# Why reading speed matters ?

• Simple question, why the speed of reading matters when mining burst coin??

PS: I though only the size matters (haha) :)

• @tyvain , because if you find a 30 sec DL after a 2 minute scan and I find a 60 sec DL in 70 seconds, I win because your scan time is slower. If we have the same scan times, you win.

• @tyvain simple answer: As long as you're able to read all your plots within block time (4 minutes), it does not matter.

Rather seldom, there are some consecutive short blocks.
Let's assume you have a 120s scan time.
If there is a 45s block (A) followed by a 45s one (B), and you finish reading A after 120s with a better deadline, let's say 15s, you will not claim block A. Because the network already has a "better" chain with A and B.

Statistically, this situation is rare. (should be - any math geek around ?)

• hhhmm ok, I am starting to see what you mean.

Could sum up by : "Better get a slow big HDD than a small fast one, as long as it's not 'too slow'."

PS: yeah, also work if you replace word 'HDD' by d** :)

• @tyvain , any current HDD sata/sas or usb 3.0 is plenty fast. It's the miner software/processor/gpu that determines the speed.

• however, my logs say that jminer had to stop my [email protected] readtime 91 times in the last 9 days for a faster block!

my guestimate is that there would have been a 0.000000000000002% chance that it would have found a better deadline!-)

• 20 seconds for 80TB is not the issue. It's reducing your 120 seconds for 600TB that could net you extra earnings with a faster read speed.

• @rds said in Why reading speed matters ?:

@tyvain , because if you find a 30 sec DL after a 2 minute scan and I find a 60 sec DL in 70 seconds, I win because your scan time is slower. If we have the same scan times, you win.

not exactly right.
tyvain has a 30s deadline after 120s,
rds has a 60s deadline after 60s.

If the following block is not found within 59s, tyvain will get the block although he is publishing it after you. It is the better chain, consensus is reached by looking at aggregate complexity, which is better with tyvain's sig than with rds's sig. Ooops, somebody has the correct vocabulary for that ?

If there is another fast block right after rds's, tyvain will not get the block as the chain is already better.

There is one other aspect - and that lies within the miner code used.
I have seen just one (mddct? I don't remember, that was 2014..) that completes reads + computation for every block (in parallel in this case). All other codes interrupt reading and restart with the new block as soon as it is on the network.

So, practically for most rigs @rds is right here. But that is not a given in the protocol, but a decision of the miner-code developer.

The chances for this to happen are dependent on your plotted volume, the more you have the more you will run into this situation. Numbers ? Oh my..

• Respectfully, I don't think your analysis in your first paragraph is correct. I've seen many cases where the winning miner DL is bigger than the best miner in a pool. I will defer to a tie breaker opinion, but I stand by what I said as I've seen it.

• @rds , alright, I read the rest of your analysis, and maybe that's what I've seen before.
Bottom line is bigger is better, faster is better but not better than bigger :)