----- Original Message ----- From: "Stephen Donnelly" <[EMAIL PROTECTED]> To: "Developer support list for Wireshark" <[email protected]> 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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
