Mailing List Archive

Capture send packets in ZC mode
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
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
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.mathieu@corp.ovh.com> 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
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
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/nanotim
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
> > athieu@corp.ovh.com> 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
> > Ntop@listgateway.unipi.it
> > http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
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.mathieu@corp.ovh.com> 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/nanotim
> 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
>>> athieu@corp.ovh.com> 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
>>> Ntop@listgateway.unipi.it
>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>> _______________________________________________
>> Ntop mailing list
>> Ntop@listgateway.unipi.it
>> http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
Yes : 

https://github.com/google/gopacket/blob/master/pfring/pfring.go#L247

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.
> > mathieu@corp.ovh.com> 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/nan
> > 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
> > > > athieu@corp.ovh.com> 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
> > > > Ntop@listgateway.unipi.it
> > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > _______________________________________________
> > > Ntop mailing list
> > > Ntop@listgateway.unipi.it
> > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > _______________________________________________
> > Ntop mailing list
> > Ntop@listgateway.unipi.it
> > http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
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#L247
>
> 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.
> > > mathieu@corp.ovh.com> 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
> > > > > athieu@corp.ovh.com> 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
> > > > > Ntop@listgateway.unipi.it
> > > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > > _______________________________________________
> > > > Ntop mailing list
> > > > Ntop@listgateway.unipi.it
> > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > _______________________________________________
> > > Ntop mailing list
> > > Ntop@listgateway.unipi.it
> > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > _______________________________________________
> > Ntop mailing list
> > Ntop@listgateway.unipi.it
> > http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
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.
> > > > mathieu@corp.ovh.com> 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
> > > > > > athieu@corp.ovh.com> 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
> > > > > > Ntop@listgateway.unipi.it
> > > > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > > > _______________________________________________
> > > > > Ntop mailing list
> > > > > Ntop@listgateway.unipi.it
> > > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > > _______________________________________________
> > > > Ntop mailing list
> > > > Ntop@listgateway.unipi.it
> > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > _______________________________________________
> > > Ntop mailing list
> > > Ntop@listgateway.unipi.it
> > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > _______________________________________________
> > Ntop mailing list
> > Ntop@listgateway.unipi.it
> > http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
Re: Capture send packets in ZC mode [ In reply to ]
Hi Charles
I guess you are using the standard PF_RING API, any chance you can try the ZC API to
check if there is any difference? (the passive-wait implementation is different, and it usually
perform better).
I also pushed a change to the standard API, please update and let us know if you see any
improvement.

Thank you
Alfredo

> On 3 Nov 2017, at 15:08, Charles-Antoine Mathieu <charles-antoine.mathieu@corp.ovh.com> wrote:
>
> 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.
>>>>> mathieu@corp.ovh.com> 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
>>>>>>> athieu@corp.ovh.com> 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
>>>>>>> Ntop@listgateway.unipi.it
>>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>>>> _______________________________________________
>>>>>> Ntop mailing list
>>>>>> Ntop@listgateway.unipi.it
>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>>> _______________________________________________
>>>>> Ntop mailing list
>>>>> Ntop@listgateway.unipi.it
>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>> _______________________________________________
>>>> Ntop mailing list
>>>> Ntop@listgateway.unipi.it
>>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>> _______________________________________________
>>> Ntop mailing list
>>> Ntop@listgateway.unipi.it
>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>> _______________________________________________
>> Ntop mailing list
>> Ntop@listgateway.unipi.it
>> http://listgateway.unipi.it/mailman/listinfo/ntop
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop