Usually when there's upload/download issues like this I just shut BOINC down and wait for the all clear news on the main page.

"I'm trying to maintain a shred of dignity in this world." - Me

Usually when there's upload/download issues like this I just shut BOINC down and wait for the all clear news on the main page.

Or you could set Seti to No new work and crunch some other projects in the meantime.

EDIT: BTW, hi Alex! :-)

Hi Fuzzy. Yea I'll have to check to see if my EINSTEIN account is still active. I registered there but quit when I saw how much time their WUs took to process and how SETI WUs took longer because of the resource share. 8-)

"I'm trying to maintain a shred of dignity in this world." - Me

IMO, we need a better system of client/server communication here. The server should serve clients until they're finished on a strict queue issuing system. Like when you take a queue ticket in the farmacy or bank and then wait in line. The client OTOH should then wait and not nag anymore until it's its time. In the mean time, the client should display its number in the queue.

Just my 2 cents.

OK when you re-write the TCP/IP standard let us know :) The standard says first in first served.. However, ever there are just so many TCP sockets that are available to be serviced. That number is < 64,000.

OK when you re-write the TCP/IP standard let us know :) The standard says first in first served.. However, ever there are just so many TCP sockets that are available to be serviced. That number is < 64,000.

I understand that, but surely it must be possible to program a C/S system to raise above the limitations of the TCP? For instance, let's say for the sake of the argument that you issue one queue ticket to each client, you'll then have upto 64,000 clients in the queue at the same time. That's not so half bad for each server. Add to this the benefit of knowing that when you're served, you are sure to empty your stack of WU's, plus if you also know how you're doing in the waiting line, you'll probably have more patience than if you don't know anything.

So, an additional effect would be less frustration and questions like "I can't upload! What's wrong??!!???? Help!!!" Information is everything. :)

Sure, some will time out and will then need to try again, but then they'll know that it was because there was a huge queue of about 63,999 people before them in the line...

Oh sure, there are bound to be problems even in the future - no matter how we change things - but the main object is to make the system best fitted to its purpose, right? And all of us are genuinly interested in working to achieve that objective, right? At least we should support the idea of adjusting things that doesn't work very well.

I've said two times already in this thread that I beleive serving clients PER WU is a wrong approach. Logic says that a PER CLIENT approach instead would reduce the load.

And please stop your patronizing tone, CW. You've always used that towards me, and it doesn't work. I react to reason, not know-it-all sentences with three exclamation marks.

The only possible change I can see that could be made is if there are a number of WU's waiting to upload is that the single connection be left open till all the WU's are uploaded.

The only possible change I can see that could be made is if there are a number of WU's waiting to upload is that the single connection be left open till all the WU's are uploaded.

There has been many other ideas. If you search the board with the search string "zip wu's", you'll find some threads discussing what I think is a very good idea!

Would the congestion be reduced if multiple operations were performed in one session? Connect once to upload, report, and download if work needed instead of connecting to upload, connecting again to report work units, and yet again to download a unit.

It still will not change the fact that 60,000 connections have to be made to 50,000 sockets. There still be retrans and there will still be people complaining about it. It will not matter if the retrans succeed at a greater rate..

It still will not change the fact that 60,000 connections have to be made to 50,000 sockets. There still be retrans and there will still be people complaining about it. It will not matter if the retrans succeed at a greater rate..

Is this a per server number? If so would more machines help in this area? For instance if we could get 10 more servers to Berkeley would that open 500,000 more sockets? Or are the two not related? If they are not related how do we get you more sockets?

And on the zipping idea, you could SEND units out zipped but RECEIVE them unzipped in the beginning to see if that would help. At least one part of the conenction would be faster. This would also make our machines do the unzipping work instead of yours. Then if this isn't helpful enough you could add in the returning units in zip format at a later time.

Actually there are 65,536 TCP and 65,536 UDP sockets per IP address. The first 1024 are reserved and there are quite a few above 1024 assigned to specific products including BOINC.
I suggested load balancing across several servers and even offered to give them two of my E-220R's on permenant loan. I am still waiting for an answer.
It's still a matter of spending the money to get the hardware or have it donated to them. besides the servers it will require a load balancer too.
It would not help if the upload rotines had to unzip the files when they were received. That process needs to be strictly read in a packet, write out the data.