2020 Formula Boinc Sprints

[biodoc]

Well, if davidBAM and @VietOZ dropped those late bunkers for XS, they could have overtaken us for 2nd place. It would have been close.

 

[VietOZ]

I wish i had bunkers lol. I woke up and saw the gap of 1st and 2nd was close, jumped to TSBT but then Dave said "I got this" lolz. I didn't bunker this time since the heat here didn't play nice. If y'all look back to previous Sprints, I'd have more to offer ... but not this time

While my scores looked like I dropped some bunkers, but it was just all pendings held by Dave
I only bunkered QuChem this Sprint. Was busy on Universe

 

[Fardringle]

I'm curious how the rest of the sprints will be handled. There are scheduled dates for 6 more sprints this year, but I'm not sure there are six projects on the remaining candidates list that could possibly handle a sprint.

I'd say that at least six on the current list are not viable candidates, and some are broken or retired/gone so shouldn't even be listed.

(+ for good, - for bad, ~ for maybe OK)

- Amicable Numbers is a GPU project, but has very little work available. Nowhere near enough for a sprint unless a lot more is made available.

- Cosmology is broken.

- Enigma has been idle for years.

~ Gerasim says it has lots of work available, but I frequently get no tasks sent when requested even though the server status says ~600K tasks ready to send right now...

+ NFS should be fine, if the server can handle the sudden load.

+ NumberFields shows a decent number of tasks available, and regularly has a few thousand active users. Should be OK.

~ ODLK and ODLK1 have a lot of tasks available right now, but have had some inconsistent server access/performance. Might be OK.

~ QuChemPedIA has work available, but doesn't normally have a lot of users. Don't know if the server can handle the load. Might be OK.

- Seti is gone.

+ SRBase is probably OK for both GPU and CPU.

- T.Brada Experimental Grid is a small, low traffic project. No idea if it can handle the load. Definitely not enough work available for a sprint unless more is added.

- Yafu is another low traffic project. Frequently has no work available...

 

[StefanR5R]

- Amicable Numbers is a GPU project, but has very little work available. Nowhere near enough for a sprint unless a lot more is made available.

It looks as if it is constantly generating work, but is keeping only a modest buffer of work ready to send.

- Cosmology is broken.

It used to work even with the admin AWOL, but right now several daemons are down.

~ Gerasim says it has lots of work available, but I frequently get no tasks sent when requested even though the server status says ~600K tasks ready to send right now...

Are you trying with a Windows host? Gerasim has only Windows64 applications.

~ ODLK and ODLK1 have a lot of tasks available right now, but have had some inconsistent server access/performance. Might be OK.
- T.Brada Experimental Grid is a small, low traffic project. No idea if it can handle the load. Definitely not enough work available for a sprint unless more is added.

As far as I recall, ODLK, ODLK1, and T.Brada have Single Board Computers as servers. E.g. the T.Brada server has got 2 GB of RAM. These servers are unlikely to keep up during a sprint. The internet connection of one or another of these servers may be too narrow too.

(Yoyo@home used to have incapable server hardware too, but its admin employed various drastic measures to keep the database size small enough.)

- Yafu is another low traffic project. Frequently has no work available...

IME it is always generating new work. It just has a slow work generator and not a large buffer of work to send.

 

[Fardringle]

Yes, I'm using 64-bit Windows hosts in my attempts to get work from Gerasim. Still only rarely get anything. But even if it was 100% reliable for Windows hosts, the fact that it doesn't have Linux apps (which I forgot to add to my list) is another reason why it really shouldn't be a sprint project. Lots of folks with big farms use Linux on the majority of the computers.

Thank you for the verification on my other comments. I actually like what a lot of the small projects are doing, but when they only have a little bit of work (or none) available at a time, that's a recipe for a lot of annoyed people in a sprint...

 

[StefanR5R]

- Cosmology is broken.

The server ran out of disk space several days ago. But it seems to be brought back up now, according to server_status.php. I haven't checked with a client.

 

[Fardringle]

I was able to get a few tasks from Cosmology yesterday. Not a lot, but it seems like someone is at least trying to fix it.

 

[Fardringle]

The next sprint has been announced. It is QuChemPedIA@home.

 

[Fardringle]

This may be an interesting sprint. So far, the project will only give me two tasks per computer, even though my preferences are set to no limit on the number of tasks or the number of CPUs used.

And I'm getting the same problem on all of my computers that I got the last time I tried to run this project. All tasks that I did get, ran for a short time and then paused with a message that says, "Postponed: VM job unmanageable, restarting later." No other projects are running, and there is plenty of RAM available...

 

[StefanR5R]

Linux has native tasks, and a quota of tasks in progress of 128 per host (which is very very little for my kind of hosts).

"Postponed: VM job unmanageable, restarting later" means that the VM was less responsive than the wrapper expected. The "restarting later" part of this message is a lie. IME with other vboxwrapper based projects, it will never restart. (I never ran QuChemPedIA's vboxwrapper based jobs myself though, only the native Linux jobs.)

I haven't followed what troubles Windows users have at QuChemPedIA, and whether they have workarounds. In general, the "Postponed: VM job unmanageable" situation tends to happen more often, the more loaded the computer is. If you have other projects running besides QuChem, suspend them and see if the situation improves.

The "postponed" tasks most likely need to be aborted (and reported right away, please).

 

[StefanR5R]

Loosely related to the previous sprint:

PrimeGrid: 321 Sieve is being SUSPENDED
On October 21st, we will be suspending our 321 Sieve project.
Details and discussion can be found here .

 

[Fardringle]

Linux has native tasks, and a quota of tasks in progress of 128 per host (which is very very little for my kind of hosts).

"Postponed: VM job unmanageable, restarting later" means that the VM was less responsive than the wrapper expected. The "restarting later" part of this message is a lie. IME with other vboxwrapper based projects, it will never restart. (I never ran QuChemPedIA's vboxwrapper based jobs myself though, only the native Linux jobs.)

I haven't followed what troubles Windows users have at QuChemPedIA, and whether they have workarounds. In general, the "Postponed: VM job unmanageable" situation tends to happen more often, the more loaded the computer is. If you have other projects running besides QuChem, suspend them and see if the situation improves.

The "postponed" tasks most likely need to be aborted (and reported right away, please).

Thank you for the input!

I loaded up the Linux VMs I have been playing with on my primary home machine (Ryzen 3900X with 2 cores assigned to each VM) and the project seemed quite happy to load them up with work. They each grabbed about 120 tasks very quickly and seem to be running OK so far. The host Windows 10 on that same PC has also received multiple tasks since my previous message, but returned them all with a 100% failure rate. I suspect that the project's VM and Hyper-V (running my Linux VMs) aren't playing nice together.

Maybe I just need to give the VMs some more cores (or make more VMs) for this project, and not bother running the sprint on my other computers since running and managing VMs on those is not really feasible right now...

 

[lane42]

Iam getting

QuChemPedIA@home.

Service Unavailable

 

[Icecold]

Iam getting


Service Unavailable

Same here.

Edit - seems like it's back up now.

 

[StefanR5R]

With the nwchem application, the power meters on my computers show an above average power consumption compared with usual DC projects. The AVX Turbo Boost 2.0 clock offset is in effect most of the time on the Intel cores. And the AMD cores generally run below the Base Clock too.

 

[Fardringle]

My 3900X, with just 8 of 12 cores (16 of 24 threads) running QuChemPedIA in Linux VMs is sitting about 5-8C higher than it normally does with all threads active running other projects. It's definitely a "hot" project, pulling a lot of power through the CPU...

It's also using up all of the 32GB of RAM on the machine with just 16 threads, which is why I'm not running all 24. I haven't seen that happen with any other project yet.

 

[Ken g6]

Same here.

Edit - seems like it's back up now.

Looks like the project admin is aware of the Sprint and will try to support it.

Spoiler: that thread

Hi damotbe,

It looks like QuChemPedIA has been selected for the Formula Boinc sprint: http://formula-boinc.org/sprint.py?sprint=17&lang=&year=2020.

Just giving you warning that you will see extreme load as the teams try to grab / crunch / upload tasks.

PM me if I can help in any way.

All the best & good luck!

Let's rock !

 

[biodoc]

Same here.

Edit - seems like it's back up now.

The project goes down for maintenance for about an hour every night.

 

[StefanR5R]

It's also using up all of the 32GB of RAM on the machine with just 16 threads,

RAM utilization on Linux is very modest. Just 22 GB on a 128-thread computer for example.

 

[Fardringle]

RAM utilization on Linux is very modest. Just 22 GB on a 128-thread computer for example.

It seems to be the way the QuChem project application is running in Linux inside the Hyper-V VM since each task is using about 2GB of RAM on this computer.

 

[TennesseeTony]

@VietOZ , Daaaannnnnggg! Is that a whole 2 weeks of bunkering? I am guessing 2 weeks minus the last Sprint, perhaps. Impressive!!

 

[Orange Kid]

QuChemPedIA@home day one

1	The Scottish Boinc Team	25	12,448,400
2	XtremeSystems	18	11,960,400
3	L'Alliance Francophone	15	11,547,200
4	UK BOINC Team	12	2,239,600
5	TeAm AnandTech	10	1,912,600
6	Rechenkraft.net	8	424,800
7	SETI.USA	6	394,800
8	[H]ard|OCP	4	213,200
9	Planet 3DNow!	2	158,400
10	Russia Team	1	92,200

From FreeDC

xii5ku		776,000
10esseetony		192,000
biodoc		133,200
crashtech		92,400
phoenicis		45,000
Orange Kid		32,600
emoga		20,000
Fardringle		19,000
zzuupp		10,000
GLeeM		5,000

 

[StefanR5R]

Tony,
I am not as impressed. Keep in mind that this preparation was possible to put together at convenient times of day, with minimum or no conflicts with work or family or biorhythm.

It makes a big difference if you are the one who sets the sprint project, and prepare at your leisure without real life interference.

With only a few project candidates left in this season, the dual team with its double vote (or is it triple actually?) will have little difficulties to work most of the remaining sprints as ~10 day events, rather than <4 day events.

 

[Fardringle]

Thanks for the stats, OrangeKid! Sure will be nice if more than 20%% of my reported results actually get validated before the race ends! Still won't be a huge amount since a couple of my computers didn't want to run the project at all, but I like to actually try to make a contribution.

 

[StefanR5R]

Sure will be nice if more than 20%% of my reported results actually get validated before the race ends!

The ratio of my current result states:
32 % validation pending, 55 % validation inconclusive, 11 % valid, 2 % invalid, 0.1 % error

Unfortunately, the inconclusive workunits may easily sit on the server for weeks if not months before a next task gets assigned to another host to fulfill the quorum. My oldest ones are from June.