Re: proposed new pcap format

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Michael Richardson, sie wrote:
-- Start of PGP signed section.
> > > > > > "Jefferson" == Jefferson Ogata <Jefferson.Ogata () noaa gov> writes:
>     >> struct pcap1_info_container {
>     >> bpf_u_int32 info_len;         /* in bytes */
>     >> bpf_u_int32 info_type;        /* enum pcap1_info_types */
>
>     Jefferson> That could be two int16s, couldn't it?
>
>   You know what they say about premature optimization :-)
>   type could be 16-bit.
>   len, I'm hesistant. The high performance network people are presently
> complaining about the 64k limit on IP packets...

Don't forget IPv6 jumbograms.

>     Jefferson> indicating the system's time error offset. Then programs
>     Jefferson> that read it can adjust timestamps on the fly.
>
>   okay, meta data for skew.
>   Can you write a structure for that?
>
>     Jefferson> Significant figures in what base? I wouldn't go there.
>
>   base 2, I'd think.
>   Hmm. I see the problem. Can someone provide a clear notion?
>   Do we have to go to units of 1/(2^32) of a second instead of
> 1/(10^9) then?

If we're attempting to indicate the error in the system's time,
then surely the best that can be done is to estimate the min/max
range that the time could be?  Kind of like error bars on a graph
to indicate confidence values of a specific measurement ?

How about 1/HZ ?  If you're trying to represent the accuracy of the
time in the capture frame then what needs to be recognised is the
maximum amount of time between the packet appearing on the network
to it ending up in a buffer, stamped.  The ideal time source here
would be a clock stamp from the NIC :)

Also, does time drift/jitter come into play?  If you're using NTP
on such a system...

Darren
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe