Slow Pandaboard Transfer Speeds

A FIQProf profile of a (single-tasking?) file upload/download over a high-latency link might allow you to quickly identify where all the busy-wait loops are and what the triggers are for leaving those loops.

Under RPCEmu RISC OS consistently responds to the sender in under 2 milliseconds, and no packets are dropped. The delay is waiting for the network cables and sender to send more data.

So basically my contribution is “stop speculating and profile the code, you big dummies!” ;-)

A packet sniffer is more useful.

The problem is that RISC OS never sends a window size larger than 17376 bytes, so the sender correctly never sends more than 17376 bytes beyond what it has received acknowledgements for. The window size and receive buffer need to be a few megabytes in size.

Trying to adjust the receive buffer using sysctl doesn’t help:

sysctl -w net.inet.tcp.recvspace=100000

Attempting to set a 1 megabyte receive buffer using sysctl causes RISC OS to fail to create a TCP socket:

sysctl -w net.inet.tcp.recvspace=1000000

Adjusting the receive buffer with setsockopt does speed it up:

size_t bufsize = 262144;
setsockopt(s, SOL_SOCKET, SO_RCVBUF, &bufsize, sizeof(bufsize));

However attempting to set any value larger than 262144 returns ENOBUFS (No buffer space available), and needs to be a lot larger, about 2.5 megabytes for a 100Mbps round the world connection.

Trying likewise for the send buffer breaks my test case, it closes the connection without sending anything.

Making the default large enough would however quickly exhaust the available amount of memory. At least Linux and FreeBSD adjust the size of the buffers to match network conditions.

Generally you get to the stage where a packet buffer isn’t available and you have to drop the packet

without any way to stop TCP retries (flow control)

Do you have any evidence of RISC OS dropping packets on a TCP connection? A slow application should not cause TCP retries, instead the TCP window size sent to the sender should be reduced.