[ntar-workers] Timestamp resolution: if_tsaccur option unclear!

[Loris Degioanni]

Ok, yes, there was a misunderstanding.
I was referring to the precision field (option, actually) of the 
Interface Description Block, not to the packets: the precision field is 
per interface, and doesn't force any representation of the packet 
timestamps inside the section.
The current packet block has 32-bit timestamps because:

- it seemed a bit overkill to force applications to handle 64-bit values 
  for timestamps nowadays
- a different encoding would break compatibility with libpcap and all 
the applications fed by libpcap

Nothing, however, prevents us to define a "precise packet block" with 
64-bit timestamps. The precision field of the Interface Description 
Block would be exactly the same, but its range would be bigger. If 
anybody thinks that more precision is important now, we can think to add 
such a packet block to push its adoption.

Loris



Ulf Lamping wrote:
> Loris Degioanni <loris.degioanni at gmail.com> schrieb am 24.08.05 06:49:52:
> 
>>Ulf Lamping wrote:
>> 
>>
>>>P.S: With the current timestamp definition, the finest resolution would be 232,8 picoseconds (when I've done a correct calculation) until the lower 32 bit part of the timestamp will wrap around. Will this be enough even for 10GBit Ethernet?
>>
>>If my calculations are not wrong, we have 31 bits, therefore a range 
>>from 0 to 2147483648. This number is the precision as a power of -10 or 
>>as a power of -2, i.e. 1/(10^2147483648) or 1/(2^2147483648) which is, I 
>>think, more than enough for AnyGbit Ethernet.
>>
> 
> 
> Missunderstanding. There is *no* problem with the wrap around of the tsaccur value itself, that one is pretty much ok.
> 
> 
> Lower 32 bit timestamp:
> The lower 32 bits of the timestamp itself (not the tsaccur value) will wrap around. The timestamp is parted into 32bits upper (seconds unix eppoch) and 32 bits lower (with accuracy defined in tsaccur).
> 
> It's about how fine the timestamp granularity could be, without  wrapping the *lower* part. The lower part must keep at least one second until wrap. This will be ok for nanoseconds 1000000000 but picoseconds will already fail 1000000000000 (doesn't fit into a 32 bit unsigned).
> 
> The only way I can see is to use 64 bit values here, but this isn't fine for all implementations (64 bit integers probably not available on all machines, handling is slower, takes more space in the file, incompatible with old libpcap format). As picosecond resolution is not really needed today (at least for me), having a "high resolution" packet block later with a 64 bit lower part timestamp might be an idea here.
> 
> 
> Upper 32 bit timestamp:
> As Guy already noted we'll have nearly the same problem with the unix eppoch value wrapping around in 2038. That issue might be get around by some intelligence, or an option field in the headers indicating the file uses (at least some dates) after the 2038 wrap, so it might not be that of a problem. Having a capture file that span over the *whole* eppoch is *very* unlikely and using a 64 bit unsigned integer here only for this reason might just be overkill.
> 
> 
> Anyway, at least adding a note to the docs about the limitations of the discussed fields values might be a very good idea so it won't get lost :-)
> 
> Regards, ULFL
> 
> P.S: I'm subscribed to the list now, no need to CC me anymore!
> _________________________________________________________________________
> Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle 
> Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179
> 
> 
> 
> 
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers
>