Re: proposed new pcap format

[Michael Richardson <mcr () sandelman ottawa on ca>]

> > > > > "Stephen" == Stephen Donnelly <stephen () endace com> writes:
    Stephen> Instead of trying to store the number of significant
    Stephen> figures in some base, how about storing the effective clock
    Stephen> timestamp frequency in Hz? This gives an indication of
    Stephen> resolution as opposed to precision.

  I'd like to say that we adopt this proposal.

    Stephen> For example if we assume timestamps are stored as
    Stephen> microseconds, but we have an older computer that only has a
    Stephen> millisecond resolution clock, then the microsecond part of
    Stephen> the time would increment by 1000 microseconds per 'tick' of
    Stephen> the 1kHz (1 millisecond period) clock. The stored
    Stephen> resolution value would be 1000 for 1000Hz.

    Stephen> If the clock resolution on a newer computer/OS was actually
    Stephen> 1 microsecond, then the microsecond timestamp would
    Stephen> increment by 1 each tick of the 1MHz clock. The stored
    Stephen> resolution value would be 1000000 for 1000000Hz.

    Stephen> To find the number of significant digits to print, you
    Stephen> could take the ceiling of log base 10 of the clock
    Stephen> resolution (in Hz). log base 10 of 1000 is 3, log base 10
    Stephen> of 1000000 is 6.

    Stephen> This method allows for clock frequencies that are not
    Stephen> powers of 10, provided that they are an integer number of
    Stephen> Hz. For example a clock resolution of 16777216Hz (log base
    Stephen> 10 of 2^24 is ~7.2) is representable, but 666.67Hz is not.

    Stephen> With a 32-bit unsigned field, frequencies up to 2^32-1 are
    Stephen> representable, which is more than sufficient for a 1ns
    Stephen> (1GHz) resolution timestamp clock. Is anyone running a
    Stephen> time-stamping clock over 4GHz? The Pentium II architecture
    Stephen> TSC counter may surpass this soon, but if the stored
    Stephen> timestamp precision is only microseconds or even
    Stephen> nanoseconds then the effective stored resolution is limited
    Stephen> to that anyway.

--
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr () xelerance com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.