Are there bad WUs that cannot be sent? [no]

[enjay]

Hello,

I have a WU I simply cannot send. Neither from my home ADSL connection (Debian x86_64) nor from a server I copied the directory to (Debian i386, can retry quickly because of its fast upstream). On both machines, the client uploads a few megabytes and then aborts:

[19:29:38] - Ask before connecting: No
[19:29:38] - User name: n_j (Team 34361)
[19:29:38] - User ID: 6AA787CB74E5BB1F
[19:29:38] - Machine ID: 3
[19:29:38]
[19:29:38] Loaded queue successfully.
[19:29:38] Attempting to return result(s) to server...
[19:29:38] - Read packet limit of 540015616... Set to 524286976.

[19:29:38] + Attempting to send results
[19:29:38] - Couldn't send HTTP request to server
[19:29:38] + Could not connect to Work Server (results)
[19:29:38] (171.64.65.56:8080)
[19:29:38] - Error: Could not transmit unit 04 (completed January 22) to work server.
[19:29:38] - Read packet limit of 540015616... Set to 524286976.

[19:29:38] + Attempting to send results
[19:29:45] - Couldn't send HTTP request to server
[19:29:45] + Could not connect to Work Server (results)
[19:29:45] (171.64.122.76:8080)
[19:29:45] Could not transmit unit 04 to Collection server; keeping in queue.
[19:29:45] - Failed to send all units to server

As I said, I can see (traffic graph) it uploads for a few seconds, at 100 kb/s (maximum linespeed) from home and about 400 kb/s from the server. They both send the same amount of data until it aborts.

Is this a bad WU that just cannot be sent?

[7im]

Is this a bad WU that just cannot be sent?

No. WU data does not affect connectivity to Stanford. More likely the servers are just busy.


EDIT: Yes, after checking the Server Status page, that server is in Reject mode (..65.56).

[bruce]

If the WU has expired, it's possible that it will not send. The client is supposed to check the expiration date and delete the WU if it's past the deadline but you can disable that checking in your configuration, causing it to repeatedly upload forever.

Of course since the server is down right now, we already have one issue so considering a secondary issue isn't something to worry about yet. You might look back at FAHlog.txt and see when the WU was originally assigned, though.

[enjay]

The second attempt is with a different server.. it immediately aborts on the first one, but starts to send to the second (see timestamps).
I dunno but ca. 50 attempts and it aborts at the exact same spot every time? Kind of strange.

edit: the WU is not expired yet. But it will be if this goes on for 1-2 more days.

[7im]

The second attempt is with a different server...

Correct. When the Work Server is busy or offline, the client will attempt to upload the WU to the backup Collection Server (171.64.122.76).

But when a work server is offline, the collection server sees more traffic, and it is harder to connect. After reporting the problem, there isn't much more you can do but wait for the servers to come back online.

[bruce]

edit: the WU is not expired yet. But it will be if this goes on for 1-2 more days.

Server 171.64.65.56 has been in Reject status for about 4 hours. During the 24 hourse before that, it appeared to be working normally. The Pande Group is aware of the issue with server 171.64.65.56

I don't see any obvious problems with 171.64.122.76 except that it's pretty busy.

[enjay]

Thanks for all the info. The WU has been successfully sent now.
I only wanted to know if the rumors about "bad WUs" that can never be submitted that I found in some forums were true.

I still wonder how it can be that the client sends several megabytes of data until the upload process is aborted.

[7im]

...

I still wonder how it can be that the client sends several megabytes of data until the upload process is aborted.

That is a good question. Not sure why it would take several MB of data to establish a handshake, verify client identity, client type, client settings, send the WU project #, check to see if the WU is valid to upload, acknowledge validity, etc...

[brityank]

...

I still wonder how it can be that the client sends several megabytes of data until the upload process is aborted.

That is a good question. Not sure why it would take several MB of data to establish a handshake, verify client identity, client type, client settings, send the WU project #, check to see if the WU is valid to upload, acknowledge validity, etc...

7im, bruce, & enjay,

From what I've seen in my traffic logs, when the WU Server is overloaded or in Reject mode and the Collection Server refuses to accept the WU due to it's not having a record -- seems that the entire log gets uploaded and then rejected, as if the WU ID is the last thing it sent in before notifying of the failure. That may also be a result of the time needed to unpack the header, as the file is compressed before sending. Also, if it does go to the Collection Server successfully, a couple of mine have taken over 18 Hours to reflect in the Stats pages. > at some who wonder after two hours!

[7im]

...That may also be a result of the time needed to unpack the header, as the file is compressed before sending.

Good point.

...Also, if it does go to the Collection Server successfully, a couple of mine have taken over 18 Hours to reflect in the Stats pages. > at some who wonder after two hours!

Stats sites only update every 3 hours. Waiting only 2 is premature.

Please remember the collection server is just that. It collects the work unit. It acknowledges the upload so the WU doesn't expire sitting on your computer. Once the work unit is at the collection server, IIRC it does not go straight to the stats server. Some type of communication with the original work server needs to take place for the WU to be processed by the stat server. I don't know the finer points of the process, but you can see why waiting several days for credit might be considered normal, if it takes that long to get the work server back up. Still better than expired WUs.