Xplotter questions and observations



  • One of the great things about the Xplotter is that if the plotting is interrupted for whatever reason, you can simply shut it down and restart, the progran will continue at a reasonable point near where the last nonce was plotted.

    One of the bad thing about it is that the entire size of the plot is established as soon as the plot file is started. So if the file was interrupted, if you don't restart the program and just put it into your mining farm, you have a file with possibly only 1 nonce plotted.

    Question 1) If that happens, does the miner flag that condition, and/or generate bad nonces, so you can see there is a possible problem?

    I thought a good way to validate plot files as being good was to rerun the Xplotter using the existing file parameters and look for a message saying "plot file done, delete file if you want to replot".

    Question 2) Is this a valid way to "plotcheck" a file to insure that the file will provide valid nonces during mining?

    I tried to do this with plot files generated with the old plotgenerator program and optimized with the old optimizer program.

    The Xplotter started and did not recognize that the file was a complete file and started to count/plot nonces as if it was replotting the file withing the same file. The file size did not change but the timestamp updated to the current time.

    Question 3) Did I ruin that file? Should I replot it?



  • @rds PlotsChecker 1.0
    https://github.com/Blagodarenko/PlotsChecker/releases/download/1.0/PlotsChecker.exe
    This will check your plots

    ex PlotsChecker.exe f:\Burst\plots will check all the plots in that folder



  • @iKnow0 said in Xplotter questions and observations:

    @rds PlotsChecker 1.0
    https://github.com/Blagodarenko/PlotsChecker/releases/download/1.0/PlotsChecker.exe
    This will check your plots

    ex PlotsChecker.exe f:\Burst\plots will check all the plots in that folder

    Thanks, but I thought I read in the original Xplotter thread that that program was no good for checking the Xplotter files?



  • @rds PlotsChecker only looks at the filename and the length of the file, as far as I know. It doesn't actually look at the nonces themselves. Since XPlotter 1.0 creates a sparse file with the correct length before it starts writing nonces, I don't think PlotsChecker can tell whether all nonces have been written correctly.



  • @rds These are actually pretty good questions. And you are correct in thinking PlotsChecker won't work for already optimized plots, it won't. The only way I've been checking my plots is by if they are hitting deadlines. I've had incomplete plots mining before and they make horrible DLs, but that's the only way I've been able to manage to check.

    One other note about Xplotter is that when you restart plotting after interruption, make sure you go and manually put in the number of nonces that xplotter calculated previously to fill your dive. I guess this wouldn't be necessary if you had already specified a size (parameter -n), but if I'm filling a drive, I typically use -n 0, so I don't initially know how many nonces are going to be created.



  • @rds :

    does the miner flag that condition, and/or generate bad nonces, so you can see there is a possible problem?

    good idea for miner - i'll add it to todo list.
    XPloter can't generate bad nonces. If plotting interrupted - you need just restart XPlotter with the same parameters (except -n 0). Or for check plot use XPlotter

    0_1486056445650_11.JPG



  • @Blago.

    Another thing I noticed is that after a block of nonces is written in RAM, the write to disk starts out fast (25-50 Mb/s) and about half way through the block, the write speed drops to 1.5-3 Mb/s. This happens regardless if I make a huge block by allocating 12GB of memory or if I make a small block by using only 1G of RAM. Also adjusted threads from 2, 3 or 4, always happens. This obviously adds time to the total plot time as the nonce generator is waiting for the write to disk to finish (the line turns gray).

    Any fix for this?



  • "The entire HDD platter assembly rotates at a fixed RPM, so the angular velocity is constant.
    The average rotational latency will be the same in all cases, since the angular velocity is the same in all cases.
    The outer cylinders have faster linear velocity.
    The data rate on the outermost cylinder could be twice as fast as the innermost cylinder. On average you might get a 50% faster data rate on an outer cylinder compared to an inner cylinder."



  • @Blago,

    I'm aware of the outer, inner cylinder thing however, the write starts at 30-50 Mb/s and slows to 2-3 Mb/s This is a 10:1 slowdown. Inner/outer cylinders would not explain this. Also, I have set the RAM down to 1GB writing 600 nonces at a time, I don't think that would move from the outer part of the Hdd to the inner for that small a write.

    Just wondering if anyone else noticed this.