2016-08-12, 15:42
Does Kodi have control over the options for the socket opened for SMB transfers in libsmbclient?
How does the packetsize option impact the TCP window size?
I tried to change "socket options" from smb.conf, but this does not seem to affect libsmbclient sockets.
Many things may impact TCP. The TCP window size will impact how much data can be sent by the server, and for high latency links (as in my case) this will be the most problematic aspect. During testing I saw that for SMB from within Kodi, the TCP window size is static at 128 kB, when not using turbo_mode or tuning packetsize. While when mounting SMB in the file system, the TCP stream reaches 500 kB.
With turbo_mode=Y (and no additional options) I see some packet loss and retransmisions, this via the perfect (Netgear only) link. TCP window size is now fluctuating, bouncing between the 128 kB and down to around 40 kB for "direct SMB", toward the end of each data burst (32-64 kB SMB data). Could this perhaps be caused by more aggressive buffering, perhaps TCP ack offloading, on the RPi 3 side? Possibly already in the Ethernet chip, before data reaches the TCP stack? File system mounted SMB has in this scenario a TCP window size of 180 kB, which does not fluctuate, and there are much fewer packets lost/retransmitted.
When my bufferbloated router can add up to 400 ms of delay at 100 Mbps load, this 128 kB TCP window will not last long. The 512 kB TCP window fares much better, obviously. As does the turbo_mode, but I haven't analyzed the characteristics of this with Wireshark.
Utilizing the eminent throughput calculator at switch.ch, I get these numbers.
Considering I reached roughly 10 times this speed on average, the delay added by the router may have been in bursts. As I mentioned, I did see bursts of data being sent from the server, likely sending data fast at first and then building up a delay in the router, possibly seeing one packet drop, finally filling up the 128 kB allowed window on the server side, and then a pause of 0.5-1 seconds until the last of the acks arrived and transfer picked up again. I'd have to collect many more TCP traces to determine this.
How does the packetsize option impact the TCP window size?
I tried to change "socket options" from smb.conf, but this does not seem to affect libsmbclient sockets.
Many things may impact TCP. The TCP window size will impact how much data can be sent by the server, and for high latency links (as in my case) this will be the most problematic aspect. During testing I saw that for SMB from within Kodi, the TCP window size is static at 128 kB, when not using turbo_mode or tuning packetsize. While when mounting SMB in the file system, the TCP stream reaches 500 kB.
With turbo_mode=Y (and no additional options) I see some packet loss and retransmisions, this via the perfect (Netgear only) link. TCP window size is now fluctuating, bouncing between the 128 kB and down to around 40 kB for "direct SMB", toward the end of each data burst (32-64 kB SMB data). Could this perhaps be caused by more aggressive buffering, perhaps TCP ack offloading, on the RPi 3 side? Possibly already in the Ethernet chip, before data reaches the TCP stack? File system mounted SMB has in this scenario a TCP window size of 180 kB, which does not fluctuate, and there are much fewer packets lost/retransmitted.
When my bufferbloated router can add up to 400 ms of delay at 100 Mbps load, this 128 kB TCP window will not last long. The 512 kB TCP window fares much better, obviously. As does the turbo_mode, but I haven't analyzed the characteristics of this with Wireshark.
Utilizing the eminent throughput calculator at switch.ch, I get these numbers.
Code:
Bandwidth-delay Product and buffer size
BDP (100 Mbit/sec, 400.0 ms) = 5.00 MByte
required tcp buffer to reach 100 Mbps with RTT of 400.0 ms >= 4882.8 KByte
maximum throughput with a TCP window of 128 KByte and RTT of 400.0 ms <= 2.62 Mbit/sec.Considering I reached roughly 10 times this speed on average, the delay added by the router may have been in bursts. As I mentioned, I did see bursts of data being sent from the server, likely sending data fast at first and then building up a delay in the router, possibly seeing one packet drop, finally filling up the 128 kB allowed window on the server side, and then a pause of 0.5-1 seconds until the last of the acks arrived and transfer picked up again. I'd have to collect many more TCP traces to determine this.
