What I'm trying to do is get timestamps on echo packets going out and
the timestamp on a reply coming in, very specifically, I know what the
client thinks he's looking at, what I'm trying to prove is the issue is
that he's putting 30 lbs of garbage in a 20 lb. bag (squeezing more data
down a 144k IDSL line than they should be)

The issue, without getting too much into it is that they are seeing
extremely high icmp echo reply times through the box, they are blaiming
it on the box itself, so what I'm trying to do is establish a baseline.

I'm not looking for "the answer" from you, I'm looking for examples
using DTrace on how to measure the exact times between two packets (one
request, one reply, icmp or tcp ping) essentially RTT times.

It seems that anyone I ask doesn't know how to use the network provider
to do something like this, which is why I ask, I really have no examples
to go in in this particular situation, so I can't even "teach myself"
like I usually do.

-Trish 

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2008 10:22 AM
> To: Siobhan P. Lynch
> Cc: [email protected]
> Subject: Re: [dtrace-discuss] Network Latency
> 
> Siobhan P. Lynch wrote:
> > Hiya,
> >
> >
> >
> > I'm trying to track down some throughput latency that our customer
seems
> > to be attributing to our product, I can't see what he's talking
about,
> 
> [...]
> 
> Please excuse if this is not what you want to hear:
> 
> The *first* thing you have to do to solve a problem is to understand
it.
> You might be "getting some deeper granularity" only to find out after
> having spent some time on that that your customer *actually* means
> something slightly different than you do when you speak of "throughput
> latency".
> 
> BTW: What is "throughput latency" supposed to mean? in my experience,
> throuput and latency are orthogonal concepts: throughput being the
average
> amount of data you get over a connection over time, and latency being
the
> response time to a given request.
> Have your customer clarify that first.
> 
> HTH
> Michael
> --
> Michael Schuster      http://blogs.sun.com/recursion
> Recursion, n.: see 'Recursion'

_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to