Right, indeed the timerslack (50us) is not added if the process is
real-time.
But the C-state problem can still hit you hard.
Cheers,
Vincenzo
Il giorno lun 29 ott 2018 alle ore 16:23 Stephen Hemminger <
step...@networkplumber.org> ha scritto:
> On Sun, 28 Oct 2018 09:07:02 +0100
> Vincenzo
On Sun, 28 Oct 2018 09:07:02 +0100
Vincenzo Maffione wrote:
> If you don't care about CPU utilization, busy-wait is the way to go.
> Otherwise you can try to usleep() for something like 60-70 us (to lower the
> CPU utilization), and then busy-wait for the rest of the interval (so that
> you
If you don't care about CPU utilization, busy-wait is the way to go.
Otherwise you can try to usleep() for something like 60-70 us (to lower the
CPU utilization), and then busy-wait for the rest of the interval (so that
you still have maximum precision).
You may want to have a look at this
Hi,
How are you wating for the 100us interval? If you use sleep primitives
like usleep() or nanosleep() your delay is
likely due to the nanosleep() default timerslack, or deep C-states enabled,
or frequency scaling, etc.
This would be completely unrelated to DPDK.
Cheers,
Vincenzo
Il giorno
Thank you very much for the help
On Sun, Oct 28, 2018 at 1:07 AM Vincenzo Maffione
wrote:
> If you don't care about CPU utilization, busy-wait is the way to go.
> Otherwise you can try to usleep() for something like 60-70 us (to lower
> the CPU utilization), and then busy-wait for the rest of
Thank you very much for the reply.
But in that case, should I busy wait, to create the delay?
Hello DPDK experts,
I'am testing the performance of DPDK not on high speed polling
but sending each packet with 100 microsecond interval.
As same as the POSIX, DPDK performance degrades into 90 ~ 100 microsecond
round-trip latency per 4KB message.
Is there a way to improve the performance,
Hello DPDK experts,
I'am testing the performance of DPDK not on high speed polling
but sending each packet with 100 microsecond interval.
As same as the POSIX, DPDK performance degrades into 90 ~ 100 microsecond
round-trip latency per 4KB message.
Is there a way to improve the performance,
