lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #9751] UDP client/serveur support in lwiperf


From: David GIRAULT
Subject: [lwip-devel] [patch #9751] UDP client/serveur support in lwiperf
Date: Fri, 1 Feb 2019 10:10:48 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Follow-up Comment #7, patch #9751 (project lwip):

> It only works in main loop mode (NO_SYS=1).

Yes, I forgot this point when I developed this. Indeed, a timer will have been
much more portable. But since `sys_timeout` is based on miliseconds, I did not
think about it.

Additionally, since lwiperf only use RAW API, I've assumed it is only
compatible with NO_SYS=1 platforms.

> Also, why do you substract '5' from 'conn->delay_target' in the sending
loop? Is that supposed to be the delay from that code line until the packet is
on the wire? Wouldn't that need to be a define that can be adjusted to the
hardware? 

Yes, this is a little trick to take care of processing time to send one UDP
frame. It should be dynamically calculated. This value is for our target to
achieve same transmit rate as requested. Original IPerf2 code use a dynamic
adjust in loop (see Client.cpp).

At least, it should be a define.

> To get this pushed, maybe we can start with wrapping the timing in defines
and providing both your 'clock_gettime' version as well as a 32-bit
millisecond-based version. We could then see where it goes...

Yes, I think it's the best way.

> Thinking about that again: if you need a 373µs delay to achieve 30Mb/s,
would it work to wait 1ms and send 3 packets? Or do they really need to be
evenly distributed?

This can be a valid workaround for the BW limits, but this will result in a
very bad jitter result in the receiver. If not evenly distributed, jitter will
be very high (according to my understand of the jitter calculation).


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/patch/?9751>

_______________________________________________
  Message posté via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]