A few more comments on other parts of this note. BFI (in any context): Brute Force and Ignorance. I believe it's usually referred to as BFBI (Brute Force and Bloody Ignorance) in the U.K.
In other words, you tweak, and you measure, and you see, instead of trying to rigorously calculate. I don't think we can do an experiment throttling from the client side: if you only accept some number of downloads, those other connections to download still come in, and you still have the overhead of processing the connections. You might be able to filter just some IP blocks in the router (and block everything else) so that the server only sees a subset, and doesn't even see the SYN packets for filtered use. But I'm not convinced. Also, you're thinking router buffer space, and I'm thinking server TCP Control Blocks -- but I don't really care what we're optimizing, we're optimizing the system. We've got a "drain" at the server side, and a set of taps at the client side. If we turn on too many taps, the floor gets wet, and I don't care if it's the pipe between the clients and the server, the basin, or the drain. Martin wrote: > Lynn W. Taylor wrote: >> I think the first step is to get the ability to tune clients, and then >> experimentally determine how to optimally tune clients. > > That's fine for controlling the uploads. > > You also need to fix the servers to avoid saturating for downloads. > > Note also that there is no "broadcast" available. Boinc is strictly > "pull" technology, There is no "push" to 'broadcast' with. > > You could include something in the response to the clients. However, > minimum system change seems to be the modus operandi... > >> That's where the BFI method comes in. I know from long experience >> running mail servers that you can often speed up throughput by reducing >> sessions. > > BFI? What's that in this context? > > > Note that, using a retry protocol such as tcp, link bandwidth is > effectively reduced when you hit the link maximum data rate. The retries > then DOS the link with repeated data so that you get a critical sudden > cut-off to ever more degraded performance. Depending on the proportion > of overload and the failed connections timeouts, you can bring a link to > near zero effective bandwidth. > > Reducing the number of simultaneous connections accepted will ofcourse > help that and will in effect increase the available bandwidth 'seen'. > > The real problem is still that you randomly loose a proportion of the > data on the overloaded link, and then suffer the fallout from that. > > To avoid data loss (and so avoid the expensive and wasteful retries, > whether at the tcp level or at the higher application level), you must > contrive the data rates so that you never exceed the router buffer space > at the slowest point on the network. > > Hence, for "bursty" data, you can never achieve 100% utilisation. The > cricket graphs for s...@h show a max of about 90Mb/s. So about 90% of that > (about 81Mb/s or rounded to 80% of the 100Mb/s) should give loss-free > and reliable operation to maintain maximum data transfer rates. > > Hit 81% (or whatever the critical point is for the router buffer > overflow and dropping packets), and the retries will bomb you down to > something less than 81%. The retries from the other connections > subsequently affected then continue a cascade into a disgraceful > degradation where you get an ever increasing proportion of retries. The > proportions are limited by the connection retry limits/timeouts. > > You still loose an awful lot of bandwidth. Far far more than if you were > to "waste" a few percent to deliberately keep the link unsaturated. > > Hence, you must keep for a rolling average for min router buffer time > that is: > > connections * connection_bandwidth < link_max_bandwidth > > Or... You suddenly hit data loss and a disgraceful degrade. > > >> Your "one fast upload" scenario has one saving grace: it's fast, it's >> going fast, it won't last long -- the faster it goes, the sooner it is > > It won't last long only if it can get through unimpeded. > > If it bungs up the pipe, it and everyone else descends into a flood of > retries and then nothing gets through, ever, until everyone hits their > tcp retry limits and give up. > > Other new connections then jump in again. > > >> gone. As long as we're operating at a reasonable load, that is -- >> different story when we're overloaded by an order of magnitude. > > Do not confuse a DDOS of *new* connections with what I think is > happening for s...@h of simply a data amplification overload that then > saturates and effectively degrades the link capacity. > > > My present view is that a *combination* of restricting the number of > connections serviced, AND restricting the permitted data rates is needed. > > > The number of simultaneous connections that can be permitted to be > serviced without any data rates limiting is really surprisingly low > compared with "website mentality" that is to serve thousands of > simultaneous connections. > > As an experiment, can s...@h limit the max number of simultaneous > upload/download connections to see what happens to the data rates? > > I suggest a 'first try' max simultaneous connections of 150 for uploads > and 20 for downloads. Adjust as necessary to keep the link at an average > that is no more than just *80* Mbit/s. > > > Aside: For example I've got uploads limited to just 200kb/s so that my > upload link is never DOSed by Boinc. > > Plausible? > > Regards, > Martin > _______________________________________________ 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.
