Re: Analysing traces for performance bottlenecks

[Sam Stickland <sam_mailinglists () spacething org>]

Matt Cable wrote:
> Kevin Oberman <oberman <at> es.net> writes
> > tcptrace is old and pretty basic, but it can provide a LOT if
> > information. Combined with xplot, the graphs often point to the exact
> > nature of a TCP problem, but you need a really good understanding of TCP
> > to figure anything out.
> >     
>
> Wireshark also provides tcptrace-like graphs ("Statistics -> TCP Stream Graph ->
> Time Sequence Graph (tcptrace)").  They're not quite as pretty, but are just as
> effective at tracking down all sorts of TCP problems, provided, as Kevin said,
> you have a really good understanding of how TCP behaves

Thanks for all the replies so far. While the TCP graphs are useful they 
are very difficult to read in Wireshark - they really need to be 
displayed in xplot, but this requires an X11 setup?

I've found NDT:

http://e2epi.internet2.edu/ndt/

This uses a java applet hosted on a web100 patched linux server to 
record network diagnostics from connecting clients. A typical report 
might look like this:

   Web100 reports the Round trip time = 122.15 msec; the Packet size = 
1260 Bytes; and
   No packet loss was observed.
   C2S throughput test: Packet queuing detected: 1.09%
   S2C throughput test: Packet queuing detected: 1.32%
   This connection is receiver limited 84.33% of the time.
     Increasing the the client's receive buffer (63.0 KB) will improve 
performance
   This connection is sender limited 1.70% of the time.
     Increasing the NDT server's send buffer (127.0 KB) will improve 
performance
   This connection is network limited 13.96% of the time.

   The theoretical network limit is 7869.69 Mbps
   The NDT server has a 127.0 KByte buffer which limits the throughput 
to 16.37 Mbps
   Your PC/Workstation has a 63.0 KByte buffer which limits the 
throughput to 4.09 Mbps
   The network based flow control limits the throughput to 8.73 Mbps

   Client Data reports link is 'OC-48', Client Acks report link is 'OC-12'
   Server Data reports link is 'OC-48', Server Acks report link is 'T3'

Something that could provide a similar, automated analysis of a TCP 
stream capture is what I'm after, although I doubt a standard packet 
capture will be able to provided as many metric as web100 stack can.

Sam