TFTP low throughput

Has anyone seen a problem with the B5C and low throughput on TFTP ? This link is 36Km with 100% LOS - clearance is better than Fresnel 3.

A Mikrotik UDP Bandwidth test can go up to 110Mbps with no “Lost Packets” still at 0, but TFTP throughput across the link is less than 1Mbps. Typically it appears to run at about 400 Kbps.

The TFTP Server tests to a local device that is on it’s subnet at over 470 Mbps. There are no queues on the CCR1009 routers at each end. The switches are Netonix WS24A’s. No errors on the Ethernet interfaces on either switch. I’ve tried with and without Flow Control enabled on the B5C’s and the switch ports.

A simultaneous test in the B5 comes in at approx 160Mbps x 125Mbps.

Phy PER is typically less than 2%. RX EVM’s are relatively equal at ~20 to 23 dB on both ends of the link.

-61.7 dBm
PHY Tx/Rx (Mbps): 405 / 360
MAC Tx/Rx (Mbps): 162 / 144

See if you dont have packet fragmentation with 1500 bytes packet size from end to end of TFTP server and client

The TFTP server is running on Ubuntu 12.04 LTS.

eth0 Link encap:Ethernet HWaddr 00:50:fc:xx:xx:xx
inet Mask:
RX packets:4853357 errors:0 dropped:0 overruns:0 frame:0
TX packets:8352134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000

Ping from that server to the target on the far end of the link with df bit set

ping -s 1472 -M do
PING ( 1472(1500) bytes of data.
1480 bytes from icmp_req=1 ttl=62 time=11.0 ms
1480 bytes from icmp_req=2 ttl=62 time=9.80 ms
1480 bytes from icmp_req=3 ttl=62 time=11.9 ms
^C ping statistics —
17 packets transmitted, 17 received, 0% packet loss, time 16023ms
rtt min/avg/max/mdev = 8.901/10.924/15.916/1.585 ms

Checking out I think I’ve found the reason. TFTP uses UDP for sending data. UDP doesn’t have any resiliency, so the TFTP protocol has to provide for the possibility of packet loss. Being “Trivial” to implement, they chose to require that each data packet is acknowledged before the next one is sent. Also, they defined a default data packet size of 512 bytes. For the sake of easy math, I’m just going to assume that 500 bytes of that packet are data. 500 bytes * 8 bytes/bit = 4Kbits data per packet. Since TFTP waits for the ACK before sending more data, if we assume no more CPU time than is need to reply to a ping, then we can use the average ping round trip time of 11ms. 4Kb/11ms = 4Kb/.011sec = 400Kb/1.1sec, or about what you were seeing. So the only way to make TFTP go faster is to reduce your latency.

Wow I’ve always assumed that being UDP it would be less connection oriented. But the math is pretty darn close so it makes sense.

Thanks Dude!