search

shaw2111 / netmap-libpcap

Automatically exported from code.google.com/p/netmap-libpcap
Other
0 stars 0 forks source link

Time stamping resolution difference between netmap-libpcap and no netmap #1

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Run tcpdump against an interface in netmap mode (against incoming traffic)
2. Look at the pcap in wireshark, timing resolution is in milliseconds
3. Run tcpdump against an interface in standard mode (against incoming traffic)
4. Look at the pcap in wireshark, timing resolution is in microseconds

What is the expected output? What do you see instead?
I'm running traffic to my DUT, which then processes the packets. I then save 
the egress traffic from DUT to pcap using traffic using netmap-libpcap. 
Netmap-libpcap has allowed to save packets at high speeds, but timestamping on 
the receiving side should also be timestamped at microsecond level

What version of the product are you using? On what operating system?
OS: Ubuntu 14.04 64bit (3.13.0-36-generic)
netmap git HEAD: 3ccdadad7d80bb1bc569d1f72ba3ece902350f65
netmap-libpcap git HEAD: 0890b993dae48767af172b693f2d664181dbe943
tcpdump: version 4.5.1

Please provide any additional information below.

I have attached three pcaps:

1. adapter_rx_timestamp1_netmap.pcap - captured via tcpdump -nei netmap:ethX
In this file, notice rx timestamp resolution is in micro-seconds

2. adapter_rx_timestamp3_nonetmap.pcap - captured via tcpdump -nei ethX
In this file, notice rx timestamp resolution is in milli-seconds

Original issue reported on code.google.com by morph...@gmail.com on 24 Sep 2014 at 10:01

Attachments:

GoogleCodeExporter commented 8 years ago 
It seems netmap-libpcap is timestamping in bulk instead on a per packet basis, 
both pcaps above were generated at 10G rate (at 1500 bytes), notice the tcpdump 
without netmap shows micro-level differences

14:26:37.475718 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:26:37.475726 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:26:37.475727 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:26:37.475728 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:26:37.475729 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462

However, on the netmap mode capture, groups of packets had the same timestamp

14:15:19.931624 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:15:19.931624 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:15:19.931624 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:15:19.931624 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462
14:15:19.931624 IP 192.85.1.4 > 193.85.1.4:  ip-proto-253 1462

Original comment by morph...@gmail.com on 30 Sep 2014 at 4:47

GoogleCodeExporter commented 8 years ago 
After looking at the code, this seems to be an intended case...

 * RING FLAGS
 */
#define NR_TIMESTAMP    0x0002          /* set timestamp on *sync() */
        /*
         * updates the 'ts' field on each netmap syscall. This saves
         * saves a separate gettimeofday(), and is not much worse than
         * software timestamps generated in the interrupt handler.
         */

Original comment by arielgy...@gmail.com on 30 Sep 2014 at 6:47