The ACK delays are exactly what cause the extremely long download times. There are approx 16,000 ACK cycles for my 8MB image on a 512K blksize. I upped this to 1432 to stay under the MTU which cut the ACK cycles by three, but still, on a 180ms round trip time the math is simple. 8MB/1432bytes=5580 ACK's * 180 ms = 17 minutes.
There are good reasons to use TCP/IP for doing the updates. Some of our reasons are: - Firewall/NAT/filter transversals - Passing arguments and status information to our update server, such as serial numbers, status's, etc. - Receiving uboot specific commands via update server - Error checking in TCP streams vs UDP (Alreading using checksums, but another layer of reliability wouldn't hurt)
NFS is still be stuck to the same rules as TFTP so it's not a very good option.
We already have equipment using UIP (UDP + TCP) which works great and is extremely small at ~30K of compiled code.
I am not yet familiar with the underlying network code in uboot, but is it entirely written from the ground up or based off of another project?
There are quite a few additions you can achieve with a TCP stack but of course it needs to be very clean and well tested.
Jeffery Palmer Project Development
-----Original Message----- From: rubini-list@gnudd.com [mailto:rubini-list@gnudd.com] Sent: Wednesday, July 22, 2009 11:23 AM To: wd@denx.de Cc: jefferypalmer@hotmail.com; u-boot@lists.denx.de Subject: Re: [U-Boot] http client?
Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis?
I'm sure it depends on network delays. TCP has the sliding window mechanism, so several packets can be in flight before you get a single ack. TFTP requires one ack for each data packet, doesn't it?
If you have high delays, TCP is usually a win, even with relatively low bandwidth. Otherwise, we need a an UDP protocol that doesn't require individual ack.
/alessandro