Hi Guys,

I wonder if something can be done on the client side to increase the success rate of the result uploads.

I'm running a self compiled version of the 4.27 boinc client.
This version has the networking code built in.

I'd be willing to try some tweaks on the code if you cold give me a heads up at where to look.

(Fiddling with socket options or whatever might help)

Regards Hans

---

Hi Guys,

I wonder if something can be done on the client side to increase the success rate of the result uploads.

I'm running a self compiled version of the 4.27 boinc client.
This version has the networking code built in.

I'd be willing to try some tweaks on the code if you cold give me a heads up at where to look.

(Fiddling with socket options or whatever might help)

Regards Hans

For it to be truly effective changes would have to be made on both sides.

After thinking about this a bunch in the last few days I think the idea of zipping the results up has merit. For grins I zipped up my not so quickly uploading results and the zip file showed a 75-80% reduction in the file size. This would make the upload transmission 60-70% faster..

Course this would also mean that the validators would have to unzip them to validate the WU. Unzipping the WU should not be done by the upload receiver. All it should do is accept a packet and write out the data.

About the pinging part, as regards to CelticWolf, has anyone tried "the finger of death?"

---

Account frozen...

For it to be truly effective changes would have to be made on both sides.

After thinking about this a bunch in the last few days I think the idea of zipping the results up has merit. For grins I zipped up my not so quickly uploading results and the zip file should a 75-80% reduction in the file size. This would make the transmission 60-70% faster..

Course this would also mean that the validators would have to unzip them to validate the WU. Unzipping the WU should not be down by the upload receiver. All it should do is accept a packet and write out the data.

This would help to reduce the upload bandwith. But since we are at 3-5Mbit/s ATM I don't think zipping results would make much of a difference.

Right now I'm wondering if the client is closing the connection when uploads are failing, or if the server is closing the socket on his side.

If it's the client that errors out, there should be some possible tweaks to make it more patient.

Regards Hans

---

About the pinging part, as regards to CelticWolf, has anyone tried "the finger of death?"

It should work. He's only a low hit die monster. Maybe a 2d4 at best.

For it to be truly effective changes would have to be made on both sides.

After thinking about this a bunch in the last few days I think the idea of zipping the results up has merit. For grins I zipped up my not so quickly uploading results and the zip file should a 75-80% reduction in the file size. This would make the transmission 60-70% faster..

Course this would also mean that the validators would have to unzip them to validate the WU. Unzipping the WU should not be down by the upload receiver. All it should do is accept a packet and write out the data.

This would help to reduce the upload bandwith. But since we are at 3-5Mbit/s ATM I don't think zipping results would make much of a difference.

Right now I'm wondering if the client is closing the connection when uploads are failing, or if the server is closing the socket on his side.

If it's the client that errors out, there should be some possible tweaks to make it more patient.

Regards Hans

If a TCP Listener doesn't respond in a very short time the request is lost. Holding the request open longer will not accomplish much.

It is true that bandwidth is not being used up, but system resources are. The file upload scripts are CGI (being converted to fastcgi). The sooner that the CGI script is freed the quicker the next upload can begin. If the WU was zipped up then the file upload CGI would be freed faster.

If a TCP Listener doesn't respond in a very short time the request is lost. Holding the request open longer will not accomplish much.

It is true that bandwidth is not being used up, but system resources are. The file upload scripts are CGI (being converted to fastcgi). The sooner that the CGI script is freed the quicker the next upload can begin. If the WU was zipped up then the file upload CGI would be freed faster.

Hmm....

So the chances that something can be done in the client code are not too good.
I'm still seeing upload traffic from time to time here.
I'll try some poking around with ethereal to see if I'm actually uploading data.

According to Scarecrow's stats there have been 250 successful uploads during the last hour for _all_ seti.

The "work in progress" is climbing fast. The seti servers are in self destruction mode right now.
If the number of results in progress, and the number of files on the servers, continue to climb steadiliy something will break sooner or later.

Regards Hans

---

If a TCP Listener doesn't respond in a very short time the request is lost. Holding the request open longer will not accomplish much.

It is true that bandwidth is not being used up, but system resources are. The file upload scripts are CGI (being converted to fastcgi). The sooner that the CGI script is freed the quicker the next upload can begin. If the WU was zipped up then the file upload CGI would be freed faster.

Hmm....

So the chances that something can be done in the client code are not too good.
I'm still seeing upload traffic from time to time here.
I'll try some poking around with ethereal to see if I'm actually uploading data.

According to Scarecrow's stats there have been 250 successful uploads during the last hour for _all_ seti.

The "work in progress" is climbing fast. The seti servers are in self destruction mode right now.
If the number of results in progress, and the number of files on the servers, continue to climb steadiliy something will break sooner or later.

Regards Hans

If you are speaking of the .28KB nope you are not.. If you are talking about an actual finished upload you are..

From the front page:

December 9, 2005
We have turned off work distribution for a bit to allow result uploads to catch up. We will be extending the deadline for returning results so that the troubles with the result upload handler will not result in lost credit.

Way to go :o)

Now all we have to do is twiddle our thumbs and wait for things to pick up speed again.


Regards Hans

---

SETI....now powered by an Ion drive, it's not fast at first, but it gathers momentum.

From the front page:

December 9, 2005
We have turned off work distribution for a bit to allow result uploads to catch up. We will be extending the deadline for returning results so that the troubles with the result upload handler will not result in lost credit.

Way to go :o)

Now all we have to do is twiddle our thumbs and wait for things to pick up speed again.


Regards Hans

That's what we'd think and what they'd like to think. However I am not convinced yet, I will only be convinced if they turned of the Scheduler full stop (or everything picks itself up quite quickly).

---

That's what we'd think and what they'd like to think. However I am not convinced yet, I will only be convinced if they turned of the Scheduler full stop (or everything picks itself up quite quickly).

Looks like they did:

2005-12-10 08:09:53 [SETI@home] Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed
2005-12-10 08:09:53 [SETI@home] Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed
2005-12-10 08:09:53 [SETI@home] No schedulers responded
2005-12-10 08:09:53 [SETI@home] No schedulers responded
2005-12-10 08:09:53 [SETI@home] Deferring communication with project for 23 minutes and 15 seconds
2005-12-10 08:09:53 [SETI@home] Deferring communication with project for 23 minutes and 15 seconds

Regards Hans

---

I think I'd agree now. If I check http://boincprojectstatus.ath.cx/SS_SETI@Home.html, I see that Scheduler is down, Downloads are all green and Uploads are not perfect but changing slowly.

The graphs are slightly more revealing.

---

This would help to reduce the upload bandwith. But since we are at 3-5Mbit/s ATM I don't think zipping results would make much of a difference.

Regards Hans

I have proposed zipping days ago and I think it will be a big difference for Berkeley's servers side, not for user's side.
Also my proposal was to reduce timeout from 3-4 minutes to 20 seconds.

Bye,
Francesco

---

Have been looking at the "attempts" to upload results for the past day with Ethereal. Last night and today, all I was seeing was the three-way handshake establishing the connection, and then nothing. No data being transfered. Matches what the Berkeley Seti Staff are saying, the server is dropping connections.

However, this three-way handshake was occurring on every attempt.

Tonight, sometimes I now see three (SYN) sent by the client, followed by a (RST) from the server and nothing happens. Which I assume is a no connection, go away.

Tonight in some cases, after a few seconds, the client is now sending a Continuation packet with one data byte (50). And that does not get a response.

In other attempts, after the connection is established, the server does make what looks like the start of a transfer request (SYN,ACK ACK=1 MSS=1460) and the client responds with (ACK), ACK=3959499169. The server responds to this with a (RST) to reset the sequence number. No response from the client. Three seconds later the server repeats its (SYN,ACK ACK=1 MSS=1460) and the client responds with (RST), and nothing happens after that.

But tonight, there was a change in what I had been seeing, and the rate of successful uploads seems to have dropped even more.

Someone with experience with Ethereal and looking at the Seti upload sequence needs to look at it and tell us what this means. I very seldom have reason to look dig out Ethereal, much less dig down into the packets.

[quote]
According to Scarecrow's stats there have been 250 successful uploads during the last hour for _all_ seti.
/quote]

Update:
-2515 in 1h and half and -883 in the last 20 minutes.
UL's speed is growing, from 28 UL per minute to 44.

Bye,
Francesco

---

[quote]
According to Scarecrow's stats there have been 250 successful uploads during the last hour for _all_ seti.
/quote]

Update:
-2515 in 1h and half and -883 in the last 20 minutes.
UL's speed is growing, from 28 UL per minute to 44.

Bye,
Francesco

===========
at present time (last stats as of 10 Dec 2005 19:20:07 UTC) Berkeley is receiving about 30 ULs per minute (during last 9h and 29min).
Is this is a linear process, we need 86 days to end the job.
I think that for a long time (weeks) it will be linear ad only near the end will accellerate.

Better to change strategy.

Bye,
Francesco

---

Check this out.

---

Account frozen...

Check this out.

I'm not an expert in communication devices and controll but ...
.... it doesn't seems a network utilization problem.

Bye,
Francesco

---

Check this out.

I'm not an expert in communication devices and controll but ...
.... it doesn't seems a network utilization problem.

Bye,
Francesco

Bandwidth is NOT the only resource being used here. System respources are being used too.. You can have all the bandwidth in the world, but it will be useless if the system runs out of resources.

Things are slowly improving..