In some email I received from Michael Richardson, sie wrote: -- Start of PGP signed section. > > >>>>> "Jefferson" == Jefferson Ogata <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]