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

[Gianluca Varenni]

----- Original Message ----- 
From: "Loris Degioanni" <loris.degioanni at gmail.com>
To: <ntar-workers at winpcap.org>
Sent: Thursday, August 25, 2005 8:39 AM
Subject: Re: [ntar-workers] Timestamp resolution: if_tsaccur option unclear!


> 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:

I think you mean 32 bits for the lower part of the timestamps...

>
> - 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.

Uhm, 64 bits for the lower part, which accounts for 32 + 64 = 96 bits for 
the timestamp. Or maybe 64+64 bits, so that we can solve the problem of the 
seconds wrapping around in 2038.

GV

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
>>
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers