This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.
Differences between revisions 5 and 12 (spanning 7 versions)
Revision 5 as of 2006-03-30 01:38:42
Size: 1784
Editor: UlfLamping
Comment:
Revision 12 as of 2008-04-12 17:51:23
Size: 2162
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Ethereal just gets its timestamp from libpcap/WinPcap, and libpcap/WinPcap gets it from the packet capture mechanism it uses; Ethereal itself doesn't generate the time stamp, so there's nothing Ethereal can do about it. Wireshark just gets its timestamp from libpcap/WinPcap, and libpcap/WinPcap gets it from the packet capture mechanism it uses; Wireshark itself doesn't generate the timestamp so there's nothing Wireshark can do about it.
Line 4: Line 4:
How the time stamp works is OS dependent. In some UNIXes, that code is in the network drivers; it's higher up in the networking code path in other UNIXes. In Windows, with WinPcap, it's done by the WinPcap driver. How the timestamp works is OS dependent. In some UNIXes that code is in the network drivers; it's higher up in the networking code path in other UNIXes. In Windows, with WinPcap, timestamping is done by the WinPcap driver.
Line 6: Line 6:
Note also that the time stamp on a packet isn't a high-accuracy measurement of the instant the first bit, or the last bit, of the packet arrived at the network adapter; there's a delay between the arrival of that last bit and the interrupt for the packet, and a delay between the interrupt handling starting and the point in the code path where the time stamp is attached to the packet. Another issue might be if the OS delivers multiple packets per interrupt. This can be because the OS does "polling" or otherwise arranges that one interrupt be delivered for a batch of packets to reduce interrupt-handling overhead. If that's the case, the timestamps might be the same for multiple packets, at least to the resolution of the timestamping routine.

Note also that the timestamp on a packet isn't a high-accuracy measurement of when the first bit or the last bit of the packet arrived at the network adapter; there's a delay between the arrival of that last bit and the interrupt for the packet and a delay between the start of interrupt handling and the point in the code path where the timestamp is attached to the packet.
Line 9: Line 11:

It'
s the resolution of whatever clock is being used. It might not be the "PC clock" because it might not be running on a "PC", either in the sense of machines sold as "personal computers" or in the sense of "IBM-compatible personal computer". Some of those machines might have better high-resolution timers than IBM-compatible PCs do - at least some OSes on more modern IBM-compatible PC's use the RDTSC instruction, if present on the processor, to get higher-precision time stamps.
The timestamp has the resolution of whatever clock is being used. The clock might not be the "PC clock" because it might not be running on a "PC", either in the sense of machines sold as "personal computers" or in the sense of "IBM-compatible personal computer". Some of those machines might have better high-resolution timers than IBM-compatible PCs do - at least some OSes on more modern IBM-compatible PC's use the RDTSC instruction, if present on the processor, to get higher-precision timestamps.
Line 14: Line 15:
== Discussion== == Discussion ==
That's the usual discussion about this might be / this could be / this will be / and so on.
Line 16: Line 18:
That's the usualy discussion about this might me / this could be / this will be / and so on.

Please put some hard facts here ...
Please put some hard facts here ...

Timestamps

Wireshark just gets its timestamp from libpcap/WinPcap, and libpcap/WinPcap gets it from the packet capture mechanism it uses; Wireshark itself doesn't generate the timestamp so there's nothing Wireshark can do about it.

How the timestamp works is OS dependent. In some UNIXes that code is in the network drivers; it's higher up in the networking code path in other UNIXes. In Windows, with WinPcap, timestamping is done by the WinPcap driver.

Another issue might be if the OS delivers multiple packets per interrupt. This can be because the OS does "polling" or otherwise arranges that one interrupt be delivered for a batch of packets to reduce interrupt-handling overhead. If that's the case, the timestamps might be the same for multiple packets, at least to the resolution of the timestamping routine.

Note also that the timestamp on a packet isn't a high-accuracy measurement of when the first bit or the last bit of the packet arrived at the network adapter; there's a delay between the arrival of that last bit and the interrupt for the packet and a delay between the start of interrupt handling and the point in the code path where the timestamp is attached to the packet.

Resolution

The timestamp has the resolution of whatever clock is being used. The clock might not be the "PC clock" because it might not be running on a "PC", either in the sense of machines sold as "personal computers" or in the sense of "IBM-compatible personal computer". Some of those machines might have better high-resolution timers than IBM-compatible PCs do - at least some OSes on more modern IBM-compatible PC's use the RDTSC instruction, if present on the processor, to get higher-precision timestamps.

There's precision and accuracy; a clock with picosecond resolution, set to a time that's 1 1/2 hours off, is very precise and very inaccurate.

Discussion

That's the usual discussion about this might be / this could be / this will be / and so on.

Please put some hard facts here ...

Just simply add measurement values (and the hard facts on the environment) on a specific platform so others can participate ...

Timestamps (last edited 2008-04-12 17:51:23 by localhost)