Well... that is very exponential looking graph

yep this is starting to look like someone put 2^x into the work generator limit

To summarize the observations during the first hours after May 12 18:00 UTC (contest announcement), and the first hours after May 15 00:00 UTC (contest start):

• Work generator speed was a bottleneck during the first hour, but not later anymore.
  
• There was so much work generated subsequently, that work generator speed is not going to be a bottleneck anytime soon.
  
• However, with more than 250,000 results returned during the first five hours of May 15, first the validator, then the assimilator was maxed out.
  
• For several hours now, the server is not assigning new tasks to hosts.
  

Is the assimilator backlog the reason for the server's refusal to send new work?

To summarize the observations during the first hours after May 12 18:00 UTC (contest announcement), and the first hours after May 15 00:00 UTC (contest start):

• Work generator speed was a bottleneck during the first hour, but not later anymore.
  
• There was so much work generated subsequently, that work generator speed is not going to be a bottleneck anytime soon.
  
• However, with more than 250,000 results returned during the first five hours of May 15, first the validator, then the assimilator was maxed out.
  
• For several hours now, the server is not assigning new tasks to hosts.
  

Is the assimilator backlog the reason for the server's refusal to send new work?

Feeders inability to keep tasks in memory for when requests come in.

From memory the scheduler only looks in memory to see if there is any tasks to be issued when its looking for work to send. It is the feeders job to keep said memory full(well cached), this way it doesn't issue lots of tiny database queries for work.

Background results processing on top of the sprint load was overwhelming the server. I've turned that off. Hopefully the server will catch up soon. Thanks for your patience!

do your stats exports tax the servers even more?

Shame I have received any NFS work all day :(

---

Work has been going out, but it gets immediately gobbled up. It seems nearly everyone wants work from the lasieve_5f queue, so I've temporarily stopped feeding work from the other queues until those clients are full.

I got over 9000 Wu in 1h so it looks like it worked

Work has been going out, but it gets immediately gobbled up. It seems nearly everyone wants work from the lasieve_5f queue, so I've temporarily stopped feeding work from the other queues until those clients are full.

It looks like you're efforts are rewarded:


PS: Are you able to reduce the time between server status page updates? xD

PPS: https://munin.kiska.pw/munin/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph&plugin_name=Munin-Node/Munin-Node/results_nfs&size_x=800&size_y=400&start_epoch=1620441730&stop_epoch=1621132930

PS: Are you able to reduce the time between server status page updates? xD

The server is stable right now. I'm not touching it! :-)

PS: Are you able to reduce the time between server status page updates? xD

The server is stable right now. I'm not touching it! :-)

*pokes server with long stick*

Ok Kiska, no more sticks!

It's always fun to wake up and discover Apache PHP crashed shortly after I went to bed. We're back and I'll keep an eye on it.

Dammit Kiska! :D :D :D

@Greg, well done sir, comms are a bit spotty but that the server is generally handling a massive inflow well is a testament to you and your team! Let's hope you have no more surprises.

Ok Kiska, no more sticks!

It's always fun to wake up and discover Apache PHP crashed shortly after I went to bed. We're back and I'll keep an eye on it.

Sorry not sorry :p



PS: My thing polls the page once per 5 minutes :D

And this is not the problem as the page is cached on BOINC server side.

Out of complete curiosity what percentage of the current lasieve_5f number was processed thanks to the pentathlon?