tcpdump mailing list archives
Re: proposed new pcap format
From: Michael Richardson <mcr () sandelman ottawa on ca>
Date: Wed, 24 Mar 2004 13:57:28 -0500
-----BEGIN PGP SIGNED MESSAGE-----
"Darren" == Darren Reed <darrenr () reed wattle id au> writes:
>> type could be 16-bit.
>> len, I'm hesistant. The high performance network people are presently
>> complaining about the 64k limit on IP packets...
Darren> Don't forget IPv6 jumbograms.
Yes.
>> 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?
Darren> If we're attempting to indicate the error in the system's time,
Darren> then surely the best that can be done is to estimate the min/max
Darren> range that the time could be? Kind of like error bars on a graph
Darren> to indicate confidence values of a specific measurement ?
yes, so, we want to say,
captured at: 2004-Mar-24 13:53:14.238534 +- 0.0001
or: 2004-Mar-24 13:53:14.238534 +- 10^-4
which can be summarized as "4". That doesn't allow for error bars
like +- 0.00015. I think when you do this in base 2, it is a lot easier.
Darren> How about 1/HZ ? If you're trying to represent the accuracy of the
Darren> time in the capture frame then what needs to be recognised is the
Darren> maximum amount of time between the packet appearing on the network
Darren> to it ending up in a buffer, stamped. The ideal time source here
Darren> would be a clock stamp from the NIC :)
No, that doesn't help.
Assume that the PHY does the stamping, you still need to know the
resolution of the timer used to make the stamp.
Darren> Also, does time drift/jitter come into play? If you're using NTP
Darren> on such a system...
It was suggested that there be a way to indicate what the drift
against an accurate source would be.
- --
] 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"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQGHaF4qHRg3pndX9AQGeKwQA05oXBe7QXCpw4GBv/quePSuaREcPHXA7
fzN7ateYcyd8xZTnNMjvTJxV5veATZYKKJZZF9+EBRbKNoYbEJ9tSsPHit7SPboK
dRHr7723XIC/gaLZFf2/hN28ri4x/Q2ITYHK4s95lEB3yQrSx/dfvM/tnhJIbny+
yz5Da7lfDZY=
=msTg
-----END PGP SIGNATURE-----
-
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
Current thread:
- Re: proposed new pcap format, (continued)
- Re: proposed new pcap format Hannes Gredler (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 24)
- Re: proposed new pcap format Hannes Gredler (Mar 24)
- Re: proposed new pcap format Hannes Gredler (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 25)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 25)
- Re: proposed new pcap format Richard Sharpe (Mar 25)
- --enable-ipv6 Error You must get working getaddrinfo() function murugesan (Mar 26)
- Re: proposed new pcap format Richard Sharpe (Mar 26)
