I found a major difference between doing the pfring_recv call with the wait_for_incoming_packet flag set and a busy loop with the flag set to 0.
Do you know why the flag induce so much latency ? With wait_for_incoming_packet set to 1 # ./ntop 2017/11/03 14:54:50 Opening PF_RING capture zc:eth2@0 2017/11/03 14:54:51 1.031169ms 2017/11/03 14:54:51 3.125617ms 2017/11/03 14:54:51 42.012934ms 2017/11/03 14:54:51 13.026811ms 2017/11/03 14:54:52 14.241295ms 2017/11/03 14:54:52 53.317201ms 2017/11/03 14:54:52 21.21709ms 2017/11/03 14:54:52 60.293962ms 2017/11/03 14:54:53 28.195748ms 2017/11/03 14:54:53 67.271545ms 2017/11/03 14:54:53 35.182174ms 2017/11/03 14:54:53 3.112353ms 2017/11/03 14:54:54 42.200138ms 2017/11/03 14:54:54 10.104631ms 2017/11/03 14:54:54 49.172548ms Busy loop with With wait_for_incoming_packet set to 0 # ./ntop 2017/11/03 14:53:54 Opening PF_RING capture zc:eth2@0 2017/11/03 14:53:54 112.808µs 2017/11/03 14:53:54 101.491µs 2017/11/03 14:53:54 105.697µs 2017/11/03 14:53:55 116.839µs 2017/11/03 14:53:55 92.49µs 2017/11/03 14:53:55 116.731µs 2017/11/03 14:53:55 101.466µs 2017/11/03 14:53:56 135.863µs 2017/11/03 14:53:56 112.909µs 2017/11/03 14:53:56 99.826µs 2017/11/03 14:53:56 111.789µs 2017/11/03 14:53:57 137.237µs 2017/11/03 14:53:57 191.66µs 2017/11/03 14:53:57 97.025µs 2017/11/03 14:53:57 100.77µs 2017/11/03 14:53:58 122.966µs 2017/11/03 14:53:58 91.301µs 2017/11/03 14:53:58 98.335µs 2017/11/03 14:53:58 80.595µs # ping 176.31.237.4 PING 176.31.237.4 (176.31.237.4) 56(84) bytes of data. 64 bytes from 176.31.237.4: icmp_seq=1 ttl=60 time=0.185 ms 64 bytes from 176.31.237.4: icmp_seq=2 ttl=60 time=0.171 ms 64 bytes from 176.31.237.4: icmp_seq=3 ttl=60 time=0.198 ms 64 bytes from 176.31.237.4: icmp_seq=4 ttl=60 time=0.203 ms 64 bytes from 176.31.237.4: icmp_seq=5 ttl=60 time=0.201 ms 64 bytes from 176.31.237.4: icmp_seq=6 ttl=60 time=0.191 ms 64 bytes from 176.31.237.4: icmp_seq=7 ttl=60 time=0.215 ms 64 bytes from 176.31.237.4: icmp_seq=8 ttl=60 time=0.172 ms 64 bytes from 176.31.237.4: icmp_seq=9 ttl=60 time=0.205 ms ^C --- 176.31.237.4 ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 7996ms rtt min/avg/max/mdev = 0.171/0.193/0.215/0.019 ms On Mon, 2017-10-30 at 17:25 +0100, Charles-Antoine Mathieu wrote: > I tried a lot of different configurations but could not figure out > why > I get those weird latencies by taking the time right after send ans > recv calls. > > I'm reduced the code to the minimum and put it in this repository if > you want to take a quick look. > https://github.com/camathieu/pfring_latency#pfring_latency > > Now, I wonder if there is some tweaks in the module or driver > parameter > that I overlooked or if it could be related to golang because I'm out > of ideas ^^. > > On Fri, 2017-10-27 at 10:18 +0200, Charles-Antoine Mathieu wrote: > > > > Yes : > > > > https://github.com/google/gopacket/blob/master/pfring/pfring.go#L24 > > 7 > > > > On Thu, 2017-10-26 at 19:14 +0200, Alfredo Cardigliano wrote: > > > > > > > > > Hi > > > are you setting the flush flag to 1 when calling pfring_send()? > > > > > > Alfredo > > > > > > > > > > > > > > > > > > > On 26 Oct 2017, at 18:42, Charles-Antoine Mathieu <charles- > > > > antoine. > > > > [email protected]> wrote: > > > > > > > > Hi, > > > > > > > > I'm trying to implement that, but my results looks odd. I'm > > > > trying > > > > to > > > > ping a bunch of ~20 hosts with a latency of ~1.77 ms every 5 > > > > seconds. > > > > > > > > I capture time right after pfring_send and pfring_recv. For > > > > every > > > > batch > > > > I get around the same latency for every host but the latency > > > > range > > > > from > > > > 1ms to 300ms. > > > > > > > > 37.187.9.32 : 11.532119ms > > > > 37.187.9.245 : 11.54512ms > > > > 37.187.9.124 : 11.525933ms > > > > ... 5 sec later the next batch ... > > > > 37.187.9.14 : 107.540483ms > > > > 37.187.9.17 : 107.519064ms > > > > 37.187.9.32 : 107.505375ms > > > > > > > > I wonder if you are aware of some kind of buffering that might > > > > happen > > > > in the process to yield such results. > > > > > > > > The ring is opened in ZC mode > > > > NIC model is Intel Corporation 82599ES 10-Gigabit SFI/SFP+ > > > > Network > > > > Connection (rev 01) > > > > > > > > I'm using gopacket and ARISTA's nanotime package to capture a > > > > monotonic > > > > time which rely upon CLOCK_MONOTONIC, it seems more reliable > > > > and > > > > lightweight that time.Now() to me. > > > > https://github.com/aristanetworks/goarista/blob/master/monotime > > > > /n > > > > an > > > > otim > > > > e.go > > > > > > > > On Fri, 2017-10-06 at 16:38 +0200, Alfredo Cardigliano wrote: > > > > > > > > > > > > > > > > > > > > Hi > > > > > in ZC mode kernel is bypassed, thus you should send the > > > > > packet > > > > > and > > > > > call clock_gettime() > > > > > immediately after in order to compute latency (the same > > > > > function > > > > > is > > > > > used for RX in this case). > > > > > > > > > > Alfredo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6 Oct 2017, at 16:34, Charles-Antoine Mathieu <charles- > > > > > > antoine.m > > > > > > [email protected]> wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > I have a process that sends and receive ICMP packets using > > > > > > PF_RING. > > > > > > > > > > > > I'd like to capture send and received packets to be able to > > > > > > compute > > > > > > the > > > > > > latency. When I'm not in ZC mode I get the send and the > > > > > > received > > > > > > packet > > > > > > in the capture. However in ZC mode I only get the received > > > > > > packets > > > > > > in > > > > > > the capture. > > > > > > > > > > > > Is there a way go get the same behaviour in ZC mode ? > > > > > > _______________________________________________ > > > > > > Ntop mailing list > > > > > > [email protected] > > > > > > http://listgateway.unipi.it/mailman/listinfo/ntop > > > > > _______________________________________________ > > > > > Ntop mailing list > > > > > [email protected] > > > > > http://listgateway.unipi.it/mailman/listinfo/ntop > > > > _______________________________________________ > > > > Ntop mailing list > > > > [email protected] > > > > http://listgateway.unipi.it/mailman/listinfo/ntop > > > _______________________________________________ > > > Ntop mailing list > > > [email protected] > > > http://listgateway.unipi.it/mailman/listinfo/ntop > > _______________________________________________ > > Ntop mailing list > > [email protected] > > http://listgateway.unipi.it/mailman/listinfo/ntop > _______________________________________________ > Ntop mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
