can't upload to 130.237.232.141

[Xavier Zepherious]

Code: Select all

[15:02:30] CoreStatus = 64 (100)
[15:02:30] Unit 1 finished with 79 percent of time to deadline remaining.
[15:02:30] Updated performance fraction: 0.790006
[15:02:30] Sending work to server
[15:02:30] Project: 6900 (Run 18, Clone 5, Gen 94)


[15:02:30] + Attempting to send results [March 28 15:02:30 UTC]
[15:02:30] - Reading file work/wuresults_01.dat from core
[15:02:30]   (Read 100178915 bytes from disk)
[15:02:30] Connecting to http://130.237.232.141:80/
[15:27:30] - Couldn't send HTTP request to server
[15:27:30] + Could not connect to Work Server (results)
[15:27:30]     (130.237.232.141:80)
[15:27:30] + Retrying using alternative port
[15:27:30] Connecting to http://130.237.232.141:8080/
[15:52:17] - Couldn't send HTTP request to server
[15:52:17] + Could not connect to Work Server (results)
[15:52:17]     (130.237.232.141:8080)
[15:52:17] - Error: Could not transmit unit 01 (completed March 28) to work server.
[15:52:17] - 1 failed uploads of this unit.
[15:52:17]   Keeping unit 01 in queue.
[15:52:17] Trying to send all finished work units
[15:52:17] Project: 6900 (Run 18, Clone 5, Gen 94)


[15:52:17] + Attempting to send results [March 28 15:52:17 UTC]
[15:52:17] - Reading file work/wuresults_01.dat from core
[15:52:17]   (Read 100178915 bytes from disk)
[15:52:17] Connecting to http://130.237.232.141:80/
[16:12:42] - Autosending finished units... [March 28 16:12:42 UTC]
[16:12:42] Trying to send all finished work units
[16:12:42] - Already sending work
[16:12:42] + Sent 0 of 1 completed units to the server
[16:12:42] - Autosend completed

would be a good idea to look at...
I'll wait and see if it gets thru

finally about 1 1/2r after it initially tried it uploaded

[7im]

Servers do occasionally get busy, and the the upload attempts will not be successful. The client is programmed to keep trying automatically until it does upload. We usually don't get concerned unless the WU sits for a long time. The servers usually get unbusy all by themselves later the same day or that night.

[Xavier Zepherious]

what gets me is you couldn't make a routine that checks very quickly if it's avail or not(rather than waste 25 mins trying each time)
if not then get the next WU and do it...while it continues to check and if avail gets token so they can upload (next in queue token) and then upload

as a programmer I find it odd that a better way of uploading units hasn't been considered yet

[7im]

as a programmer I find it odd that a better way of uploading units hasn't been considered yet

Consider the V7 client.

[bruce]

what gets me is you couldn't make a routine that checks very quickly if it's avail or not(rather than waste 25 mins trying each time)
if not then get the next WU and do it...while it continues to check and if avail gets token so they can upload (next in queue token) and then upload

as a programmer I find it odd that a better way of uploading units hasn't been considered yet

The question isn't so much how to deal with how the client uploads, but rather how the server deals with both congestion and with clients with a wide range if connection speeds, a few of which drop connections in the middle of an upload. When a server is saturated and there's a backlog of clients all wanting to connect, things can get out-of-hand very quickly. At any one time, there are maybe 1000 connections distributed across a number of individual servers. A client can't work on WUs from just any server; only a limited number of servers have work for your particular hardware/OS/client. Once a WU is assigned, the results will have to be delivered back to the server that's running that specific project after an unknown processing interval.

Servers and RAID arrays are expensive, especially if they're underutilized, but workloads vary and keeping them all operating somewhat below their maximum takes careful planning -- with the growth of server capacity matching the growth in demands of the clients.