On Sat, Apr 7, 2012 at 2:49 PM, Fred Baker <[email protected]> wrote: > > On Apr 7, 2012, at 11:50 AM, Dave Taht wrote: > >> http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html >> >> 64-256k seems about right but the math is eluding me this morning. > > For a 5 MBPS data stream, Path MTU = 1460, 100 ms RTT, you're looking at > > rate in bps rtt in microseconds > cwnd_limit = ceiling ( ----------- * ------------------- ) > 8*pmtu 1e6 > > 5e6 100 e 3 > = ceiling ( ------ * ------------------- ) > 8*1460 1e6 > > = ceiling ( 428 * 0.100 ) > > = 43 > > you probably want to bump that by one or two to account for 43*40 bytes of IP > and TCP headers. > > 43*1460 is 62780 bytes per RTT, which is frightfully close to 65K bytes per > RTT, 524,280 bits per RTT, or 5,242,800 bits per second with the stated RTT. > Hmmm. > > Speaking strictly for myself, I would throw in one caveat, which is that a > variable bit rate codec that averages 5 MBPS sometimes sends faster, and > there may be good reason to allow it to. I think I'd recalculate for 6 MBPS > on average, and carefully insert the RTT I cared about into the calculation. > Doing that also accounts for the Mathis formula, which is far more complex > and requires a lot more assumptions, but will come up with a number below 6 > MBPS for a .1% loss rate.
In my case I'm 196ms away and running this for the past hour or so vlc -6 http://pannekake.samfundet.no:3015/ seems to show it never really getting out of slow start. Regrettably my favorite graph crashes xplot (grr)... so I can't see the canonical bloat pattern or not. Could be a problem in my lab (but the udp stream is ok), am checking now... Captures are up here: http://huchra.bufferbloat.net/~d/captures/gathering/pannekake_3015.cap -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
