2020 Formula Boinc Sprints

[lane42]

Thanks for the stats OK

 

[StefanR5R]

Hey, @gizmo23 defected to Ars Technica over in league 2. Will they make it yet into the top ten of their league before the end of the sprint? Perhaps, but it all depends on @gizmo23 now.

Oh, I see that league 2 is almost dominated by Belgium's Best Team (founded by you know who) by now... if it wasn't for @Aurum's Foundation. ;-)

 

[Orange Kid]

Moo! Wrapper Final

1	XtremeSystems	25	282,887,700
2	The Scottish Boinc Team	18	194,815,384
3	TeAm AnandTech	15	161,112,050
4	UK BOINC Team	12	94,127,517
5	Planet 3DNow!	10	49,687,232
6	LITOMYSL Boinc Team Czech Republic	8	41,455,028
7	Rechenkraft.net	6	38,019,353
8	Crunching@EVGA	4	31,777,317
9	L'Alliance Francophone	2	22,421,241
10	Overclock.net	1	20,076,30

From FreeDC

	Day 3	Day 2	Day 1		Total
xii5ku	41,491,036	2,433,568	2,442,832		46,367,436
biodoc	6,184,120	6,119,792	14,079,216		26,383,128
crashtech	6,849,664	5,867,820	11,934,750		24,652,234
phoenicis	5,413,496	4,826,000	265,072		10,504,568
Icecold-Team Anandtech	3,467,070	3,668,440	3,318,976		10,454,486
Orange Kid	2,426,832	2,211,184	4,447,176		9,085,192
Lane42	2,232,544	2,200,224	3,488,464		7,921,232
10esseeTony	1,555,744	1,609,128	2,999,666		6,164,538
Kiska	847,672	1,032,120	3,323,000		5,202,792
Ken_g6	458,384	437,720	847,048		1,743,152
waffleironhead	374,088	405,608	847,661		1,627,357
zzuupp	330,264	407,760	232,608		970,632
IEC	292,112				292,112
geecee	157,120	12,288			169,408

and the Hungarian Grand Prix results

• Lewis HAMILTON1:36:12.473
• Max VERSTAPPEN+8.702
• Valtteri BOTTAS+9.452

 

[biodoc]

3rd place is a good showing. Nice bunker drop @StefanR5R ! Thanks for the stats Orange Kid.

 

[lane42]

Thanks for the stats OK . Super drop Stefan

 

[StefanR5R]

Good morning! Thanks for the stats.

Here is the 2nd half of the sprint, top ten teams. I wasn't awake to watch, but have the replay on tape. ;-)

 

[StefanR5R]

Hey, @gizmo23 defected to Ars Technica over in league 2. Will they make it yet into the top ten of their league before the end of the sprint? Perhaps, but it all depends on @gizmo23 now.

Yep, Ars made it to 9th rank.

 

[gizmo23]

Yep, Ars made it to 9th rank.

It's true, I was just seeing how much of a difference I could make on my own. Adding a million to Anandtech's showing didn't change much, what with the heavy hitters in this team. I also read the Ars website regularly so just picked them and switched to see if I could be beneficial to a lower ranked team. Didn't realise that there are only 37 in the team, so it looks like my contribution did make up a few places.

 

[TennesseeTony]

Start your bunkers for LHC, the next Sprint which begins in 24 hours.

 

[StefanR5R]

The Sprint is the beloved/hated LHC. Beloved if you are good with the VM's, hated if not.

There are aspects which one might hate even if one is good with VMs.
Such as:

• Most of their applications are ports of their internal HPC datacenter applications to BOINC. While that's interesting on its own, unfortunately these ports are very minimal which don't make proper use of BOINC. E.g., most of the required networking traffic bypasses BOINC entirely.
• From what I understood, they don't really need donated computing capacity, they've got enough on their own. And even some spare capacity which they can donate to good causes. IOW, LHC@home appears to be about public outreach/ about showing some of the inner workings of LHC, not about supporting science with spare computer time.
• And there is more. I am thinking of a technical/ administrative issue with LHC@home which does not belong into a public forum. Or maybe it does, but I need to look up whether the issue is still current.

That said, the BOINC world has got so many number-theoretical projects, I wish it had a few more physics related projects.

 

[StefanR5R]

Another example of flawed porting of their cluster applications to BOINC: While a task of the CMS application is running, it internally requests and fetches several jobs from the LHC cluster manager, one after another and without using the boinc client for it. If one such work request fails, the entire BOINC task fails. That is, you don't get credit for any successful computation before the work request failure. Plus, the more BOINC tasks fail on your host, the less reliable is your host from the BOINC server's point of view. Consequently, the quota of tasks in progress will be reduced for this host, until it is able to finish many tasks properly again (source). "No, I didn't write the BOINC server code..." says a project developer. Sure, but they wrote their lazy wrapper.

But not only their wrapped applications are flawed. Their one native BOINC application, SixTrack, has got the problem that there are occasionally tasks which finish very quickly. Aside from network transfers overhead being a problem with these short tasks, they also reduce the boinc-client's internal estimation of average task run times. It is possible that a host receives a large number of such short tasks as a series. When it then receives a proper task with normal run time again, the client may wrongly determine that this task is taking too long, and terminate it as failed. There is no way out of this, except maybe for project reset (I don't remember if this works), or by manipulating the run time limit of queued tasks in client_state.xml.

My personal view: Projects which are not entirely straightforward to run tend to capture my interest — at least for a while. But I am not easily convinced to run projects which are not integrated with BOINC. Further, one current problem of LHC@home makes this project improper for competitions. It doesn't help if project developers don't plan to address problems which were brought to their knowledge.

 

[StefanR5R]

Sprint #13 at LHC@home,
the first 18 hours, top ten of league 1:



Points/hour of teams 2 and 3:

 

[StefanR5R]

For the rest of this sprint I need to gather the mental strength not to look at the powermeters or at 'uptime'. It's sheer horror. Much of the time these tasks just sit there doing nothing.

My guess is that they are attempting internal transfers over LHC's cluster filesystem, but can't progress because my Internet connection is maxed out.

I think the real advantage of the native applications over the vbox application --- for a user like myself --- would not actually be their lower RAM footprint, but the possibility to cache some of the cluster filesystem traffic. However, the real solution would be a 10GigE connection straight into their datacenter...

 

[Orange Kid]

LHC@Home day one

1	XtremeSystems	25	903,877
2	Gridcoin	18	550,764
3	TeAm AnandTech	15	537,419
4	Rechenkraft.net	12	243,234
5	The Scottish Boinc Team	10	201,146
6	Overclock.net	8	83,192
7	UK BOINC Team	6	81,400
8	L'Alliance Francophone	4	50,419
9	Planet 3DNow!	2	38,816
10	Czech National Team	1	24,0

From FreeDC

xii5ku	197,628
biodoc	128,716
wes.	26,869
10esseeTony	18

 

[Fardringle]

Gridcoin is pulling ahead gradually. I wish my computers would get some work so I could help.

 

[StefanR5R]

Actually we do have similar speed to Gridcoin, and are occasionally slightly ahead. Like just now. In addition, P3D overtook LAF. This combined resulted in this current overall standing at Formula BOINC 2020:

4 . . . . TeAm AnandTech . . . . . . . . 283 :-)
5 . . . . L'Alliance Francophone . . . . 282

----------------
Some observations from the different computers of mine; all Linux:

• Dual Zen2 with 256 GB RAM, kernel 4.12.14 and 5.3.18, vbox 6.0.18 and 6.1.10 work like a charm.
• Dual Xeon with 64 GB RAM, kernel 4.12.14, vbox 6.0.12 occasionally get tasks stuck in "Postponed: VM job unmanageable, restarting later" state. Sometimes its "Postponed: VM environment needed to be cleaned up" after half a minute of run time. Such "postponed" tasks need to be aborted, as I know of no way to restart them.
  These computers also had a few tasks which ran for very long time (when I noticed this first, some ran already for a whole day), and I aborted these too.
• Core i7, 16 GB RAM, kernel 4.15.0, vbox 5.1.38 (of Linux Mint 18.3) had two lockups so far; the whole computer was stuck with a black screen and needed a hardware reset. I have no doubt that the out-of-the-mainline kernel modules of VirtualBox caused these lockups, as these computers generally work almost as reliable for me as my server hardware based computers.

 

[StefanR5R]

The 2nd 18 hours:





Meanwhile, user Aurum is rocking the 2nd League again. If the RDFfR&S ran in 1st League, they'd be fourth.

 

[Orange Kid]

LHC@Home day two

1	XtremeSystems	25	1,973,613
2	TeAm AnandTech	18	1,113,452
3	Gridcoin	15	1,066,123
4	Rechenkraft.net	12	540,633
5	The Scottish Boinc Team	10	532,406
6	UK BOINC Team	8	213,786
7	Planet 3DNow!	6	210,093
8	Overclock.net	4	138,809
9	L'Alliance Francophone	2	101,816
10	Czech National Team	1	47,771

From FreeDC

xii5ku	243,971	197,628		441,599
biodoc	117,121	128,716		245,837
wes.	145,457	26,869		172,326
Icecold-Team Anandtech	23,409	0		23,409
crashtech	19,469	0		19,469
Orange Kid	12,102	0		12,102
Fardringle	5,258	0		5,258
Peter	1,451	0		1,451
far	366	0		366
10esseeTony	108	18		126

 

[TennesseeTony]

Sorry for my lack of contribution, I started a VM task with 8 threads, went to work, came home and found it had 9 more DAYS to go. Is this an aberration? Maybe I should try another task....

 

[biodoc]

Sorry for my lack of contribution, I started a VM task with 8 threads, went to work, came home and found it had 9 more DAYS to go. Is this an aberration? Maybe I should try another task....

If it's an Atlas vbox task, abort it. On my Zen2's, Atlas 8 thread tasks take about 1.25-1.5 hours. On my ivy bridge 2P, they take 4.25 hours.

 

[StefanR5R]

The third 18 hours:

 

[Ken g6]

Sorry for my lack of contribution

Me too. I finally got some ATLAS tasks working, very inefficiently. They're only using at most 8 of 14 cores, due to RAM limits.

 

[StefanR5R]

​

This many credits were granted at each of the LHC@home sprints at Formula BOINC so far:

	June 2017	November 2018	September 2019	July/Aug. 2020
TeAm AnandTech	0.6 M​	2.2 M​	7.6 M​	1.4 M*​
all teams combined	9.5 M​	24.1 M​	49.5 M​	10.1 M*​

*) at 14 hours before the end = 80% done​

Notable changes from year to year:

2018:

The native ATLAS application for Linux was introduced in August 2017.​

2019:

Credits for Theory-vbox had been changed by the project admins a few months before this sprint.​

2020:

No SixTrack tasks are available at the time of the sprint, or a handful at best. (There is only work for vboxwrapper based applications, and for native applications which require installation of cluster infrastructure on the users' hosts.)​

Per-host quota of tasks in progress are severely broken. (Some hosts never get tasks.)​

There is one positive aspect of the technical problems this year: Gridcoin has been #1 in all previous sprints, with 1/4 of the credits of all teams combined in 2017, further increased to 1/3 of the credits in 2018 and 2019. This year, Gridcoin is ranking #3, with merely 1/8 of the credits of all teams combined.

 

[TennesseeTony]

My linux boxes are failing at the checkpoint, 10 minutes into crunching (Theory VM). Probably do not have virtualbox fully installed or something. Ah, well, good run from those who making all the points!

 

[StefanR5R]

My linux boxes are failing at the checkpoint, 10 minutes into crunching (Theory VM).

Is there a firewall running on these computers, or anywhere between them and CERN? The application inside the VM needs several ports open. For ATLAS, these are 80 (HTTP), 3128 (HTTP proxy), 443 (HTTPS), 5222 (XMPP), 9094 (perhaps used by CERN's cluster stuff) — says Yeti. I haven't found the same info for the Theory application.