I have 2 different USB hubs. One is a 2.0, and the other is a 3.0. Does it really matter if for farming I’m using a 3.0 or not? (Besides the obvious tranfer time from the NVME, for actual farming does it matter?)
YES!
You will massively increase your challenge response time using USB 2.0. You need to use USB 3.0 SS throughout. Notice the SS!! USB 3.0 is still too slow to achieve good response times. Only USB 3.0 SS will keep your response times in good shape.
Is the increase significant in regards to the 30 seconds limit? The speed matters for plotting, for farming I thought the difference was minimal and both could work.
When I added an array and hooked it to normal (not SS) USB port my response times were badly affected. Time for writing a K33 plot went from around 30 minutes to almost 3 hours. I was actually missing challenges when it was writing files to the drive array and response times were higher across the board.
I installed a USB 3.0 SS hub and use only the 3.0 SS ports on the PC and everything went back to normal with 30 minute writes and no missed challenges.
By the way, 30 seconds is not the limit. Your response times should be under 2 seconds and definitely not over 5 seconds. My response time averages under .02 seconds using 3.0 SS throughout.
Ah, that’s because you are plotting. I wouldn’t do that on USB2 for sure since it’s vastly inferior. But I don’t see it as an issue for farming if the hub isn’t saturated.
Your point is well taken.
I cannot say I am 100% sure how badly farming is affected if you are not plotting as I upgraded as soon as I saw the problem start and did not really nail down if it was happening much when not writing plots.
I would say (EDIT: incorrectly) that as 2.0 is about ten times slower than 3.0 you can rest assured that ALL of your response times are affected if you use 2.0. CORRECTION: USB 3.0 is about twice as fast as 2.0. Only USB 3.0 SS is about 10 times faster than USB 2.0.
1 Like
PCIe 2.0 has a bandwidth of 0.50 GB/s per PCIe lanes. PCIe 3.0, on the other hand, offers 0.985 GB/s per PCIe lane.
1 Like
3.0 SS is 10x faster than 2.0 though.
Yeah, I should have been more clear in my reference. I was talking about 3.0 SS.
Just now, I read a few conversations about farming using 2.0 and most agreed that 2.0 worked unless you were plotting.
From what I read, 2.0 is ok for farming, but I like my 3.0 SS.
I have an avg response time of around .12 seconds using 3.0 SS. Even when writing a plot to the drive array I have less than 1% of challenges over 2 seconds, and none missed, with avg response time still around .2 seconds. Maybe it is overkill but I sleep better, lolz!
1 Like
2.0 works just fine for harvesting. Have over 300 drives connected and almost no stales on flexpool while still writing to those drives.
1 Like
What is your average response time?
Right now i have 7 on 2.0, and 7 on 3.0. I dont notice a difference in the 2. Average response is 1.5 sec
Between 2-3 sec, however I don’t think you should draw much meaning from that answer, because it depends not just on whether it is USB 2.0 and 3.0, but more on the number of drives connect, plot count, how powerful the harvester is, and difficulty used by the pool.
I draw a lot of meaning from response times.
I would not be at all happy with an avg response time over 1 second. If your avg is that high than you have many challenges over 5 seconds which is not good.
I suggest you install farmr and get a real count on your challenge information.
I have just over 60 TiB of plots on 10 HDDs in three 4 bay arrays. Start to finish is all USB 3.0 SS. My avg response time is under two tenths of a second.
I disagree with you. I don’t see a reason to not be happy with avg response time over 1 second as long as high percentiles are also within reasonable range (significantly below 30 seconds).
I do have proper monitoring in place and the stales I have are due to concurrent writes to those disks that are handled by weak mini PC.
As an example, I’m attaching graph from a harvester with 1844 plots (41 disks connected via USB 2.0) showing max lookup time from every 1 minute interval. Keep in my that I’m on Flexpool and they set difficulty to 1 which results is multiple proofs being fund every minute, hence the graph basically captures the worst scenario. What is shows it that the lookup time is consistently below 6 seconds during the entire 24 hour sampling period.
Also, it is worth mentioning that there is nothing magic about the 5 seconds threshold that pops up in the logs. It is arbitrary number (lower than 30 seconds) and by no means it implies that one is losing chances for wining XCH. The actual blockchain timeout is 30 seconds.
All in all, my payouts would not be different if I had response time 0.2s vs 3s that I currently have.
2 Likes
Interesting read. So, when you get the warnings because it is over 5 seconds, that doesn’t really mean anything? As long as it is below 30 seconds, I am good?
I’ve seen 30 seconds mentioned in multiple places and it is also on the official Chia FAQ. I can’t find it easily in Chia Greenpaper, hence I’m not sure what does it exactly imply (between what events it is measured and who measures it).
I would assume that there will be some delay between node getting new signage point that triggers lookup and the propagation of the proof from the farmer to the entity that validates them (timelord?, not sure). Assuming reasonable internet connection, this delay should be minimal (compared to actual slow HDD lookups). Keep also in mind that the actual proof check takes more HDD reads than discarding eligible plot without proof - i.e. if you were solo farming you would get messages that some number of plots were eligible for farming. Those plots would trigger few reads and occasionally would result in reads taking more than 5 seconds. Now, with pools (especially on Flexpool) you will often also get proofs for the eligible plots. Ending up with a validated proof requires more HDD reads and will take more time. Hence, you should really care about lookup times when there are proofs (easy to validate on Flexpool). If those are reasonable below 30 seconds then you should be safe.
There is one more caveat. One think that I’ve observed that in case you are using distributed harvester you might notice a situation when the harvester lags (for example because of scanning drives for new plots) and will not be processing challenges. Once it resumes, it will handle multiple challenges in short period of times. Those challanges are already lagging since they happend on a blockchain some time ago (full node knew about them earlier). The logs on the harvester will only indicate lookup time, but will not include the additional lag caused by processing challenges with additional delay.
Very informative conversation, thanks to all!
My only addition was sort of said by rsok.
I’m worried about challenges that “passed”, but in reality, did so too late to successfully compete in the lottery. If my avg response time is .12 seconds and my longest response is under 2 seconds then I feel I have a better chance to win then a peep who has many response times running over 2-5 seconds.
I do not know this to be true but it makes sense from what I have read.
Be well! 
I think your concern about challenges that passed but we’re too late is valid, but the main thing here is that the lottery lasts 30s according to the documentation. Tossing lottery ticket in few seconds still makes those tickets eligible for the lottery.
2 Likes
I will try a 30 port USB2 powered hub (and other configurations) when it finally arrives in a few day and report here. That should settle it, right ? 