> traceroute www.kernel.org
traceroute to linux.kernel.org (206.184.214.34), 30 hops max, 40 byte
packets
1 vacumatic.cac.washington.edu (128.95.2.100) 0.984 ms 0.804 ms 0.724
ms
2 uwbr2-FE0-1-0.cac.washington.edu (140.142.150.24) 0.993 ms 0.696 ms
0.686 ms
3 seatr1-fste.nwnet.net (204.200.8.3) 1.896 ms 1.952 ms 2.155 ms
4 166.48.205.253 (166.48.205.253) 2.884 ms 37.041 ms 4.607 ms
5 bordercore1.SanFrancisco.mci.net (166.48.12.1) 16.472 ms 16.353 ms
16.206 ms
6 best-internet.SanFrancisco.mci.net (166.48.13.250) 18.113 ms 18.531
ms 18.170 ms
7 core1-hssi8-0-0.mv.best.net (206.86.228.89) 20.636 ms 22.492 ms
20.951 ms
8 core2-fddi0-0.mv.best.net (206.184.188.2) 21.048 ms 21.633 ms
20.628 ms
9 transmeta-T1-gw.mv.best.net (206.86.229.194) 358.965 ms 423.744 ms
381.311 ms
10 linux.kernel.org (206.184.214.34) 252.813 ms 240.786 ms 212.991 ms
--- linux.kernel.org ping statistics ---
74 packets transmitted, 73 packets received, 1% packet loss
round-trip min/avg/max = 167.9/346.2/527.8 ms
It makes sense that you'd see a 300-400ms q-ing delay over a busy T1,
since it takes (1500*8b)/(1.5Mb/s) = 8ms to send a full-sized TCP segment,
so a queue of 50 packets will lead to a 400ms q-ing delay. And long queues
are not surprising, with dozens of people downloading huge kernel source
trees - dozens of TCP flows each trying to drive the queues to loss.
Seems like this is exactly the kind of situation that needs a smarter TCP
(vegas) or a traffic shaper.
neal