FYI, there will probably be some increased server load.
http://formula-boinc.org/sprint.py?lang=&year=2019

we are ready for it...

Hi Eric,

Out of curiosity, would you be able to publish an estimate of the server load and completion of WU increase before and after the FB sprint event? There are some projects where the server and/or WU generation can't cope up during the FB sprint. Don't want to put any names to this but those who participated in FB sprint will know what I'm talking about. Thanks.

Hi Eric,

Out of curiosity, would you be able to publish an estimate of the server load and completion of WU increase before and after the FB sprint event? There are some projects where the server and/or WU generation can't cope up during the FB sprint. Don't want to put any names to this but those who participated in FB sprint will know what I'm talking about. Thanks.

I might be able to do that, depending on exactly what you want. How do you measure "server load"? Do you mean the kind of information that is on the server status page? I can definitely measure a WU completion rate, but I would guess that is proportional to the GFLOPS on the server status page. Just let me know what you would like to see.

We handled the BOINC Pentathlon last year with no problems, so unless the FB sprint draws a lot more participants, I'm confident we can handle the load.

I saw ~380k tasks available a little after the event start and now its over 400k. I don't think FB has as high of participation than the Pentathlon even if there are more teams. Some projects were in their 1st year of being a BOINC project last calendar year and did not know about being listed for FB Sprint. Some tripled their normal daily output and their servers suffered.

I saw the tasks in progress growing fast, so I dumped a bunch more WUs into the queue. I'd rather have too many out there than not enough.

Thanks Eric for the good measure. I'm sure any/all the statistics on the load change that you can provide would be appreciated as it could give others an idea of what to expect for the upcoming sprints the rest of the year.

---

Well done Mr. Eric Driver, Sir, for keeping up with a sudden demand due to a competition. :) Well done indeed!

Found via the rechenkraft.net forum:
The beginning of this sprint brought NumberFields@home's second and third highest credits/day in boincstats' recorded history, eclipsed only by the first day of Pentathlon 2018.

Found via the rechenkraft.net forum:
The beginning of this sprint brought NumberFields@home's second and third highest credits/day in boincstats' recorded history, eclipsed only by the first day of Pentathlon 2018.

Very interesting! Thanks for the link.

I have some information regarding server load. I think a good measure of that is how many WUs are processed per hour. Here is an average, broken down by day:
Before Sprint (3-13): 3571 WUs/hr
Thurs (3-14): 9329 WUs/hr
Fri (3-15): 5042 WUs/hr
Sat (3-16): 4311 WUs/hr
Sun (3-17): 6593 WUs/hr

On Friday, the current batch that had been running (14x11) ran dry and processing started on the next batch (14x12). The WUs in 14x12 average twice the run time as 14x11, so to compare apples to apples, I did a 2nd calculation where I double the WU rate for the 14x12 cases before adding to the 14x11 rate. This gives the following WU rates (this is what the numbers would have looked like if both batches had the same run times):
Thurs (3-14): 9329 WUs/hr
Fri (3-15): 6871 WUs/hr
Sat (3-16): 7930 WUs/hr
Sun (3-17): 10692 WUs/hr

I think the key point here is that the worst server load is at the start and end of the sprint. I'm not an expert on the strategies behind these competitions, but I assume it's due to bunkering up front and then holding back results until just before the finish. Anyways, the other point of interest is that the worst server load was about 3 times our typical load.

Thanks for the break down Eric.

---

Eric, thanks for the stat. Very useful and I'm sure most crunchers who participated in the sprint are glad that there were no hiccups during the 3/4 day event. Kudos!

You're welcome. And thanks to all the participants!

Now, wait until you get GPU code running.

Now, wait until you get GPU code running.

Funny you should mention that... I just got a prototype working on my GTX 1050. It's about 20 times faster than the CPU version. Probably still a few weeks out before it's production ready though.

I have some information regarding server load. I think a good measure of that is how many WUs are processed per hour. Here is an average, broken down by day:
Before Sprint (3-13): 3571 WUs/hr
Thurs (3-14): 9329 WUs/hr
Fri (3-15): 5042 WUs/hr
Sat (3-16): 4311 WUs/hr
Sun (3-17): 6593 WUs/hr

On Friday, the current batch that had been running (14x11) ran dry and processing started on the next batch (14x12). The WUs in 14x12 average twice the run time as 14x11, so to compare apples to apples, I did a 2nd calculation where I double the WU rate for the 14x12 cases before adding to the 14x11 rate. This gives the following WU rates (this is what the numbers would have looked like if both batches had the same run times):
Thurs (3-14): 9329 WUs/hr
Fri (3-15): 6871 WUs/hr
Sat (3-16): 7930 WUs/hr
Sun (3-17): 10692 WUs/hr

I think the key point here is that the worst server load is at the start and end of the sprint. I'm not an expert on the strategies behind these competitions, but I assume it's due to bunkering up front and then holding back results until just before the finish. Anyways, the other point of interest is that the worst server load was about 3 times our typical load.

https://stats3.free-dc.org/stats.php?page=proj&proj=num

This shows over 20x normal load by credit at the peak and 9-10x the last two days. If your GPU version is 20x as fast on just a 1050 I would expect there to be much more 20x once a GPU version is released. More people will come to the project with GPUs to cash in on the higher credit. Assuming the same task is worth equal if ran on a GPU vs CPU.

The free-dc stats page doesn't have all of the top users on it, which could explain the discrepancy. Compare to this:
https://numberfields.asu.edu/NumberFields/top_users.php
I wonder if free-dc stats only uses data from those who consented to stats export.

Now, wait until you get GPU code running.

Funny you should mention that... I just got a prototype working on my GTX 1050. It's about 20 times faster than the CPU version. Probably still a few weeks out before it's production ready though.

Awesome! I assume that if the GPU is 20 times faster than CPU, then you will get your result quicker too, assuming the calculation method is the same with both CPU and GPU(?). Please keep us posted. It is exciting to know what's coming soon and I'm sure some crunchers here are ready to fire up their GPUs when the task are available.

Now, wait until you get GPU code running.

Funny you should mention that... I just got a prototype working on my GTX 1050. It's about 20 times faster than the CPU version. Probably still a few weeks out before it's production ready though.

Awesome! I assume that if the GPU is 20 times faster than CPU, then you will get your result quicker too, assuming the calculation method is the same with both CPU and GPU(?). Please keep us posted. It is exciting to know what's coming soon and I'm sure some crunchers here are ready to fire up their GPUs when the task are available.

Yep, results should be that much quicker. It works with the same exact WU inputs. On my test case, the CPU time was 13000 sec, the GPU time was 500 sec.

I will open a new thread in the next several days to post more info, and maybe put a beta version out there.