Thank you for taking the time to answer.
The fact that a different system shows the same RTT's on the port mirror confirms what you say.
I realise the times mentioned are very small (almost insignificant), but I originally expected the values to be the same.
Thanks again,
Mario
------------------------------
Message: 5
Date: Wed, 21 Jan 2009 12:34:40 +1100
From: Martin Visser <martinvisser99@xxxxxxxxx>
Subject: Re: [Wireshark-users] Wireshark & Port Mirroring Confusion
To: Community support list for Wireshark
<wireshark-users@xxxxxxxxxxxxx>
Message-ID:
<b3739b0c0901201734v3c622724q2e64edd7c65e147a@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
I think the answer is probably self-explantory when you think about it.
Firstly a RTT of 0.1 ms is very small. To expect a timestamp resolution at
this level, is actually pretty difficult (and in fact I don't you get much
better than about 20ms on a Windows box). I am actually surprised you even
can trust a resolution less than 1ms, as I thought the Linux "tick" or "Hz"
value was no faster than 1000. This means that interrupts aren't processed
more often than 1000 times a second, or every 1ms. But maybe I am wrong
about that. (I am normally concerned about WAN performance issues so
anything much less than 50ms doesn't interest me).
Secondly, the port mirror is basically a function where the switch is
sending an extra copy of the monitored traffic to the monitor port. Thus the
switch sees and copies your request a non-zero time *after* your PC sends
it, and copies the response *before* it reaches your PC. The switch needs to
calculate frame check sequence and as well as determine the correct output
port. So if both PCs you are pinging between are on the same switch, then
the switch is infact in the middle. So I would expect it to have a different
time, and probably going to be smaller. Also as far as I know, no vemdor,
Cisco including, makes any specification of how well it preserves timing of
port mirror data. In fact, if you monitor multiple ports simulateously, it
*will* have to interleave data (if it on the monitored ports packets are
received at the same time), and hence timing will be different.
I wouldn't consider this a bug, more you are seeing the effects of the
actual function in real-time.
Regards, Martin
MartinVisser99@xxxxxxxxx
