Reference time from pcap header rather than keyframe

[dermoth]

Hi,

I'm looking at using Arista ASIC timestamps but right now the data I have has no key frames... It's not really relevant to me as I'm primarily interested at the delta of specific packets, but I need <10ns resolution. This means any reference time, good or bad, will work for me as the asic counter alone will retain accurate deltas packet after packet.

I'd like to implement an option to take pcap header as reference time. It would help if you could provide sample pcaps (just a couple of packets will be sufficient) with and without keyframes so I could use it for development and testing. Having sample pcaps could also be great to add automated tests.

Regards,

Thomas

[advornic]

Hi Thomas,

Just to confirm I understand this right, are you looking for a pcap with
timestamped data packets and no keyframes? Any preference on the
timestamping being performed before-FCS or by replacing FCS?

Thanks,
Andrei

On Wed, Mar 11, 2015 at 4:16 PM, Thomas Guyot-Sionnest <
notifications@github.com> wrote:

Hi,

I'm looking at using Arista ASIC timestamps but right now the data I have
has no key frames... It's not really relevant to me as I'm primarily
interested at the delta of specific packets, but I need <10ns resolution.
This means any reference time, good or bad, will work for me as the asic
counter alone will retain accurate deltas packet after packet.

I'd like to implement an option to take pcap header as reference time. It
would help if you could provide sample pcaps (just a couple of packets will
be sufficient) with and without keyframes so I could use it for development
and testing. Having sample pcaps could also be great to add automated tests.

Regards,

Thomas

—
Reply to this email directly or view it on GitHub
#1.

[dermoth]

The switch writes (or can write) ASIC timestamps, and i'm looking at getting the high resolution timestamp into the pcap header (i.e. re-writing them). The pcap header is fairly accurate too (hw timestamping, ~10ns resolution), but not precise enough and more importantly it's taken later down the line, not at the switch port.

A reload may be needed for the keyframes to work, and with it or not I'm worried the first capture packets before the keyframe may end up missing their timestamp. Since I care only about the delay between specific packets and not the actual time accuracy I think the timestamp from the pcap packet headers could be used for synchronization. It will give a very imprecise time compared to keyframes, but the relative time between packets would be retained as long as there is no gap in the flow (~6.15 sec from what I read earlier...)

Actually going even further, I think the pcap timestamps could also be used to calculate the number of rollovers on long gaps so the script could remain perfectly synchronized... But that's not my priority right now.

[advornic]

I attached a few pcaps - simply remove the '.png' extension from the file - I hope that helps.

Can you please clarify where you got the ~10ns resolution number from? As far as I know (https://wiki.wireshark.org/Development/LibpcapFileFormat) you can get either microsecond precision or nanosecond precision with libpcap (nanosecond using the latest version on GitHub).

And just to clarify if I understand this right - you wish to use the pcap timestamp in the first packet as a reference and then replace the following pcap timestamps by ones generated based on the reference timestamp (the one from the first packet) and the difference between the ASIC time in the packets and the ASIC time in the reference packet. Is that right?

If you need more pcaps or more specific ones, please unicast me @ andrei@arista.com. Thanks!

[advornic]

The file attached above is actually ZIP archive - please rename it accordingly.

[dermoth]

Thanks.

The 10ns resolutions comes from the capture box. It's saved as ns resolution but the last digit is always 0.

And yes, I wast to use the first pcap header as reference time.

Regards,

Thomas

[dermoth]

Hey, for the heads up, the python library used here doesn't support pcap-ng... this is a problem since I would have to convert pcaps beforehand and then on write-out I'd loose the ns resolution, which isn't very useful.

It seems it'll be easier to just add Arista counter support to our scripts instead... I guess you can either close this bug or make it depend on a new one for pcap-ng support....

Regards,

Thomas

[advornic]

At the time when we started this project there was no Python library for
pcap-ng (as far as I can remember).

On Thu, Mar 19, 2015 at 12:00 PM, Thomas Guyot-Sionnest <
notifications@github.com> wrote:

Hey, for the heads up, the python library used here doesn't support
pcap-ng... this is a problem since I would have to convert pcaps beforehand
and then on write-out I'd loose the ns resolution, which isn't very useful.

It seems it'll be easier to just add Arista counter support to our scripts
instead... I guess you can either close this bug or make it depend on a new
one for pcap-ng support....

Regards,

Thomas

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[sponsoredlinks]

Hello guys,

Did you end up getting anywhere with adding pcap-ng support for either the pcap decoder or the tsdump scripts? It'd be great to be able to use this with nanosecond-accurate timestamps in our pcap files

[dermoth]

I don't know much about doing that with the modules used in this tool, nor pcap-ng support, but nseclibpcap is very similar to normal pcap format with nanosecond support... in fact it would be trivial to transcode plain pcap format to nseclibpcap using pack/unpack (we do it in Perl but this is proprietary code). If you need other formats you can also convert to/from nseclibpcap using Wireshark or its command-line tools.

That said, I found out for latency calculation over very short periods (ex. packet forwarding latency or app response time) are best done with the raw timestamps directly, unless you have more advanced tooling such as Corvil appliance that does it for you. The thing with conversion to pcap format is that you have to make time adjustments based on keyframes to find wall-clock time, and if you calculate latencies based on this resolved timestamp it will introduce jitter. The most accurate way to calculate latencies it to therefore decode raw timestamps directly and only consider the delta between packets using the formula Arista tick delta * 20 / 7 ("20/7", or if you prefer "1000/350", being the exact interval in ns between each Arista tick).

When doing so you have to of course handle counter rollovers happening every ~6.1s... if you need to get deltas over 6s you'd probably best keep an internal 64bit representation and use keyframes to stay in sync.