How do I change the window size for FTP server

[MattJCole]

I am using. KSDK Version: 1.3.0, RTCS v4.2.0: (I believe this is the version I am using. I go the version from the rtcs_changelog.txt),Processor: MK65FN2M0xxx18

I need to increase the number of bytes sent in an FTP packet. I found the variables FTPC_BUF_SIZE, FTPSRVCFG_TX_BUFFER_SIZE, FTPSRVCFG_DATA_BUFFER_SIZE in the RTCS. They were set to 1460. I changed them but the FTP would still only send 1460 bytes of data.  I set a break point in the send function in sock.c and it does call socket_ptr->PROTOCOL->SOCK_SEND with the correct length but it sends the data in multiple packets. I believe if I change the window size, I will be able to send larger FTP packets. What do I need to change to increase the window size for FTP server?

[MattJCole]

Know I need to figure out why the fread function is taking 60 ms to read 1460 bytes. When in crease the read to  2920 bytes it to 120 ms to read.

[MattJCole]

I am going to disable the Nagel algorithm and retest. I think it will download the file much faster after I disable the Nagel algorithm.

[mjbcswitzerland]

Hi

Your PC (192.168.3.191) is establishing the data connection for the file download ("test.bin").
The MSS is 1460 and the PC's TCP Rx window size is 64k.
The embedded stack's TCP Rx windows size is 1460 bytes (although this is not relevant for a download).

The embedded system takes 300ms to access the file and start downloading the data in packets of 1460 bytes.
The PC acknowledges each packet after a delay of about 40ms (delayed acks - see "Nagel algorithm" for reason).

Each time there is a TCP ack the embedded system requires about 20..40ms to prepare and send the next packet of 1460 bytes.

Therefore the throughput during the download is around 1460 bytes each 60..80ms and thus around 20kBytes/s.

Therefore the embedded system is sending one frame and waiting for an ack before sending the next (un-buffered TCP with low data rate). This can be improved by disabling the Nagel algorithm in the TCP/IP stack of the PC so that it doesn't wait 40ms to ACK and will likely increase the throughput to maybe 60kByte/s since there looks also to be a subsequent limit due to slow data retrieval or response time.

Here is the comparison with my download:

The difference is that buffered TCP is in operation and so not just one frame is sent before receiving an ACK but multiple ones (standard buffered TCP operation, which breaks the Nagel delay and thus ensures fast transmission. The PC will ack as soon as two frames have been received (about 50us delay).

The uTasker stack and file system are faster than the standard ones so there is also only a few hundred us delays involved rather than the 20..40ms delays in order to obtain 800kBytes/s throughput.

Some stacks, or FTP implementations, will use non-buffered operation for simplicity (and easier reliability) therefore you may find that you need to modify the FTP server, or you may find a TCP socket setting that allows the socket to do buffered TCP so that the FTP server can 'queue' more data. Once you have done that I expect you will achieve 80..100kBytes/s.

Note that the present FTP behavior will become slower in the Internet when additional round-trip delay is encounter and TCP buffering also solves this by allowing multiple frames to be sent without requiring an ack to each.

Regards

Mark

[MattJCole]

Attached is the wire shark capture

[MattJCole]

Turns out I was looking at the wrong setting RFC1323. Recommends you set tine window size to 64Kbytes. Is there a way I can change the window size?

[mjbcswitzerland]

Hi

The window size if controlled by the TCP peer that is receiving the data so it won't change the size of data that is being sent by the FTP server during a download in case it could be configured at the server side.

If the FTP client is Windows (MAC or Linux) the size will very probably already be 64k.

As noted before you probably need to enable tx buffering and possibly increase the tx buffer size (in the stack), which is the opposite direction to the TCP windowing size. Tx buffering and the tx buffer size is  implementation specific and not governed by TCP/IP.

Please post a Wireshark recording since all these details are visible in it and it saves having to hypothesise on what is happening.

Regards

Mark

[MattJCole]

Is there a way to change the MTU size?

[mjbcswitzerland]

Hi

Ethernet's MTU of 1500 bytes is defined in RFC 895 from 1984.

If you have control over both host and client in a custom network you could develop special TCP/IP stack versions at both ends to extend this as physically Ethernet can send/receive larger frames - but it would not be able to work in other networks or in the Internet.

Regards

Mark

[mjbcswitzerland]

Hi

It sounds as though TCP is not using buffers to get that speed. Check what settings there are for using buffered TCP connections and enable them if needed. You may also need to allocate more memory to TCP sockets for them to make use of a buffered connection.

Make a Wireshark recording and post it here so that the present behavior can be checked.

In case of issues you can also use the free open source uTasker TCP/IP stack from https://github.com/uTasker/uTasker-Kinetis which works with all  Kinetis parts. I get about 800kBytes/s FTP download speed and it doesn't need any additional buffering (due to its regeneration technique) to achieve the speed.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

[MattJCole]

There must be a way to make FTP faster using the RTCS library. It currently downloads a file at 21KB per second.

[mjbcswitzerland · Accepted solution]

Hi

FTP is above IP and TCP and on Ethernet the maximum payload is 1500 bytes (MTU).

This means that the maximum TCP payload (whether FTP or other higher layer protocol, is 1500 - IPv4 header size - TCP header size. Both IPv4 and TCP headers are 20 bytes each (minimum) so the maximum TCP payload (over IPv4 and no IP options) is 1500 - 40 = 1460 bytes.

Changing FTP buffer sizes will not cause larger frame payload than 1460 bytes since it is not allowed over Ethernet. If IPv4 header options are used (for whatever reason) the payload will also go down,as it does when over IPv6.

If the TCP peer negotiates smaller MSS in the TCP handshake it can also result in smaller TCP payload too. Therefore, again, it is not a define which specifies the the payload size that is to be used since it can only specify the maximum that you want to use "when it is allowed and when the actual TCP connection doesn't specifically request a smaller size".

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT and uTasker TCP/IP stack]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html