manitou
Senior Member+
you didn't provide all of your sketch, so one can't tell if you are using TCP or UDP. TCP has several algorithms that affect data clustering (slow-start, Nagle, delayed ACK). At start of TCP connection, TCP slowly increases the window size to avoid flooding the network, eventually the TCP "flow-control" will stabilize around the bandwidth-delay product. TCP uses Nagle to avoid sending lots of tiny packets. With a small amount of data to send, TCP will often wait a bit to see if app is going to send more data. So what you are observing is probably normal TCP behavior. UDP will allow you to avoid such delays, but at the cost of reliability. UDP packets can be lost, duplicated, arrive out of order, ...I tried many different combinations, and the behaviour is always the same. The first write() goes in the first package. Then the next few writes() are packed together in the second package, and its transmitted around 40ms after the first. Then the third is typically the same. And after this, all seems to stabilize and there are no more delays. Even if i only do 2 small writes(), in the Teensy prints it says they took like 10uS, but in Wireshark I see the the second package being sent 40ms after the first one. Could the library maybe be waiting for more data to fill a frame or something like that? And when it actually has enough data it does not realize it and only sends the frame after a timeout? Now I'm just guessing...
Let me know your thoughts, and if you'd like to make any other tests let me know.
Last edited: