<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 26, 2015 at 11:41 AM, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
On Aug 25, 2015, at 3:50 PM, Stephen Donnelly <<a href="mailto:stephen.donnelly@avagotech.com">stephen.donnelly@avagotech.com</a>> wrote:<br></span><br>
The current spec says<br>
<br>
        The timestamp is a single 64-bit unsigned integer representing the number of units since 1/1/1970 00:00:00 UTC.<br>
<br>
It doesn't say "units *except for those evil leap seconds!!!!!111ONE!!!!!!*", so I'd say "it counts up once per unit, every unit" - i.e., *not* POSIX/Windows-style - is a valid interpretation.<br></blockquote><div> </div><div>You know the pcap code base better than I, how many of the input layers currently 'convert' the system/POSIX time into a monotonic counter? I thought they just shoved the packet 'system' time stamp in there as-is. This means the defacto implementation is already POSIX style.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> A monotonic count of seconds since an epoch is in practice what both TAI and GPS provide (there is a fixed offset between them due to different epochs). TAI is the default time base for PTP and IRIG-B clocks, so is often available where people really care about time stamp quality.<br>
<br>
</span>There's "time stamps" in the sense of "real-number coordinates on an axis with a given origin", and there's "time stamps" in the sense of "stuff a normal human would recognize as a date and time".<br>
<br>
Most if not all capture files, including pcap and pcapng, provide time stamps that are approximations of the first of those senses; it's the capture file readers that turn them into values of the second type.<br><br>
If both TAI and UTC were represented as seconds that have elapsed since their individual epochs, the difference between those representations would be a constant (the difference between their epochs, if any), unaffected by leap seconds, and either one would work as a monotonic count of seconds; it's attempting to tie a monotonic counter to the rotation of the earth that causes the problem.<br>
<span class=""><br>
> I was not suggesting changing the 'default' time stamp definition of pcapng, but rather adding an option for the interpretation to be e.g. 'TAI' rather than 'POSIX/Windows UTC' encoding for clarity.<br>
<br>
</span>Unfortunately, given the hardware and software on which most captures are done, it's probably not an interpretation that would allow a valid interpretation of the time stamp values.<br></blockquote><div> </div><div>Not sure what this means? I suggested allowing the capture system to indicate what interpretation to use, e.g. POSIX, Windows, 'monotonic UTC', TAI, GPS etc. Only the display tool needs to be able to interpret into a human readable UTC or local timezone for display. Wireshark must already use on leap-second tables/timezone files for this if pcap/pcapng time stamps are monotonic as you suggest and not POSIX.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So, if we're to allow packet captures on UN*X and Windows systems, with OS-supplied time stamps, we'd have to find *some* way to describe POSIX-style time stamps.<br>
<br>
If a "unit" is 1 second, then we could go with POSIX.<br>
<br>
However, if it's less than 1 second, what happens during a leap second?  Does the counter keep ticking milliseconds or microseconds or nanoseconds or whatever, and then reset back to the beginning of the previous second?</blockquote><div><br></div><div>That's precisely the problem I am trying to address by allowing the specification of a TAI time base instead of POSIX/System, so we could have a monotonic standard. The POSIX behavior is under-specified during leap seconds, implementations dependent (1). Some systems jump the clock back after the leap second, causing duplicates, while some 'pause' the clock during the leap second, messing up latency/bandwidth calculations. Some systems (Google) reportedly adjust their clock rate slightly over the next several hours/day, also messing up statistics and leading to loss of global synchronization.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">(1) <a href="http://www.madore.org/~david/computers/unix-leap-seconds.html">http://www.madore.org/~david/computers/unix-leap-seconds.html</a></div><br clear="all"><div>Stephen</div><div class="gmail_signature"><div dir="ltr"><span><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(64,64,64)"><br></span></span></div></div>
</div></div>