Hello as probably noticed I have some LwIP struggles myself, but perhaps my idea sparks another one
My theory would be that writing tcp_write(40) makes lwip use a single memory-managing structure internally. Which would imply that it 'frees' the buffer once the entire structure is send - waits for the last byte to be transmitted before freeing the space. If this is the case than writing tcp_write(10) tcp_write(10) tcp_write(10) tcp_write(10) would do the trick, since you would be left with only last un-freed 10 during that long time and you could write in your next segment (again in four chunks). I think the long time could be a separate issue: lwip waits for more data to fill up the last package (to reduce the number of packages) and gives up and finally sends it after that 600ms. Did you consider turning off the naggle algo? Perhaps a solution with the split tcp_write could help. Lwip is left with last 10 units of data and is about to wait to fill up the package, and since you could do the next tcp_write you would supply it, thus it would send it sooner than waiting for the timeout... Hope it helps in any way :) -- View this message in context: http://lwip.100.n7.nabble.com/large-latency-on-last-TCP-segment-tp21227p21272.html Sent from the lwip-users mailing list archive at Nabble.com. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
