Seti is seeing serval conditions: Connect failed - the original ACK in the connection request is either rejected (Upload Server) or lost in the traffic. The majority shows the Upload Server has been denying the connection request. HTTP Error -184 Boinc and sent the request and received the SYN/ACK so it replies with the final ACK and waits for the thread to be constructed then times out. HTTP Error -184 Boinc sends the request gets acknowledged and the thread is opened and you get a reply from the Upload Server. The Boinc Manager starts buffering the upload and then.... does not acknowlege that packet stream. this would indicate that something tromped on the first packet of the result as the upload started.
Then an upload will happen with no problem. So with some non measured overhead that are the connection requests appear to be tromped on by the Download saturation. My thinking would if a machine has one upload and the connection can be made send it. If the connection is good and the first result went fine, BTW there is another Result ready use the same connection and send it. IF in the case of some Cuda Machine there are 200 waiting results send the first 20 (and if you can identify critical due to deadlines fine) then fall back to let someone else in. Build the connection use it and release it. At 01:13 PM 7/21/2009 -0400, [email protected] wrote: >You do get some increased throughput if the problem is dropped connections >and packets, and the distributed upload servers have sufficiently better >connections, and the link has to the final upload server has sufficient >bandwidth to handle the load if the connections are carefully controlled >(i.e. pull rather than push). A TCP/IP link that is completely saturated >will have a much lower throughput than the same link that has only 70% to >80% saturation. > >jm7 > > > > David Anderson > <[email protected] > ey.edu> To > Sent by: "Lynn W. Taylor" <[email protected]> > boinc_dev-bounces cc > @ssl.berkeley.edu BOINC dev > <[email protected]> > Subject > 07/21/2009 12:54 Re: [boinc_dev] Fw: Re: Optimizing > PM uploads..... > > > > > > > > > > >It's not a strong attraction, since no projects use them. >But possible factors are: >- increased availability >- political reasons, e.g. wanting to give colleagues or > partner institutions a role (this was the original CPDN motivation) > >Increased through is a non-factor since, as you point out, >all data eventually has to get read by the (central) validator anyway. > >-- DPA > >Lynn W. Taylor wrote: > > I don't really understand the attraction to multiple, distributed upload > > servers. > >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. > > > >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
