Hi All,

I've been taking a look at the RAC for the top 10 computers on this project. I have a question regarding computers that do not have outstanding WU's to be completed. Computer #3 of 10 (ID 6344) & Computer #7 of 10 (ID 13709) hasn't communicated with the project since 6/1/09, and Computer #8 of 10 (ID 14182) hasn't communicated since 5/31/09. Why are they in the top 10 if they aren't computing anything?!?!?!? I mean, I switch from Linux to my Windows partition for 2 hrs to perform some Solidworks training and I drop a position to #9 (ID 9385) compared to a computer that doesn't even perform work right now. What's the deal? Is the RAC set in concrete when you drop out of the project?!?!?! Inquiring minds are confused and PO'ed!!!! ;-)

Mike Doerner

---

The RAC should go down slowly even if the host does not contact the scheduler. I'll check the stats_update script, perhaps it's broken.

---

M4 Project homepage
M4 Project wiki

WOW! That was quick; I didn't even have time to edit my post to add another computer before you responded.....;-)

---

See anything yet? I've dropped down from about 2575 RAC to 2540 RAC because I ran my Windows partition for about 4 hours yesterday, but those 3 computers have not contributed anything and their RAC has not changed. The one guy according to DC-VAULT has fallen off the face of the earth, while the other guy is churning 100% on a different project (or rather, was. He's fallen off the earth as well.)

Mike Doerner

---

update_stats runs every 2 days. The next run is scheduled for today, around 2 hours from now.
I haven't seen any errors in update_stats output data log, so I think it works. If the RAC won't drop during next 2-4 days, then I'll start checking what's wrong.

---

M4 Project homepage
M4 Project wiki

Fair enough. We'll see what happens.

---

I think there's a bug somewhere, the stats haven't budged since 6/1/09. What if someone does not detach from a project, but suspends getting new work? I'd think as soon as they grabbed a new WU things would go down, but until then it looks like the RAC does not re-compute until new WU's are issued.

Mike Doerner

---

And as much as I hate to throw another AMD user user the bus.....Computer #11 (ID 12762) hasn't completed any work sine 6/1/2009 as well. Dang, he had a Phenom II as well....

Mike D

---

And as much as enjoy trumping an i7 processor, computer #10 (ID 13485) hasn't put up WU's since 6/2/2009, but still holds 10th place. This case is different, as he's still working on outstanding WU's, so he may just push up a bunch in a day or so. But why isn't his RAC dropping while we're waiting?

PS Same issue for Computer #2 (ID 14092) is crunching 100% on Ufluids@Home. No communication since 6/2/2009 yet he's holding on to the #2 position. He has outstanding WU's but again, if he isn't pushing up WU's today (or yesterday or the day before), why is his average not dropping?

Mike D

---

From the update_stats.cpp

// update_stats:
// Update average credit for idle users, hosts and teams.
// These fields are updates as new credit is granted;
// the purpose of this program is to decay credit of entities
// that are inactive for long periods.
// Hence it should be run about once a day at most.
//
// Also updates the nusers field of teams
//
// usage: update_stats [-update_teams] [-update_users] [-update_hosts]

#ifdef EINSTEIN_AT_HOME
#define UPDATE_INTERVAL 3600*24;
#else
#define UPDATE_INTERVAL 3600*24*4;
#endif

I'm not sure (yet) what's that update interval, I have to check the source.

for (i=1; i if (!strcmp(argv[i], "-update_teams")) {
do_update_teams = true;
} else if (!strcmp(argv[i], "-update_users")) {
do_update_users = true;
} else if (!strcmp(argv[i], "-update_hosts")) {
do_update_hosts = true;
} else if (!strcmp(argv[i], "-d")) {
log_messages.set_debug_level(atoi(argv[++i]));
} else {
log_messages.printf(MSG_CRITICAL, "Unrecognized arg: %s\n", argv[i])
}
}

I noticed the -d option, so I thought that I'll use it to get additional info. But for some reason, it crashes the program with segmentation fault...

EDIT:
I've just build fresh version of update_stats, this one works with -d 3, but it doesn't show anything useful in the output, just some unrecognized xml values while parsing project's config.xml. I ran it manually and I haven't seen any values changed after that, so I guess that it does not work.
I'll edit the source to add some more debug messages, then I'll be able to see what's going on. But it has to wait until tomorrow, it's already late and I'm almost falling asleep.

---

M4 Project homepage
M4 Project wiki

Yeah, midnight is about the right time to quit. Don't worry, it's not like those stats are gonna change by morning or something....:-D

Mike Doerner

---

Don't worry, it's not like those stats are gonna change by morning or something....:-D

Yep, you were right, nothing has changed since yesterday %-)

I'm testing debug-version of the update_stats right now. Looks like there must be a serious bug somewhere, because it doesn't even enter the main loop when I run it with -update_hosts.

---

M4 Project homepage
M4 Project wiki

I'm just glad the numbers are moving now.......:-D

We can figure out if they're right or wrong later, I'm just glad I'm not fighting "ghosts in the machine", so to speak. I'm just glad to see the people who have moved on to other projects are out of the top 10-20 positions. The true status of who's really contributing to the project should become apparent within the next few days....Cool!

Mike D

---

Update_stats works fine now, but I'm not sure why the default cutoff time is set to 3600*24*4 aka 4 days. I always thought it should be ~24 hours. I'll let it run with the default value for few days to see what will happen - I guess that 4 days is the time between recalculating RAC for inactive hosts and probably it does not affect the calculated value, just the update frequency.

---

M4 Project homepage
M4 Project wiki

Hi TJM,

Is the RAC screwed up again? The #1 computer hasn't computed anything since we ran out of agwly100's on 11/23/09, but it's still the #1 computer [AF>WildWildWest] in the list. I'm sure he'd drop down as soon as he re-sent a new work unit, but until then he's holding the #1 spot.

Mike D

---

In the top 20 computers, the ones ahead of me (I'm at #20) that haven't posted any new WU's since the restart are as follows...

#1 [AF>WildWildWest]nico4485 ID:12129
#9 Anonymous ID:2752
#10 [SG-SPEG]Kirk ID: 14027
#11 [SG-SPEG]Kirk ID: 19715
#14 [AF>WildWildWest]nico4485 ID: 12177
#19 Ludovic ID: 18756

So I should be #14, not #20 in the top computers list, except these stragglers aren't being cleared out because they're not submitting new WU's the clear out their score. FWIW.

Mike D

---

The RAC decay works, with all settings set to default. It takes few days until the RAC starts going down. This page explains how it works: http://www.boinc-wiki.info/Recent_Average_Credit

---

M4 Project homepage
M4 Project wiki

How is there a Core 2 Duo running 4000+ RAC? Seems super high to me, and most of the tasks are erroring out on download. http://www.enigmaathome.net/show_host_detail.php?hostid=3757

That's because it's a 4-core machine running multithreaded app (2 or 4 cores per app). This one is mine and there's another one with similar setup which I used for tests, but it's currently inactive.
The server didn't support multi core apps until the recent update (and probably it is not possible to keep single and multicore app under the same app version), so this host runs recompiled client which thinks that it has 2 physical CPUs. This way it avoids problems like running 4 2*CPU tasks on a quad CPU machine.

The multicore app was abandoned a while ago, the little speed increase (up to 5% if running on 4 cores compared to 4 x single core app + a little less memory used) is not worth the increased risk of trashing WU - the app is known to be unstable. It can run fine for days and then crash a whole batch of tasks, depending on what else the machine is doing.
Recently I resurrected the app for a while to check it's performance on multi-core CPUs with HT (mainly i7 series), but it's a dead end.
I also used it as a base to test CPU+GPU app, but that was an epic FAIL.

Probably the multicore support will come back with the second app (bombe simulator), because it can be compiled for a given number of CPUs, unfortunately only for linux - Windows is forced to run one per core.
For now I have no idea if it's possible to keep multi- and single-core apps under one app version; if not, then the multi core app will require special app_info and cc_config options or custom client to run.

---

M4 Project homepage
M4 Project wiki