• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Project 3798?

A

APOLLO

[H]ard|DCer of the Month - March 2009
Joined
Sep 17, 2000
Messages
9,089
Has anyone else received this very weird WU? Take a look at the complete log:


[21:01:05] Project: 3798 (Run 28, Clone 4, Gen 17)
[21:01:05]
[21:01:05] Assembly optimizations on if available.
[21:01:05] Entering M.D.
[21:01:12] Protein: p3798
[21:01:12]
[21:01:12] Writing local files
[21:02:57] Extra SSE boost OK.
[21:02:57] Writing local files
[21:02:57] Completed 0 out of 1500 steps (0)
[21:03:41] Writing local files
[21:03:41] Completed 500 out of 1500 steps (33)
[21:04:21] Writing local files
[21:04:21] Completed 1000 out of 1500 steps (67)
[21:05:03] Writing local files
[21:05:03] Completed 1500 out of 1500 steps (100)
[21:05:03] Writing final coordinates.
[21:05:03] Past main M.D. loop
[21:06:03]
[21:06:03] Finished Work Unit:
[21:06:03] - Reading up to 550656 from "work/wudata_04.arc": Read 550656
[21:06:03] - Reading up to 0 from "work/wudata_04.xtc": Read 0
[21:06:03] goefile size: 0
[21:06:03] Leaving Run
[21:06:06] - Writing 573212 bytes of core data to disk...
[21:06:06] Done: 572700 -> 518444 (compressed to 90.5 percent)
[21:06:07] ... Done.
[21:06:07] - Shutting down core
[21:06:07]
[21:06:07] Folding@home Core Shutdown: FINISHED_UNIT
[21:06:09] CoreStatus = 64 (100)
[21:06:09] Sending work to server


Apparently this is some kind of code test unit worth 5 pts, I can't find any more info on it. I wouldn't have brought up a thread on a WU of little interest but for the fact that I've been folding quite a lot of these record small WUs in the past 24hrs and most of them are refusing to upload their results. Anyone know what these things are all about?? :confused:

 
i had one yesterday .. it said FINISHED_UNIT twice, and diddnt do anything for almost an hour so i closed it and restarted.... havent seen one since.. mine seemed to get stuck at the end too, hope its not a prelude to things to come.. lol

 
LOL ... that is funny ... The ghost has come back .....

Here is what happened. On October 31, 2008 (Halloween Night) some of project 3798 escaped in the wild from testing.

It is a test work unit designed to test some new server code that is being designed.

It is so small so the WU return very fast and yes it worth "5" whole points.

Stanford made a post about it on the FF but I can't seem to locate it at this time.
 
Correct, those WU aren't supposed to be public and it's only for testing the new server code. Just ignore them and let them finish.

 
HighYield said:
I didn't see any yet....and if they refuse to upload I hope it stays that way.
Click to expand...
Why? :confused:

Xilikon said:
Correct, those WU aren't supposed to be public and it's only for testing the new server code. Just ignore them and let them finish.
Click to expand...
That's part of the problem. More often than not, they refuse to upload results and stall the clients for long periods. What follows is an endless stream of messages that state the server has no record of the unit and then for some reason the client cannot contact the assignment server. Here is what generally follows:


[22:07:35] + Attempting to send results
[22:12:44] - Couldn't send HTTP request to server
[22:12:44] + Could not connect to Work Server (results)
[22:12:44] (171.64.122.139:8080)
[22:12:44] - Error: Could not transmit unit 06 (completed November 27) to work server.
[22:12:44] Keeping unit 06 in queue.

[22:12:44] + Attempting to send results
[22:13:05] - Couldn't send HTTP request to server
[22:13:05] + Could not connect to Work Server (results)
[22:13:05] (171.64.122.139:8080)
[22:13:05] - Error: Could not transmit unit 06 (completed November 27) to work server.

[22:13:05] + Attempting to send results
[22:13:11] - Server does not have record of this unit. Will try again later.
[22:13:11] Could not transmit unit 06 to Collection server; keeping in queue.
[22:13:11] - Preparing to get new work unit...
[22:13:11] + Attempting to get work packet
[22:13:11] - Connecting to assignment server
[22:13:11] - Successful: assigned to (171.64.122.139).
[22:13:11] + News From Folding@Home: Welcome to Folding@Home
[22:13:11] Loaded queue successfully.
[22:13:32] - Couldn't send HTTP request to server
[22:13:32] + Could not connect to Work Server
[22:13:32] - Error: Attempt #1 to get work failed, and no other work to do.
Waiting before retry.
[22:13:42] + Attempting to get work packet
[22:13:42] - Connecting to assignment server
[22:13:42] - Successful: assigned to (171.64.122.139).
[22:13:42] + News From Folding@Home: Welcome to Folding@Home
[22:13:42] Loaded queue successfully.
[22:14:03] - Couldn't send HTTP request to server
[22:14:03] + Could not connect to Work Server
[22:14:03] - Error: Attempt #2 to get work failed, and no other work to do.
Waiting before retry....

Anyway, since these WUs aren't supposed to be released to the public, I think I'll just stop them if I catch them right after the download. I have about half a dozen queued up results and they will likely stay that way, so there's no point in continuing to process WUs that only stall clients unless someone can give me a compelling enough reason. Fortunately, I have a certain amount of redundancy configured into my folding setups for just these sort of situations.
 
What you see is a problem with the server code. If that happens, just flush it and let it pick a different one. This is precisely the reason this WU is being used for testing the server code in a quick manner so they can debug and fix the issues.

 
You must log in or register to reply here.
Back
Top