Pentathlon 2023 - Obstacle Run- Yoyo@home - May 5 00:00 UTC to May 19 00:00 UTC

[Skillz]

The Obstacle Run for the 2023 Pentathlon is YoYo@home. This project requires that you use the BOINC Manager to register as their is no option to register on the site. I will guide you through setting this up.

Step 1: Downloading BOINC
Download BOINC - https://boinc.berkeley.edu/download.php (You do not need the version with VirtualBox, but it wont matter if you install it anyway)

Step 2: Installing BOINC
When it is downloaded simply double click the file to install. After the install process the BOINC Manager should pop up in simple view. If not, then click on Start and find BOINC Manager, open it.

Step 3: Registering and Computer Setup

Registering for Yoyo and attaching the project to your computer: Towards the bottom you'll see "Add Project" like in the picture. (Note that you might not see anything in the stuff below that since you haven't attached any projects yet.)




Step 3.1: Find yoyo in the list:



Click next

Step 3.2: Creating new account





Enter an email address and password. Confirm the passwords match and click next.

After this point, yoyo@home is attached to your host and downloading work.

However, you need to ONLY run EMC and/or EMC P2. The difference? ECM P2 can use up to 10GB worth of RAM per task. So if you have a 16 core, 32 thread host that means you'll need over 320GB of RAM to run the P2 tasks on all 32 threads. Not likely. So choose ECM.

Step 4: Setting ECM and ECM P2 Only
You need to login to the yoyo@home web site with the email and password you created above: https://www.rechenkraft.net/yoyo/

Then go to this link: https://www.rechenkraft.net/yoyo/prefs.php?subset=project

Match the screenshot:


Click update preferences.

Step 5: JOINING TEAM

Join the team: Go here https://www.rechenkraft.net/yoyo/team_display.php?teamid=116

Click join team.

 

[mmonnin03]

50% Bonus right now
Start: 07 May 2023 00:00 UTC
End: 08 May 2023 00:00 UTC

 

[StefanR5R]

The yoyo@home server software has got an ancient bug. Some but not all of my computers ran into this today:

Server sends a malformed response which the client reports in its log with this:
[error] No close tag in scheduler reply

You can tell your host is affected e.g. using boincmgr, Tools – Event Log, then scroll through the log to a part when the client had its latest communication with the server.

I found this workaround:

• Open C:\ProgramData\BOINC\cc_config.xml (Windows) or /var/lib/boinc/cc_config.xml (Linux; by default you need to do this as superuser).
• Scroll into the <options> section. Look for a line like <max_tasks_reported>…</max_tasks_reported>.
• If the line does not exists, add it with this value:
  <max_tasks_reported>1</max_tasks_reported>
  If the line does exist, change the existing value to 1.
• Save the file.
• In boincmgr, go to View – Advanced View…, use Options – Read config files.
• Then go into boincmgr's Projects tab, select yoyo@home, push [Update].
• The client contacts the server and the server responds. Once the response finished (you are seeing it in the event log), check in the Tasks tab if there are still results ready to report. If so, trigger another Update. Repeat until the client does not have any results ready to report anymore.
  (Watch the event log instead of the Tasks tab. You need to repeat the Updates as long as the client's requests contain the log line "Reporting 1 completed tasks".)
• Change the line in cc_config.xml back to something saner like <max_tasks_reported>100</max_tasks_reported>, save the file, and re-read the file via boincmgr.

Note, when you go through this procedure, you will likely encounter lots of lines like
[error] Already have task ecm_cw_1683381639_N_4_434M_17930_0
in the event log. Don't worry. This is merely the resolution to the previous misunderstandings between client and server while the server sent malformed responses.

Also note that you may have to force lots and lots of Updates until this mess is cleared. Be patient. Or if you are an experienced boinc user, use a script for the updates. Ignore the project's request_delay while you perform this cleanup.

 

[StefanR5R]

If you are new here and the above post disturbs you:

If you just started now to compute yoyo@home, your computer is not likely to have encountered this server problem… yet.

 

[StefanR5R]

I made a simple modification that I hoped would help: I disabled networking most of the day and only enabled it at the beginning of each UTC day.

On a 128-threaded host, I would have needed to set up two client instances (with yoyo@home specific workarounds) in order to ensure a >24h deep work buffer. This year I just did not bother; I had not planned to.

 

[Ken g6]

On a 128-threaded host, I would have needed to set up two client instances (with yoyo@home specific workarounds) in order to ensure a >24h deep work buffer. This year I just did not bother; I had not planned to.

Suspending networking for as many hours as possible before midnight would have had some benefit. 🤷‍♂️

 

[StefanR5R]

Certainly true! But then again, on the 100% bonus (or 0% malus) day, yoyo@home's validator was busy during almost the entire day. I didn't watch how it fared on the other two obstacle days. Consider what would have happened if for example parsnip alone had brought more than a (I hope to be pardoned for saying it like that) half-assed ½ days deep bunker (as he did just what you described). Either he would have needed to plug the bunker doors again early on that day, or there would have commenced a general weeping and gnashing of teeth because everybody else got hardly anything validated that day.¹ It's merely hindsight, but there would have been little point² in bunkering even a bit more before that day, across all pentathletes.

________
¹) edit – or, as discussed, one or another other server limit would have been hit even earlier
²) another edit – Again sorry for my constant complaining, when everybody else had a good time. I need to take things easier.