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

[Simon Goldschmidt]

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

Ok, so now I took the time to review your implementation and I see why you
need the µs timing. However, seeing how you did that I can say this
implementation is not portable. It only works in main loop mode (NO_SYS=1).

For threaded mode, you can't just call 'lwiperf_poll_udp_client' in a loop as
you might have other threads that need to run *AND* have to obey threading
requirements. So you would need to use a timer that calls your code at the
right time, much like 'sys_timemout', but on µs base. I'm not sure how that
would work.

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?

> May be we can have a new `u64_t sys_now_us()` to allow fine 
> grained timing in lwIP ? Defaulting to `sys_now()*1000`.

That might be an idea, but it doesn't really work as sys_now() overflows after
~49 days. Differences between to u32_t still work, but if you multiplied this
by 1000 and compared 2 u64_t, you'd get a huge negative diff after ~49
days...

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...

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/