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
On Wed, Jan 21, 2009 at 3:49 AM, Mario Valetti
<mariov652@xxxxxxxxx> wrote:
Hi,
I was under the impression that port mirroring is supposed to
assist in troubleshooting / diagnosis of traffic on one or more ports.
The traffic is also supposed to be an exact image of that seen on the 'monitored' port.
I have some weird results that simply don't make sense...
Standard PC to PC ping using hrping gives me a roundtrip time of ~0.100ms (or 100us).
Running wireshark on the 'source' PC, monitoring the same interface
as the ping, gives me roundtrips of ~95us. A slight difference, but
nothing to write home about (perhaps due the way that wireshark or
hrping measures times).
This is where it gets strange...
Using a second nic on the 'source' PC, and port mirroring the
source interface on a switch to this secondary nic, shows a
round trip time of ~50us - A big difference.
Maybe the secondary nic is reporting this incorrectly? I then used
a separate PC to monitor the pings on the switch at the mirrored port, and this gives me the
same ~50us result.
Has anyone got any ideas why I would get different results (even
better results) from the port mirror than the original ports /
interface?
I don't see how wireshark could be a cause for these different times, but perhaps someone with more experience will be able to explain...
(I've posted this to CISCO too, so hopefully I'll get an answer there too.
Thanks.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
