On Don, 2017-01-12 at 14:46 +0100, rolfm@dds.nl wrote:
i'm sending data using tcpserver & tcpclient over wifi with a router in a local network.
the source patch sends 6 bytes and then waits until a single byte comes back that signals the next 6 bytes can be sent. in total 3538 data recs of 6 bytes are sent.
what could be the reason for this behaviour?
The "chattiness" of your application layer protocol. You went for the least optimal way to achieve high throughput. As for why there is a difference between Pd's [netsend]/[netreceive] and iemnet's [tcpclient]/[tcpserver] I can only guess. I believe Pd's implementation is not threaded and is executed directly in the DSP thread, while iemnet classes are threaded. While using threads is often the better solution, because it avoids blocking Pd when the network buffer is full, I assume it takes a little wee bit more time for the message to be passed from the Pd's main thread to the networking thread and thus increases the overall round trip time slightly. Since your protocol requires a full round trip for every 6 bytes, the small increase in round trip is amplified by the high number of round trips required.
I could imagine that the situation might be improved by lowering the latency in Pd's audio settings, but that's not a very substantiated guess.
Imagine you use the protocol between two computers that are more apart from each other (i.e. not in the same LAN). An increase of round trip time from 1ms to 10ms would reduce your throughput by a factor of 10.
a bug?
I don't think so. My advice is to rethink your application layer protocol. Try to reduce the "multi-ping-pong" to just one ping (containing all requests in one message) from the requesting party, answered by a single pong message from the providing party.
Let me tell from my experience, the iemnet classes are performing _well enough_ (if not excellently). It's easy to create a patch that saturates a 100Mbit/s link without consuming much CPU.
Roman