Re: [tcpdump-workers] nanosecond timestamp
Hi!
Can I add this structure in pcap.h and get a new magic number so
that we can support nanosecond resolution?
/* libpcap record header. */
struct pcaprec_hdr {
guint32 ts_sec; /* timestamp seconds */
guint32 ts_usec;/* timestamp microseconds */
guint32 incl_len; /* number of octets of packet saved in
file */
guint32 orig_len; /* actual length of packet */
};
/* libpcap header for version used by Navtel */
struct pcaprec_navtel_hdr {
struct pcaprec_hdr hdr; /* the regular header */
guint32 ts_nsec;/* timestamp nanoseconds */
};
Regards,
Dumas Hwang
Should I add a new struct and request a new magic number? I would
think many people
need nanosecond resolution (if not picosecond).
That's probably a reasonable short-term answer, if you need this soon.
I wouldn't do much of anything more in the new format, though, because
the right long term answer is
http://www.tcpdump.org/pcap/pcap.html
which supports a number of new things, including the ability to specify
the accuracy of time stamps. It'd be nice to add the ability to *read*
that format to libpcap 0.9, but still have it write the old format, so
that when we add the ability to *write* that format, there will be at
least some versions of libpcap that will be able to handle new-format
captures with only one interface.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
Dumas Hwang wrote:
Hi!
Can I add this structure in pcap.h and get a new magic number so
that we can support nanosecond resolution?
/* libpcap record header. */
struct pcaprec_hdr {
guint32 ts_sec; /* timestamp seconds */
guint32 ts_usec;/* timestamp microseconds */
guint32 incl_len; /* number of octets of packet saved in
file */
guint32 orig_len; /* actual length of packet */
};
/* libpcap header for version used by Navtel */
struct pcaprec_navtel_hdr {
struct pcaprec_hdr hdr; /* the regular header */
guint32 ts_nsec;/* timestamp nanoseconds */
};
Regards,
Dumas Hwang
Should I add a new struct and request a new magic number? I would
think many people need nanosecond resolution (if not picosecond).
Are there any issues with having the header not be an 8 byte multiple in
size? lots of stuff (iirc) wants four-byte, but I'm not sure about 8
rick jones
one must constantly strive to eschew the tendency to overly utilize
polysyllabic verbiage in interpersonal communications lest the intent of
said communications becomes obfuscated by the preponderance of
preposterous pronouns. there, hopefully that is enough new text :)
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
Rick Jones wrote:
Are there any issues with having the header not be an 8 byte multiple in
size? lots of stuff (iirc) wants four-byte, but I'm not sure about 8
And is there a compelling reason to supply both the microseconds and
nanoseconds time stamps in the record header? Yes, libpcap would have
to divide ts_nsec by 1000 for each packet in order to allow existing
libpcap-based programs to read Navtel files, but whatever's writing out
those files would have to divide ts_nsec by 1000 for each packet in
order to put ts_usec into the header, and, if that's a significant
amount of CPU time, you probably want to spend it when reading the
capture file offline, not when capturing it.
So the Navtel header should perhaps be
struct pcaprec_navtel_hdr {
guint32 ts_sec; /* timestamp seconds */
guint32 ts_nsec;/* timestamp nanoseconds */
guint32 incl_len; /* number of octets of packet saved in
file */
guint32 orig_len; /* actual length of packet */
};
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
Yes, I can use that structure too. Sorry, I am quite new to this. Is
the next step to get the magic number, change Ethereal so that it will
recognize the new magic number and submit the patch?
Regards,
Dumas Hwang
So the Navtel header should perhaps be
struct pcaprec_navtel_hdr {
guint32 ts_sec; /* timestamp seconds */
guint32 ts_nsec;/* timestamp nanoseconds */
guint32 incl_len; /* number of octets of packet
saved in file */
guint32 orig_len; /* actual length of packet */
};
-
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
Dumas Hwang wrote: Yes, I can use that structure too. Sorry, I am quite new to this. Is the next step to get the magic number, change Ethereal so that it will recognize the new magic number and submit the patch? The next step is to change libpcap so that all programs using libpcap can read files in this format (they wouldn't get nanosecond resolution, but then neither will Ethereal without changes to Wiretap, as it returns timestamps with microsecond resolution) and submit that patch. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
Can I get a magic number associated with this format? Regards, Dumas Hwang -Original Message- From: Guy Harris [mailto:[EMAIL PROTECTED] Sent: January 6, 2005 4:20 PM To: tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] nanosecond timestamp Dumas Hwang wrote: Yes, I can use that structure too. Sorry, I am quite new to this. Is the next step to get the magic number, change Ethereal so that it will recognize the new magic number and submit the patch? The next step is to change libpcap so that all programs using libpcap can read files in this format (they wouldn't get nanosecond resolution, but then neither will Ethereal without changes to Wiretap, as it returns timestamps with microsecond resolution) and submit that patch. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: I would like to get nanosecond resolution on Solaris in libpcap. What's the best way to go about it? I suppose it's not a good idea to change struct timeval ts in pkthdr to timespec. That would be an amazingly bad idea (and it was an amazingly bad idea when IBM did it; they then proceeded to make it worse when they also used SNMP interface types rather than the we started with ARP types but then just added new types DLT_ values, so that not only are the time stamps different from what a program expecting a libpcap file would expect, the *link-layer type values in the file header* are different - Ethereal has some hacks to try to guess whether the file is an AIX file or not, and if we're willing to give up the ability to read pre-libpcap-0.4 PPP captures, libpcap could adopt those hacks, too). Should I add a new struct and request a new magic number? I would think many people need nanosecond resolution (if not picosecond). That's probably a reasonable short-term answer, if you need this soon. I wouldn't do much of anything more in the new format, though, because the right long term answer is http://www.tcpdump.org/pcap/pcap.html which supports a number of new things, including the ability to specify the accuracy of time stamps. It'd be nice to add the ability to *read* that format to libpcap 0.9, but still have it write the old format, so that when we add the ability to *write* that format, there will be at least some versions of libpcap that will be able to handle new-format captures with only one interface. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: I would like to get nanosecond resolution on Solaris in libpcap. BTW, where are you getting the nanosecond-resolution time stamps in Solaris? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime there is such a thing in some of the other OSes as well - netperf will use it for -DHISTOGRAM because it typically is lower overhead. however, my recollection of the manpages is that it is only good for relative time, not clock time. perhaps that is ok here but it will be a semantic (right term?) difference from gettimeofday(). rick jones higher resolution timestamps would be nice. there is no rest for the wicked, yet the virtuous have no pillows - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
In some email I received from rick jones, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime there is such a thing in some of the other OSes as well - netperf will use it for -DHISTOGRAM because it typically is lower overhead. however, my recollection of the manpages is that it is only good for relative time, not clock time. perhaps that is ok here but it will be a semantic (right term?) difference from gettimeofday(). Perhaps, the man page says: The gethrtime() function returns the current high-resolution real time. Time is expressed as nanoseconds since some arbi- trary time in the past; it is not correlated in any way to the time of day, and thus is not subject to resetting or drifting by way of adjtime(2) or settimeofday(3C). The hi- res timer is ideally suited to performance measurement tasks, where cheap, accurate interval timing is required. So something like getimeofday(foo, NULL); foohr = gethrtime() would approximately equate foohr with foo, such that you could use the change in gethrtime() values returned to calculate the current time with more accuracy than just gettimeofday() ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 2:08 PM, Darren Reed wrote: In some email I received from Guy Harris, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime That says what the high-resolution time counter's value is now, not what the value was when bufmod saw the packet (which raises another issue, namely that the time stamps you get out of libpcap might have nanosecond *precision* but they might not have nanosecond *accuracy*) - or are the packets in question not being captured by libpcap, so that you can use gethrtime() to time stamp packets reasonably close to the time t which they arrived? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
In some email I received from Guy Harris, sie wrote: On Dec 9, 2004, at 2:08 PM, Darren Reed wrote: In some email I received from Guy Harris, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime That says what the high-resolution time counter's value is now, not what the value was when bufmod saw the packet (which raises another issue, namely that the time stamps you get out of libpcap might have nanosecond *precision* but they might not have nanosecond *accuracy*) - or are the packets in question not being captured by libpcap, so that you can use gethrtime() to time stamp packets reasonably close to the time t which they arrived? I think that whether it is bufmod or a program that generates a time stamp, it is still a software timestamp and sometime after the actual packet arrived. So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 3:23 PM, Darren Reed wrote: So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. ...or as bad as the next. If you want absolute time stamps, nanosecond resolution with anything other than hardware timestamps is probably overkill - *microsecond* resolution is probably overkill. If you want relative time stamps, the higher resolution is useful with software time stamps only to the extent that the jitter in the delay between packet arrival and time stamping is enough less than the resolution that you're not measuring noise with those extra bits of resolution (unless one goal is to measure the times when the packet made it through the networking software, but, in that case, you really *do* want the bufmod time stamp, except that it doesn't exactly reflect the time when the packet was seen by, say, the IP layer). So, yes, one software time stamp is as good - or as bad - as the next, but in that case I suspect that the boring old microsecond time stamp from bufmod is as good as any nanosecond-precision time stamp you might synthesize. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
...the time stamps you get out of libpcap might have nanosecond *precision* but they might not have nanosecond *accuracy*) - So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. If the kernel timestamp on the packet agrees with the (adjusted) result of gethrtime to within the kernel's level of accuracy (often far less than the microsecond precision it provides) you might be justified in using the additional precision of gethrtime to increase your accuracy. This depends a lot on how you adjust the gethrtime result (a fixed offset won't deal well with adjtime skew etc.) but let's assume that you periodically update the gethrtime adjustment based on gettimeofday/gethrtime comparisons, and try to estimate the software delay between the kernel and your application call to gethrtime somehow. In that case, Guy's argument is still compelling if your adjusted gethrtime data doesn't even agree with the kernel timestamps to within the kernel's limits of accuracy - in that case you are clearly trading down to a less accurate timestamp, even if it seems more precise. @alex - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
