Does the speed of the computer that writes the plots affect the mining speed?



  • I've noticed that the memory used to create the file is saved in the file name for plot files. Just wondering if it has any implication on read speed. I created a good portion of my plots on a slow computer and have since upgraded.

    Common sense tells me that it wont, but I just want to make sure that the RAM used when plotting does not affect mining speed.

    Thanks as always



  • RAM is not a matter when mining, only when plotting.

    Ben



  • @BenBurst said in Does the speed of the computer that writes the plots affect the mining speed?:

    RAM is not a matter when mining, only when plotting.

    Ben

    What do you mean by that? RAM is used by the miner to read the plot files.



  • The miner use RAM thats right but a riddiculous amount of it. Not noticeable.
    When mining, it use a bit of CPU and you have to worry about plot read time, that mean,how fast is your disk read speed; how your disk is connected, to give you an exemple USB2.0 sucks, USB3.0 SATA are much better; and is your plot optimized or not (yeah, optimized are faster to read...).

    Ben



  • @nox the portion of the filename that you are referencing indicates the stagger size of the plot file. the plotter sets the stagger according to the amount of nonces it can hold in ram while writing the file.
    stagger indicates the number of nonces which scoop data is stored in a sequence on the drive. there is a helpful image and explanation https://forums.burst-team.us/topic/288/plots-101/3
    the effect on mining comes in the form of hard drive seeks, having to move the read head to find the next part of the data on the disk. this will increase read time (see referenced post for numbers) and also cause wear on the drive.
    so as ben stated optimization (number of nonces equal to stagger size) of plot files is best practice.



  • @damncourier said in Does the speed of the computer that writes the plots affect the mining speed?:

    @nox the portion of the filename that you are referencing indicates the stagger size of the plot file. the plotter sets the stagger according to the amount of nonces it can hold in ram while writing the file.
    stagger indicates the number of nonces which scoop data is stored in a sequence on the drive. there is a helpful image and explanation https://forums.burst-team.us/topic/288/plots-101/3
    the effect on mining comes in the form of hard drive seeks, having to move the read head to find the next part of the data on the disk. this will increase read time (see referenced post for numbers) and also cause wear on the drive.
    so as ben stated optimization (number of nonces equal to stagger size) of plot files is best practice.

    Thank you @damncourier that was very informative.

    What I don't understand from what you said is "number of nonces equal to stagger size". Optimization does that as you said. Consider the two following files - would there be a difference in final result of the optimized file?

    1. 1TB plotted with 16GB memory
    2. 1TB plotted with 1GB memory


  • @BenBurst said in Does the speed of the computer that writes the plots affect the mining speed?:

    The miner use RAM thats right but a riddiculous amount of it. Not noticeable.
    When mining, it use a bit of CPU and you have to worry about plot read time, that mean,how fast is your disk read speed; how your disk is connected, to give you an exemple USB2.0 sucks, USB3.0 SATA are much better; and is your plot optimized or not (yeah, optimized are faster to read...).

    Ben

    Thanks @BenBurst. Maybe I should get some high speed sata cables :)



  • @nox what type of drives you mining with ?



  • @nox once optimized no difference.

    i suppose stagger size equal to number of nonces would be more accurate. the idea here is to have one long continuous read of the scoop data by the miner and that is what optimizing provides.

    again to the referenced post
    @Blago's plot experiment
    17930413153828766298_69900000_1000000_4000 - not optimized, reading time 3818 ms
    17930413153828766298_64900000_1000000_1000000 - optimized, reading time 2143 ms

    the second to last number in the filenames is the number of nonces and the last is the stagger size. optimized they are equal.