----- Original Message -----
From: "Stephen Donnelly" <stephen@xxxxxxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Monday, January 21, 2008 5:04 PM
Subject: Re: [Wireshark-dev] pcap-ng support
On Tue, 2008-01-22 at 00:20 +0100, Ulf Lamping wrote:
Stephen Donnelly schrieb:
> On Mon, 2008-01-21 at 22:00 +0100, Ulf Lamping wrote:
>> Gianluca Varenni schrieb:
>>> http://www.winpcap.org/pipermail/ntar-workers/2006-March/000122.html
> I believe part of the idea behind allowing the timestamp precision to
> be
> specified as a binary fraction (2^-X) is to allow the use of Endace ERF
> timestamps in pcapng/ntar natively.
>
Well, my complain in the first place is that the specification text is
pretty easy to misunderstand (just as I did), which is usually a very
bad thing for a specification.
Certainly true.
> Timestamps in network traces are typically 64-bit, comprising a 32-bit
> 'seconds' part with a UNIX epoch, and a 32-bit 'subsecond' field
> counting milli/micro/nanoseconds withing the second. The most
> significant few bits of the subsecond are not used as the conuter
> saturates before using all the available bits.
>
I'm pretty much aware of that - I'm the author of
http://wiki.wireshark.org/Development/LibpcapFileFormat and I've
implemented the Wireshark switch from millisecond to nanosecond internal
resolution :-)
Very much appreciated. In fact the current Wireshark code for reading
ERF records converts the binary fractions to nanoseconds, a definite
improvement.
> ERF timestamps are also 64-bits, and can be considered to be a 64-bit
> value in units of 2^-32 seconds, with a UNIX epoch. Alternatively it
> can
> be considered a fixed point count of seconds from the UNIX epoch.
> Conveniently the 32 MSB are equivalent to the conventional 'seconds'
> count, while the 32 LSB can be considered a binary fraction of seconds.
> The lowest few LSB may not be used by specific hardware depending on
> the
> available clock resolution.
>
Thanks for explaining it. But it just doesn't really help to explain it
here, it must be explained in the spec! Otherwise the next one that
graps the spec and implements stuff will be trapped.
I would be happy for this to be put into the spec, if there is
consensus.
I will try to clarify the specification tonite or tomorrow.
I promise :-)
GV