171.64.65.55

[artoar_11]

OK sorry, i posted that before the server had finished restarting. Still problems?

Now is OK.

Thanks dvanatta

Code: Select all

[20:03:44] Preparing to commence simulation
[20:03:44] - Ensuring status. Please wait.
[20:03:50] Posted data.
[20:03:50] Initial: 0000; - Uploaded at ~76 kB/s
[20:03:50] - Averaged speed for that direction ~76 kB/s
[20:03:50] + Results successfully sent
[20:03:50] Thank you for your contribution to Folding@Home.
[20:03:50] + Number of Units Completed: 10

[20:03:50] + Sent 1 of 1 completed units to the server
[20:03:50] - Autosend completed
[20:03:54] - Looking at optimizations...
[20:03:54] - Working with standard loops on this execution.
[20:03:54] - Previous termination of core was improper.
[20:03:54] - Going to use standard loops.
[20:03:54] - Files status OK

[starkreiten]

Thanks dvanatta, it took mine too.

Dana

[dvanatta]

Awesome, sorry about the trouble, hope those QRBs worked out

-Dan

[shad0wfax]

Thanks dvanatta, it took another client kill + restart to get the send to work. (It wasn't auto-sending due to previous time-outs or something).

Code: Select all

[20:41:42] Initial: 0000; - Uploaded at ~377 kB/s
[20:41:42] - Averaged speed for that direction ~321 kB/s
[20:41:42] + Results successfully sent
[20:41:42] Thank you for your contribution to Folding@Home.
[20:41:42] + Number of Units Completed: 154

[20:41:42] + Sent 1 of 1 completed units to the server
[20:41:42] - Autosend completed

All seems to be well again, save for the loss of productivity.

[7im]

Mine sent also, after a client restart.

Thank you for the perseverance.

[codysluder]

Now it's simply hammering the collection server, which is also not allowing a transmission, but my client is finally folding on the next WU in the queue at least. (It wasn't even making progress on the 6097 WU I received until just now, and it's killing my TPF.)

Don't worry about "hammering the CS" In this case, you're dealing with 171.67.108.26 which has been off-line for a long time. It's one of those servers that needs to have it's code updated and is not functional. The error messages look bad in your log, but nothing is actually happening.

That doesn't change the issues with the main Work Server, though, so do follow up on 171.64.65.55.

[PinHead]

Don't worry about "hammering the CS" In this case, you're dealing with 171.67.108.26 which has been off-line for a long time. It's one of those servers that needs to have it's code updated and is not functional. The error messages look bad in your log, but nothing is actually happening.

So why do clients / projects still point to it? Isn't that the point of the collection servers, to collect during times of maintenance or trouble?

Had 3 90xx from different clients stuck because 64.65.55 and 67.108.26 were rejecting.

[7im]

Yes, collection servers are to collect WUs when the work server goes down. However, the v6 client and corresponding work server code broke most of the collection server functionality.

When they all get upgraded to V7, collection servers will start working again, with several improvements...

[PinHead]

Hi 7im,

So is the collection server assignment based on code in the client? the server? or the project? I'm trying to figure out why it doesn't just roll over or get configured to a collection server that has been upgraded and is truely on-line.

Hopefully there is a short answer to these questions.

[codysluder]

There are no collection that work with certain versions of the Work Server code. Both have to be upgraded, but until that happens pointing to a CS that is down is better than pointing to one that sends some data and then fails.

[PinHead]

Hi cody,

I guess my point was why does the client keep trying to go to a collection server that is known to be down ( apparently not temporarily ). It's been a bit since I folded but I seem to recall that certain IP address servers were locked to certain collection servers. I might be remembering incorrectly, but if so and the server is known to need an upgrade; then why are they mapped that way? They all ET to home.

What I was trying to understand it where the map lies, at the client, at the work server or at the collection server?

I noticed this problem much earlier than this thread started but because all of us do server maintenance on Sunday Night, I didn't post about it earler. If I understood the mechanics; I could have posted at 9 A.M. But, it was Monday morning and I thought server maintenance was just running long.

[7im]

A Work server is mapped to a collection server, and that info gets stored in each work unit.

Also both ends of the connection need to be software compatible. That's why you can't map an older WS to a newer CS.

[PinHead]

ahhh, so the work server and the collection server both need an upgrade; because you can't just point the older work server at a newer collection server. Gotcha

Thank you for taking the time to answer that 7im!

[CBT]

Somewhere this night it uploaded :

• [01:26:36] - Autosending finished units... [February 7 01:26:36 UTC]
  [01:26:36] Trying to send all finished work units
  [01:26:36] Project: 11021 (Run 0, Clone 807, Gen 10)
  
  
  [01:26:36] + Attempting to send results [February 7 01:26:36 UTC]
  [01:26:36] - Reading file work/wuresults_03.dat from core
  [01:26:36] (Read 8706481 bytes from disk)
  [01:26:36] Connecting to http://171.64.65.55:8080/
  [01:26:43] Posted data.
  [01:26:43] Initial: 0000; - Uploaded at ~1214 kB/s
  [01:26:43] - Averaged speed for that direction ~438 kB/s
  [01:26:43] + Results successfully sent
  [01:26:43] Thank you for your contribution to Folding@Home.
  [01:26:43] + Number of Units Completed: 387
  
  [01:26:46] + Sent 1 of 1 completed units to the server
  [01:26:46] - Autosend completed

Do I still get my QRB for this WU?

Corné

[7im]

Yes, but slightly less due to the delay in returning the WU.