Terje Mathisen <"terje.mathisen at tmsw.no"> writes: > Rob wrote: >> But of course this is completely unreasonable. It will bring you nothing >> to use a larger window than the rate of your connection times the maximum >> roundtriptime you get for the sites you download from. And it has > > Actually, I would suggest a small amount more, as a safety margin, but > otherwise I agree. > >> disadvantages to set the window larger than that, which those websites >> usually don't explain to you. > > My personal "problem" is that I am sitting at the end of 30/30 Mbit/s > fiber connection here in Oslo, Norway: This means that I can very > easily run out of buffer space when talking to US servers: > > 200 ms ping times corresponds to 6 Mbit of data, i.e. I need about 800 > kB network buffers just to keep the pipe going, more if I want to be > able to recover from an occasional lost packet with a fast retransmit.
Bufferbloat is different that the TCP receive or transmit window size. Bufferbloat is unmanaged buffers in the software TXQUEUE, the hardware TX ring, and the device itself. The TCP layer of buffering is not what we are talking about with bufferbloat. TCP's window and amount of buffering is highly tunable, and controllable. > > In the real world I simply have to split up my SFTP/SCP/RSYNC > transfers so that I can run N of them in parallel: This gets me N > times the buffers supported (at both ends) by the underlying ssh > protocol. > >> >> What makes the situation complicated is that there could be more than >> one download going on at the same time. > > Right. :-) > > Terje -- Dave Taht http://nex-6.taht.net _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
