Open GoogleCodeExporter opened 9 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
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
Original issue reported on code.google.com by
morph...@gmail.com
on 24 Sep 2014 at 10:01Attachments: