From: Ajinkya D Kadam <ajinkya.kadam@nyu.edu>
To: Paul Emmerich <emmericp@net.in.tum.de>
Cc: users@dpdk.org
Subject: Re: [dpdk-users] TimeStamping Packets Generated and Received via Pktgen Application
Date: Mon, 17 Oct 2016 04:01:17 -0400 [thread overview]
Message-ID: <CAOX3V8T5iAtiooh_3Vo-2C2nu7pXVReaeHSULkN=Xq=BLqVDwA@mail.gmail.com> (raw)
In-Reply-To: <30743c45-8247-ebf6-45ae-55d95e9bdfce@net.in.tum.de>
Hi Paul,
Thanks a lot for your help.
I was reading through your paper and I think this tool will be much more
helpful to me. Btw I am using quad X710 and dual X520 NICs.
Is this [1] the right code to look at if i want to see how you have
achieved hardware based time stamping ?
In addition, I want to confirm my understanding of why MoonGen is better
than PktGen in time stamping context.
PktGen reads the value of rdtsc which it then appends to packet, this adds
more delay and hence the precision is bad.
In case of MoonGen how does this work ? I am not sure. Could you please
elaborate ?
Thanks,
Ajinkya
[1]
https://github.com/libmoon/libmoon/blob/b5f6c2cac42c02db64073b57dd8ca82692d3858c/examples/hardware-timestamping.lua
ᐧ
On Sun, Oct 16, 2016 at 6:55 PM, Paul Emmerich <emmericp@net.in.tum.de>
wrote:
> Hi,
>
>
> Ajinkya D Kadam:
>
>> If yes I would like to modify the pktgen code so that each transmitting
>> and
>> received packet is timestamped. Right now I am exploring the example
>> applications like rxtx_callbacks which timestamps packets in DPDK, Is
>> this
>> the right direction to go ?
>>
>
> Check out my packet generator MoonGen
> https://github.com/emmericp/MoonGen
>
> It uses the hardware timestamping features (PTP) to do latency
> measurements in the nanosecond-range.
>
> However, if you will run into hardware limitations if you want to
> timestamp *all* packets. This is sometimes supported on RX (e.g., i310,
> X550) but I don't know a NIC that supports this on TX.
>
> As for the precision that is achievable: ~10ns (depending on the NIC) with
> hardware support. Software timestamping will typically result in a standard
> deviation of 200-300ns under load and there will be huge outliers.
>
>
> Paul
>
next prev parent reply other threads:[~2016-10-17 8:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-16 22:33 Ajinkya D Kadam
2016-10-16 22:55 ` Paul Emmerich
2016-10-17 8:01 ` Ajinkya D Kadam [this message]
2016-10-17 10:41 ` Paul Emmerich
2016-10-22 10:19 ` Huynhtu Dang
2016-10-25 11:07 ` Paul Emmerich
2016-10-27 7:27 ` Huynhtu Dang
[not found] ` <58A6F009-9B14-4CA2-87E5-54ABDB18D5F7@net.in.tum.de>
2016-12-06 15:40 ` Ajinkya D Kadam
2016-12-06 16:32 ` Paul Emmerich
[not found] ` <96BD8530-7724-4ABA-9D93-47C4FBD409DA@net.in.tum.de>
2016-12-14 18:33 ` Ajinkya D Kadam
2016-12-14 21:05 ` Paul Emmerich
2016-12-15 0:00 ` Ajinkya D Kadam
2016-12-19 17:51 ` Ajinkya D Kadam
2016-12-19 18:16 ` Paul Emmerich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOX3V8T5iAtiooh_3Vo-2C2nu7pXVReaeHSULkN=Xq=BLqVDwA@mail.gmail.com' \
--to=ajinkya.kadam@nyu.edu \
--cc=emmericp@net.in.tum.de \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).