Yes, but we can reduce the polling frequency from once a minute (120 files to upload) to once every 2 hours (per project polling).
jm7 "Lynn W. Taylor" <[email protected]> wrote on 07/14/2009 01:22:32 PM: > "Lynn W. Taylor" <[email protected]> > 07/14/2009 01:22 PM > > To > > [email protected] > > cc > > [email protected] > > Subject > > Re: [boinc_dev] Optimizing uploads..... > > Absolutely correct. > > Whatever you want to tell the clients, they have to poll for it > periodically. The best you can do from the project side is "publish" > the information. > > From the client side, it has to be able to get the information, and > getting the information should not be subject to the same loading > problem that you're trying to fix. > > In other words, you can't publish "the upload server is too busy" using > the upload server. > > The client needs to poll periodically. > > -- Lynn > > [email protected] wrote: > > Yes, but, the server cannot initiate communications with the client in > > almost all cases. Once the problem starts, communications may very well be > > impossible from the client. > > > > jm7 > > > > [email protected] wrote on 07/14/2009 12:30:14 PM: > > > >> "Lynn W. Taylor" <[email protected]> > >> Sent by: [email protected] > >> > >> 07/14/2009 12:30 PM > >> > >> To > >> > >> Carl Christensen <[email protected]> > >> > >> cc > >> > >> [email protected] > >> > >> Subject > >> > >> Re: [boinc_dev] Optimizing uploads..... > >> > >> Carl, > >> > >> You're right, there are ways (by throwing resources at the problem) to > >> handle this server-side. > >> > >> ... and the reason is that typically, that's all that is possible. > >> Someone like Amazon.com can't tell Internet Explorer to slow down. > >> > >> This isn't a "must" sort of thing -- it's a huge opportunity that rarely > >> comes along! > >> > >> Amazon does not own the client and the server, they only own the server. > >> > >> BOINC owns both. > >> > >> I'm reminded of the physics "thought experiment" where you put a > >> refrigerator in a sealed room, leave the door open and turn it on. > >> > >> It's hard to figure out how the room temperature changes if you focus on > >> the refrigerator -- but it's easy if you look at the refrigerator and > >> room as a system. There is a net flow of energy into the room to run > >> the 'fridge. > >> > >> Same thing here. You can look at the servers and shaping and etc., or > >> you can look at the BOINC client/server system as a system, and tune the > >> whole system. > >> > >> -- Lynn > >> > >> Carl Christensen wrote: > >>> there are plenty of good server-side means to handle failed > >> uploads without having to fiddle with the BOINC client; I think it > >> comes back to a project needing to do some homework and take some > >> blame if they vastly underestimated number of uploads, bandwidth etc. > >>> for example, on CPDN at our peak when we had huge uploads we were > >> able to setup a round-robin DNS system so that the same upload URL > >> could go to one of three physical servers. then we used > >> mod_backhand in apache for more intelligent load balancing, then > >> simply have a bunch of upload URL's in our workunits so if one fails > >> it just goes to another one (we had 10 upload servers federated > >> around the world at one point). these server-side mechanisms to > >> deal with things are much more flexible and sensible than trying to > >> cram a "one size fits all" solution in a BOINC client. > >>> > >>> > >>> _______________________________________________ > >>> 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. > > > _______________________________________________ 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.
