On Tue, Nov 19, 2002 at 10:04:15PM +1100, Ronnie Sahlberg wrote:
> ----- Original Message -----
> From: "Pavel Mores"
>
> > I'm not sure if there's much more information to be extracted from this
> > simple type of graph. This type of graph should be used for cursory
> > examination only where the much more informative tcptrace-style graph
> > can be confusing (exactly by the sheer amount of info it contains). I
> > included this graph style because it's simple and it's used by Stevens
> > in his TCP/IP Illustrated masterworks for examining time/sequence number
> > dependencies. For a more serious analysis tcptrace-style graph should
> > be used.
> >
>
> Oh but it produces incredibly useful output to spot tcp layer problems for
> bulk transfer performance.
>
> Horizontal gaps in the graph will tell you exactly where you have
> retransmission timeouts and how long
> the timeouts are.
> This graph type can by eyeballing it for a few seconds tell you whether the
> performance
> problem lies in the TCP layer or not.
Yes, I'm not saying it's useless. Its strength is in its simplicity -
it does one or two things, and it does those things in a probably more
efficient manner than the tcptrace-style graph.
Good to know someone's actually using it. ;)
> The only problem with it is that it only works ontop of Ethernet.
> Porting it to grab data from a tap instead should fix that problem though.
The ethereal's inner workings turned out to be much too convoluted for
me to digest. When I started to write the graphing code, I thought
there would be some API in the ethereal proper that would isolate me
from the link layer. I found none so I hacked my code to support
ethernet and ppp (most common link-layers, in my view). Porting it to
other link-layers would be nice but it has to be done by someone else.
pvl