The Gridcoin 4x4x4 Challenge - week 1

Welcome back to our weekly show!
And I'm obviously using 'weekly' in the loosest sense possible. Also 'show'.

Week 1 in numbers

Our first week had 8 days, due to my lack of time and coordination.
I couldn't get the status snapshot on Wednesday morning, so I waited for 24 more hours to get the situation after everything got updated overnight.
As our frequent readers might remember, I am running BOINC on my day-to-day laptop. That means about 12 hours/day on weekdays, plus maybe a couple of hours on weekends.
I chose not to leave it running overnight for the challenge, I find that a bit wasteful, perhaps I will detail in a separate post.

To start with a bang, here's the "cash" produced (I started the challenge at 0 owed GRC):

See, I told you I'd get rich :)

The magnitude went pretty up smoothly, with a small hiatus over the weekend for obvious reasons

If we look at the projects overview, they all went up pretty well, except for WCG which seems to be lagging behind quite a bit.

But that image doesn't tell the whole story. Looking at the Mag graph per project, we see that SRBase decided to take a suddden vacation right after the beginning of our challege.

I really don't know what happened there, but for 3 or 4 days there were no WUs coming, with no apparent error in the log. I tried updating manually, suspending all the other projects, nothing worked.
But then it came back on its own, and SRBase nicely recovered the Mag gap and (spoiler alert) is shaping up to become the most productive of the projects.

Scientific comparison

The title above is just clickbait. Fake news. Covfefe.
It turns out I have no clue how to compare the numbers for individual projects in a meaningful way.

• Mag depends directly on each project's success with crunchers. See WCG above, while it had equal weight to the other projects, it managed to gather less Mag in a week than SRBase, which was on the bench half the time
• RAC is a great way to compare participants to the same project, but seems meaningless for cross-project evaluations. Here is how my stats looked on Thursday:
  
• Credit is even worse, because it's an all-time aggregate value and doesn't really show what happened on such a short period (that's what RAC was created for in the first place). And every project seems to be pulling values out of its ..er.. servers anyway, with no traceable logic.

So to be able to set up a method of comparing each project's throughput in my particular case, I think one idea would be to compare actual CPU time spent on each.
Ideally, these values should be equal for equal-share projects, but as we saw with the SRBase situation that is not necessarily the case. Plus, I have a feeling that BOINC task scheduler wold prove to have less-than-pharmaceutical precision in splitting the run times.

But getting that metric proves to be almost impossible to me. BOINC manager has it per-task, but doesn't seem to aggregate the numbers anywhere per-project.
The project sites don't aggregate it either, so one would have to manually get the WUs list from each project and perform some spreadsheet magic (=SUM :) ).
But then we see that NFS@Home for instance purges the stats quite often (at this moment I can see only the last 3 WUs in the list).
The stats sites (BOINC Stats, Free-DC) also don't seem to offer aggregates.

So other than sifting through the stats daily and saving them locally, there doesn't seem to be a way to get aggregate CPU time per-project in a civilized fashion.

Unless one of you avid readers has a proper way to do it.

Empirical observations

• The first obvious one was that SRBase had a big hiatus last week. Did anyone else experience this?
• On the other hand, SRBase seems to have the fastest growth once it's actually running.
• WCG seems to be the most popular project out of the 4, so it gets the least Mag
• Could that also come partially from the fact that it has the most time-consuming WUs, so they get suspended a lot to switch to other projects? (I kept the 60 mins switch time default)
• On my particular system, running on 100% CPUs (all 4 threads) puts pressure on the cooling solution and kicks the fan to max speed and noise. Miraculously, the CPU manages to stay unthrottled the whole time and runs at boost frequency, so props to Asus for the adequate, if not quiet, cooling solution. Running with only 2 threads gets about 65-70% CPU load and keeps the temperatures and noise in a more pleasant zone. This is important for a computer that gets used daily for office, email and programming (that takes place on remote systems, so not a lot of CPU load locally). But of course I will put up with the noise and sweaty palms for the 4 weeks of our challenge. What a man does for the love of science!
• More on that 2 vs 4 threads: this being a 2 core / 4 threads CPU, naturally loading it to the max results in reduced performance/thread. On shorter ODLK tasks, I saw about 35-50% increase in runtime from running 2 threads to running all 4 in parallel. So it's still worth it to run at max threads, just don't expect miracles. Those are not real horses you are riding there, cowboy, just holograms of poneys with Microsoft Windows saddles on them!

Wrap-up

Thanks for reading or at least scrolling all the way down here!

Also, thank you for all the subscriptions and votes last week. Keep them coming!

My secret plan is to use those hard-earned steem dollars to convert to GRC and top up my wallet to prepare for solo staking. But that's a different challenge, and I still have to give it proper planning before jumping in, especially with the highly volatile crypto market these days.

I also plan to keep the 8-days week, since I obviously have more time on weekends to write the articles, so pushing the
cutoff day towards the weekend will just keep the info more fresh.

See you in the comments section.
Happy crunching y'all !
slowminer