Bloat list:<br><br>I note that yesterday's problem with the long period latency swings was narrowed down to a bad card or connector in the chassis, and that fiber connection has been disabled.<br><br>I've got packet captures covering a goodly percentage of the universe now (thanks to the hard work of the cc'd).... and occasionally I do things like checking ipv6 vs ipv4 performance going internationally so as to have a reference later.<br>
<br><a href="http://gathering-edge.bufferbloat.net/~d/california/california_46compete-3.svg" target="_blank">http://gathering-edge.bufferbloat.net/~d/california/california_46compete-3.svg</a><br><br>Interesting about the ping part of the plot - there seems to be some classification on the link, and it's neat<br>
that BE traffic stops (packet loss there), that the EF traffic has got a different RTT than the BK (CS1) traffic (which is the lowest latency of the bunch!!!) , and that ipv6 has lower latency than ipv4 on this path(s). (duh)<br>
<br>as for the periodic bits of long period TCP changes, darned if I know... that's what I have packet captures for.<br clear="all"><br>you can see some sort of major packet loss event at T+168 or so here:<br><br><a href="http://gathering-edge.bufferbloat.net/~d/california/california_46compete-long-3.svg">http://gathering-edge.bufferbloat.net/~d/california/california_46compete-long-3.svg</a><br>
<br>As to where it occurred, well, darn it,  "mtr" was part of the rrul spec and haven't got around to integrating it.<br><br>Anyway, another long period 6vs4<br><br><a href="http://gathering-edge.bufferbloat.net/~d/california/california_46compete-long-600.svg">http://gathering-edge.bufferbloat.net/~d/california/california_46compete-long-600.svg</a><br>
<br><br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>