Re: nanosecond timestamp

[Alexander Dupuy <dupuy () sysd com>]

> > ...the time stamps you get out of libpcap might have 
> > nanosecond *precision* but they might not have nanosecond *accuracy*) - 

> So what am I trying to say here?  Unless you have hardware timestamps
> in captured packets, one software timestamp is as good as the next in
> a well written application.

If the kernel timestamp on the packet agrees with the (adjusted) result of 
gethrtime to within the kernel's level of accuracy (often far less than the 
microsecond precision it provides) you might be justified in using the 
additional precision of gethrtime to increase your accuracy.

This depends a lot on how you "adjust" the gethrtime result (a fixed offset 
won't deal well with adjtime skew etc.) but let's assume that you periodically 
update the gethrtime adjustment based on gettimeofday/gethrtime comparisons, 
and try to estimate the software delay between the kernel and your application 
call to gethrtime somehow.

In that case, Guy's argument is still compelling if your adjusted gethrtime 
data doesn't even agree with the kernel timestamps to within the kernel's 
limits of accuracy - in that case you are clearly trading down to a less 
accurate timestamp, even if it seems more precise.

@alex
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.