Project: 6077 (Run 0, Clone 104, Gen 71)

[sswilson]

Code: Select all

[13:48:20] Project: 6077 (Run 0, Clone 104, Gen 71)
[13:48:20] 
[13:48:20] Assembly optimizations on if available.
[13:48:20] Entering M.D.
[13:48:26] Completed 0 out of 500000 steps  (0%)
[13:54:58] Completed 5000 out of 500000 steps  (1%)
[14:01:30] Completed 10000 out of 500000 steps  (2%)
[14:08:03] Completed 15000 out of 500000 steps  (3%)
[14:14:38] Completed 20000 out of 500000 steps  (4%)
[14:21:09] Completed 25000 out of 500000 steps  (5%)
[14:27:39] Completed 30000 out of 500000 steps  (6%)
[14:34:12] Completed 35000 out of 500000 steps  (7%)
[14:40:41] Completed 40000 out of 500000 steps  (8%)
[14:47:11] Completed 45000 out of 500000 steps  (9%)
[14:53:42] Completed 50000 out of 500000 steps  (10%)
[15:00:15] Completed 55000 out of 500000 steps  (11%)
[15:06:47] Completed 60000 out of 500000 steps  (12%)
[15:13:18] Completed 65000 out of 500000 steps  (13%)
[15:19:47] Completed 70000 out of 500000 steps  (14%)
[15:26:19] Completed 75000 out of 500000 steps  (15%)
[15:32:44] Completed 80000 out of 500000 steps  (16%)
[15:39:18] Completed 85000 out of 500000 steps  (17%)
[15:45:48] Completed 90000 out of 500000 steps  (18%)
[15:52:19] Completed 95000 out of 500000 steps  (19%)
[15:58:51] Completed 100000 out of 500000 steps  (20%)
[16:05:23] Completed 105000 out of 500000 steps  (21%)
[16:11:52] Completed 110000 out of 500000 steps  (22%)
[16:18:25] Completed 115000 out of 500000 steps  (23%)
[16:24:55] Completed 120000 out of 500000 steps  (24%)
[16:31:26] Completed 125000 out of 500000 steps  (25%)
[16:37:58] Completed 130000 out of 500000 steps  (26%)
[16:44:30] Completed 135000 out of 500000 steps  (27%)
[16:50:59] Completed 140000 out of 500000 steps  (28%)
[16:57:33] Completed 145000 out of 500000 steps  (29%)
[17:04:03] Completed 150000 out of 500000 steps  (30%)
[17:10:38] Completed 155000 out of 500000 steps  (31%)
[17:17:08] Completed 160000 out of 500000 steps  (32%)
[17:23:40] Completed 165000 out of 500000 steps  (33%)
[17:30:11] Completed 170000 out of 500000 steps  (34%)
[17:36:43] Completed 175000 out of 500000 steps  (35%)
[17:43:12] Completed 180000 out of 500000 steps  (36%)
[17:49:44] Completed 185000 out of 500000 steps  (37%)
[17:56:18] Completed 190000 out of 500000 steps  (38%)
[18:02:49] Completed 195000 out of 500000 steps  (39%)
[18:09:25] Completed 200000 out of 500000 steps  (40%)
[18:15:58] Completed 205000 out of 500000 steps  (41%)
[18:17:29] CoreStatus = C0000005 (-1073741819)
[18:17:29] Client-core communications error: ERROR 0xc0000005
[18:17:29] Deleting current work unit & continuing...
[18:17:41] - Preparing to get new work unit...
[18:17:41] Cleaning up work directory
[18:17:41] + Attempting to get work packet
[18:17:41] Passkey found
[18:17:41] - Connecting to assignment server
[18:17:43] - Successful: assigned to (171.64.65.54).
[18:17:43] + News From Folding@Home: Welcome to Folding@Home
[18:17:44] Loaded queue successfully.
[18:17:50] + Closed connections
[18:17:55] 
[18:17:55] + Processing work unit
[18:17:55] Core required: FahCore_a3.exe
[18:17:55] Core found.
[18:17:55] Working on queue slot 09 [November 26 18:17:55 UTC]
[18:17:55] + Working ...
[18:17:55] 
[18:17:55] *------------------------------*
[18:17:55] Folding@Home Gromacs SMP Core
[18:17:55] Version 2.22 (Mar 12, 2010)
[18:17:55] 
[18:17:55] Preparing to commence simulation
[18:17:55] - Looking at optimizations...
[18:17:55] - Created dyn
[18:17:55] - Files status OK
[18:17:56] - Expanded 1762307 -> 2247349 (decompressed 127.5 percent)
[18:17:56] Called DecompressByteArray: compressed_data_size=1762307 data_size=2247349, decompressed_data_size=2247349 diff=0
[18:17:56] - Digital signature verified
[18:17:56] 
[18:17:56] Project: 6077 (Run 0, Clone 104, Gen 71)
[18:17:56] 
[18:17:56] Assembly optimizations on if available.
[18:17:56] Entering M.D.
[18:18:02] Completed 0 out of 500000 steps  (0%)
[18:24:32] Completed 5000 out of 500000 steps  (1%)
[18:31:05] Completed 10000 out of 500000 steps  (2%)
[18:37:31] Completed 15000 out of 500000 steps  (3%)
[18:44:05] Completed 20000 out of 500000 steps  (4%)

Client-core communications error: ERROR 0xc0000005 after 41%.

CPU is OC'd, but has been folding fine for several weeks without any problems. Rig is running SMP2 + 2X GPU3.

What I'm most curious about is the fact that it claimed to be "deleting" the WU, but then picked up the exact same one. I could understand the WU still being available on the server if it had errored immediately, but this is 5 1/2 hours later............

I'll let it run and report back if it errors at the same place.

[codysluder]

Deleting a WU means that the client was not able to upload any results. This frequently leads to the WU being reassigned.

Was it deleted intentionally by someone who just didn't like that WU? Was the error a corruption during the original download? Was it due to an instability in your computer? Was it a random fluke of some other kind during processing? Was it due to and instability implied by the original data?

You know the answer to the first question but the server doesn't, and nobody knows for sure about any of the others. If it was any of the first four, it makes sense to reassign it. The server can't guess if it's the last one or not.

[sswilson]

That theory doesn't work in this case as the server doesn't know that it's been dumped, and as such shouldn't be re-assigning it until after the deadline which will still be more than a day off by the time my machine turns it in.

Something has been done to the clients which keeps a hidden record of "current" WUs which is why deleting the queue / unit info / work folder no longer works for getting a different WU. Maybe it was done to hinder the cherry pickers, but in cases like this it causes those of us who are playing by the rules to question why we keep getting the same possibly bad WU.

[bruce]

That theory doesn't work in this case as the server doesn't know that it's been dumped, and as such shouldn't be re-assigning it until after the deadline which will still be more than a day off by the time my machine turns it in.

Something has been done to the clients which keeps a hidden record of "current" WUs which is why deleting the queue / unit info / work folder no longer works for getting a different WU. Maybe it was done to hinder the cherry pickers, but in cases like this it causes those of us who are playing by the rules to question why we keep getting the same possibly bad WU.

The Pande Group doesn't provide an explanation of why FAH works the way it does. I certainly can see your point.

I'n not sure if the logic is meant to thwart cherrypickers or not, but how is a server to know? For the moment, let's assume that's the only reason. If a person who plays by the rules tells the server "I'm not a cherrypicker; give me something else." don't you think that the real cherrypickers would have their client tell the server exactly the same thing? I can't think of a rational way to distinguish. Can you?

[sswilson]

Heh... I wasn't really complaining, more just commenting on what I've noticed WRT failed units and PCs going to sleep lately.

That said... if it is an attempt to thwart the cherry pickers, it's not very effective as it seems all that's required to get a new WU is to change the machine ID......

[toTOW]

Here's why you got the same WU again :

- when the WU errored, it got deleted, but not reported to the server that it did.
- since the server doesn't know you got an error, it thinks that 1) your deleted the WU on purpose (naughty boy ) or 2) there has been an error somewhere that lead to deletion (but it might also be corruption, instabilities dues to OC or anything like that)
- to make sure that the problem is not on your machine, the server sends the same WU again (usually up to 5 times before considering it as definitely lost and moving to another one)

This is a safety that the researcher can set on his projects (in the first days of GPU2, it was usually set to 5 attempts (which triggered client pause ), and on SMP2, 3 attempts if my memories are correct).

By the way, you finally completed the WU you reported :
Hi sswilson (team 54196),
Your WU (P6077 R0 C104 G71) was added to the stats database on 2010-11-26 21:05:04 for 2551.71 points of credit.

[sswilson]

Yep, finished late last night.

Follow up question:

In a case like this, where it's a time based "bonus" WU, am I correct in assuming that the calculation is based on when the second attempt started rather than when the WU was initially downloaded?

I had always thought that the calculation would be based on the initial download, but looking at the points I was awarded for completing it the second time around, I suspect that's not the case. The points you quoted for me appear to be in line with what I'd expect from a "fresh" WU. (Somewhere around 2 non-6701/6702 WUs per day for aprox. 5K+ ).

[toTOW]

The calculation should start over from the latest assignment of the WU and it apparently succeeded since you got the right bonus.

[sswilson]

Thanks for the info. Learned something new today, and even better, it takes some of the sting out of the occasional WU error resulting in running the same one over again.