RE: Analysing traces for performance bottlenecks

* Bulger, Tim · * Thu Jul 17 12:14:44 2008

There is a Java version of xplot available now called jPlot.  It works
in largely the same way.

http://www.tcptrace.org/jPlot/

Regards,
Tim

-----Original Message-----
From: Sam Stickland [mailto:[email protected]] 
Sent: Thursday, July 17, 2008 11:53 AM
To: Matt Cable
Cc: [email protected]
Subject: Re: Analysing traces for performance bottlenecks

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
*****************************************************************
This message has originated from R. L. Polk & Co.,
26955 Northwestern Highway, Southfield, MI 48033.
R. L. Polk & Co. sends various types of email
communications.  If this email message concerns the
potential licensing of a Polk product or service, and
you do not wish to receive further emails regarding Polk
products, forward this email to [email protected]
with the word "remove" in the subject line.

The email and any files transmitted with it are confidential
and intended solely for the individual or entity to whom they
are addressed.

If you have received this email in error, please delete this
message and notify the Polk System Administrator at
[email protected]
*****************************************************************