>No. You'll just get threading problems when starting something like that... In my architecture, when I need an interrupt process (like for handling Rx) the Interrupt process is just triggering a handler process. The handler process and any other process from the driver have the same priority and will not intercalate each other. By doing this I believe I am in compliance with the "multi-thread issue" of the raw API, because any invoked LWIP function will return before any other LWIP function starts being executed.
Em qui, 11 de out de 2018 às 21:47, goldsimon <goldsi...@gmx.de> escreveu: > > > > vr roriz wrote: > >That's my point, I thought it would be totally unpredective. But after > >some certain amount of data is periodically queued, the RTT starts to > >go down again and the throughput is achieved. That is what I would > >like to understand. > > I think tcp_output() is called every time an rx segment is processed for a > pcb, even if it doesn't contain data but only an ack. This is to,achieve > throughput like you want. You just cannot rely on it regarding throughput. > But this could well explain your measurements... > > >Do you think it would be a good idea to call > >tcp_output from some custom timer? (Since the poll callback has a very > >high resolution). > > No. You'll just get threading problems when starting something like that... > > Call tcp_output() when you want to send data. In other words, if the > application calling your code controls send_now, make them set it to 1 for > the last call. > > Simon > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
