What about gnuplot? Maybe it provides something more than xplot?

http://www.gnuplot.info/

--
Tim Sanderson, network administrator
[EMAIL PROTECTED]


-----Original Message-----
From: Bulger, Tim [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 12:14 PM
To: Sam Stickland; Matt Cable
Cc: nanog@nanog.org
Subject: RE: Analysing traces for performance bottlenecks

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: nanog@nanog.org
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]
*****************************************************************

Reply via email to