There are 800 in 1.5 million total results or so a day for HSTb

https://www.worldcommunitygrid.org/stat/viewP...&numRecordsPerPage=14

https://www.worldcommunitygrid.org/stat/viewG...y.do?numRecordsPerPage=14

It means unless your client connects to the server right in the minute there are slots filled with these workunits, they're not snapped up. Random distribution so all have the same small chance.

I can sympathize phishbonz. I re-started crunching earlier this year, when there were several thousand work units per day, and crunched about 3.5 years worth. And then for the past 6 months or so, the reduced work load hit and I've been struggling to get those last 1.5 years. Almost there, just need another 50 days or so, but it'll probably take me a month to get there haha

But keep trying! The research team has hired a new researcher and are training him/her on HSTB, so maybe we'll see increased work flow eventually. We might all get there yet!

If the queues are totally full, you won't get any.
I have to ration the number of every project to keep the queue short yet have enough waiting to keep all threads busy for MIP and MCM. I see 1 or 2 HSTB and 1 or 2 ARP per day per computer.

I have two almost identical machines, a Ryzen 1700 and a Ryzen 2700, both running Ubuntu 18.04.3 and both set to the same "Default" profile, which includes TB, MCM, MIP, and SCC.

The Ryzen 1700 gets the TB (a few per day), and the Ryzen 2700 doesn't. This has been going on for several days now, so I don't think it is by chance. I keep a default buffer (0.1+0.5 days), so they have both had the opportunity to pick up new work.

It isn't a bug, just a feature. I don't care who gets the work, or which machines, just as long as it is done.

Since there is an enforced back-off of 121 seconds and the releases are quasi timed after the whole minute, internet atom time synched, realistically, once every 3 minutes. Since you have no control over the actual backoff signal which increments to as much as 24 hours if work fetches are unsuccessful, IIRC, a forced update will help to know the next one is in 121 seconds, so the first one needs to be right before the minute is up taken response times into account. To add, ARP1 and HSTb are on forced random release with the ltd numbers that come out each day, making it all mostly a stroke of luck. I let it be and still manage to have a continuous stream for ARP on 1 thread 24/7. HSTb are so rare, get one or a few every 3rd-4th day and that's it for a week.

More annoyingly on HSTb is, that when I snap a few and crunch them, they often sit 3-4 days and more in PV, meaning some are queuing them big time, which slows down the iteration generations (dependencies) i.e. quick returns puts actually more work out in a day. Uplinger noted this as much applies to FAHB. Get a return in 6 hours and the next generation will be put out the next day.

No intend to invoke on any guilt complexes.

PS, I love the button punchers who do this every 60-120 seconds... they're always on backoff, too soon. The servers can handle it... they treat it as a DDOS attempt from your IP address.