We are looking for an http client now as well. Our major issue revolves around the download times for tftp.
Can Volkmar Uhlig kindly provide the patches?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us?
Jeffery Palmer
Project Development
954.709.7232
_____
From: Mark T [mailto:mark@astfin.org] Sent: Wednesday, July 22, 2009 8:47 AM To: Jeff Palmer Subject: Fwd: [U-Boot] http client?
fyi
Begin forwarded message:
From: Robin Getz rgetz@blackfin.uclinux.org Date: July 22, 2009 8:26:58 AM GMT-04:00 To: u-boot@lists.denx.de Cc: Ben Warren biggerbadderben@gmail.com, Volkmar Uhlig vuhlig@us.ibm.com Subject: Re: [U-Boot] http client?
On Tue 21 Jul 2009 17:09, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200907211400.21275.rgetz@blackfin.uclinux.org you wrote:
I know there have been discussions about adding wget to U-Boot,
which I agree is not something that is worthwhile to do.
I am not so sure about that, but that's just my opinion.
http://lists.denx.de/pipermail/u-boot/2006-March/013697.html
but a simple client would be helpful in many situations.
There is such in IBM's port of U-Boot for the Blue Gene super-
computer, and Volkmar Uhlig promised to submit patches. But so far he
didn't.
Hmm.. That sounds interesting. Do you know if there is a public repository? or Do I need to buy a Blue Gene to get access to the source :)
According to: http://domino.research.ibm.com/comm/research_projects.nsf/pages/kittyhawkind...
We added a simple HTTP server to U-Boot so that individual nodes can be
booted via a PUT command that pushes the desired boot images and kernel
command line. The command line is evaluated via the scripting environment
before it gets passed on to the OS kernel thereby allowing per node
customizations. With this simple extension to U-Boot we are able to
construct powerful scripted environments and bootstrap large numbers of
nodes in a controlled, flexible, and secure way.
What is in RedBoot is a "HTTP GET".
So -- while it shouldn't be hard to extend from there...
If a port of the redboot functionality is done - any thoughts on if
it would
be accepted?
Well, you are aware that such a thing would need a TCP/IP stack, which
is far beyond what we currently have in U-Boot support?
Yes - I'm aware. My thoughts were to do something like what IBM and other suggestions were - use lwip.
-Robin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
__________ NOD32 4266 (20090722) Information __________
This message was checked by NOD32 antivirus system. http://www.eset.com
Dear "jeffery palmer",
In message BLU127-DAV686E79B5BF3A896935555A91B0@phx.gbl you wrote:
We are looking for an http client now as well. Our major issue revolves around the download times for tftp.
HTTP will probably not be much faster.
Did you try using NFS?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
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?
Best regards,
Wolfgang Denk
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
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
On Wed, 2009-07-22 at 12:00 -0400, jeffery palmer wrote:
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.
http://www.sics.se/~adam/uip/uip-1.0-refman/
I used it before on a small arm platform (small =16k ram) and used it for a tftp server and http server.
Have no idea about performance I was only interested in it working at all so never tried to measure anything or tune any parameters.
On Wed 22 Jul 2009 10:04, jeffery palmer pondered:
We are looking for an http client now as well. Our major issue revolves
around the download times for tftp.
Can Volkmar Uhlig kindly provide the patches?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ?
Do you have a patch to send - or that I can clean up and submit?
We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us?
Yes - Although it sounds like your schedule is more immediate than mine...
Robin Getz wrote:
On Wed 22 Jul 2009 10:04, jeffery palmer pondered:
We are looking for an http client now as well. Our major issue revolves
around the download times for tftp.
Can Volkmar Uhlig kindly provide the patches?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ?
Do you have a patch to send - or that I can clean up and submit?
Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago.
regards, Ben
On Wed 22 Jul 2009 16:32, Ben Warren pondered:> Robin Getz wrote:
On Wed 22 Jul 2009 10:04, jeffery palmer pondered:
We are looking for an http client now as well. Our major issue revolves
around the download times for tftp.
Can Volkmar Uhlig kindly provide the patches?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ?
Do you have a patch to send - or that I can clean up and submit?
Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago.
I see:
#define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE;
/* try for more effic. blk size */ pkt += sprintf((char *)pkt,"blksize%c%d%c", 0,TftpBlkSizeOption,0);
but that is it...
No CONFIG_ options for anything else?
Robin Getz wrote:
On Wed 22 Jul 2009 16:32, Ben Warren pondered:> Robin Getz wrote:
On Wed 22 Jul 2009 10:04, jeffery palmer pondered:
We are looking for an http client now as well. Our major issue revolves
around the download times for tftp.
Can Volkmar Uhlig kindly provide the patches?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ?
Do you have a patch to send - or that I can clean up and submit?
Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago.
I see:
#define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE;
/* try for more effic. blk size */ pkt += sprintf((char *)pkt,"blksize%c%d%c", 0,TftpBlkSizeOption,0);but that is it...
No CONFIG_ options for anything else?
Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think).
Is this not good enough?
Ben
On Wed 22 Jul 2009 16:53, Ben Warren pondered:
Robin Getz wrote:
I see:
#define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE;
/* try for more effic. blk size */ pkt += sprintf((char *)pkt,"blksize%c%d%c", 0,TftpBlkSizeOption,0);but that is it...
No CONFIG_ options for anything else?
Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think).
Is this not good enough?
When I looked at the RFC data
blocksize no gateway with gateway --------- ---------- ------------ 512 23.85 37.05 1024 16.15 25.65 1432 13.70 23.10 2048 10.90 16.90 4096 6.85 9.65 8192 4.90 6.15
it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time...
-Robin
When I looked at the RFC data it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
net.c confirms it:
/* Can't deal with fragments */ if (ip->ip_off & htons(IP_OFFS | IP_FLAGS_MFRAG)) { return; }
I don't think it's worth adding.
/alessandro
On Wed 22 Jul 2009 18:00, Alessandro Rubini pondered:
When I looked at the RFC data it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
I don't think anyone said it did.
net.c confirms it:
/* Can't deal with fragments */ if (ip->ip_off & htons(IP_OFFS | IP_FLAGS_MFRAG)) { return; }I don't think it's worth adding.
This is based on ... ?
If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds, 4096 byte block size == 6.85 seconds) it might be worth the complexity...
At least worth it enough to give it a try, gather some results, and then make a decision.
-Robin
I played around with setting the TFTP block size very large, like 16K, primarily to reduce the required number of ACK's. It actually appeared as though uboot was processing the additional frames correctly but without doing a memory comparison I'm not sure. Here were a few bad side effects though... - blksize set to 16K, when fetching a 10 byte file it thinks it's downloading a 6000 byte file - The last packet appears to mess things up. The majority of the transfer goes very well and then at the very end it hangs. Likely the portion of tftp.c that checks when the file is completed.
UDP packets are either not fragmented or very easy to re-assemble. When doing a tcpdump the udp packets go out as 1500 byte chunks. A 16K tftp block gets broken into 11 consecutive packets and requires only 1 ACK. Because packets can come in out of order and uboot is not very network oriented, I would suggest just dumping the entire block if a packet comes in out of order and re-request that block.
Anyways, you can jump right in by setting the blksize to a large number and see how it behaves.
When I looked at the RFC data it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
I don't think anyone said it did.
net.c confirms it:
/* Can't deal with fragments */ if (ip->ip_off & htons(IP_OFFS | IP_FLAGS_MFRAG)) { return; }I don't think it's worth adding.
This is based on ... ?
If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds, 4096 byte block size == 6.85 seconds) it might be worth the complexity...
At least worth it enough to give it a try, gather some results, and then make a decision.
-Robin
Me:
Just tried it: U-Boot doesn't support reassembly, it seems.
Robin Getz:
I don't think anyone said it did.
I'm sorry, I misread that in your message.
Me:
I don't think it's worth adding.
Robin:
This is based on ... ?
laziness, mainly. And personal preference over simpler code where possible.
But you are right, no real reason. So I've done it trivially (see patch posted today). On my LAN it doesn't make any noticeable difference: only I have more lost packets if I increase the block size too much, so it gets worse.
I would like to know if it helps Jeffery Palmer.
BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first?
/alessandro
I didn't add fragmenting but without further investigation into it I would assume that the fragmented packets were discarded. The tftp program still acted like it was downloading at a larger block size but I doubt it actually was.
I have noticed a reasonable amount of lost packets as well which is odd. We have a 100 meg fiber to our servers and I still get lost UDP packets. I think there is a pending bug in the network layer regarding this.
I will have a look at the patch and revert. Thanks.
Jeffery Palmer Project Development
-----Original Message----- From: rubini-list@gnudd.com [mailto:rubini-list@gnudd.com] Sent: Friday, July 24, 2009 4:12 AM To: rgetz@blackfin.uclinux.org Cc: u-boot@lists.denx.de; biggerbadderben@gmail.com; jefferypalmer@hotmail.com Subject: Re: [U-Boot] http client?
Me:
Just tried it: U-Boot doesn't support reassembly, it seems.
Robin Getz:
I don't think anyone said it did.
I'm sorry, I misread that in your message.
Me:
I don't think it's worth adding.
Robin:
This is based on ... ?
laziness, mainly. And personal preference over simpler code where possible.
But you are right, no real reason. So I've done it trivially (see patch posted today). On my LAN it doesn't make any noticeable difference: only I have more lost packets if I increase the block size too much, so it gets worse.
I would like to know if it helps Jeffery Palmer.
BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first?
/alessandro
On Fri 24 Jul 2009 04:11, Alessandro Rubini pondered:
BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first?
I believe it depends on if it your host has gig support (for jumbo frames) Most Gig hosts/routers/gateways nowadays do...
http://en.wikipedia.org/wiki/Jumbo_frame
However - it looks like it might be a bug in the Linux networking stack (I'll ask on netdev) that if the Gig card is connected as 100, it should not be sending jumbo frames (from what I understand -- it is a spec violation).
I tried on my subnet - and was able to transfer 4k packets without issue (which is as big as I tested). (dumb repeater/hub between U-Boot & the tftp server). However - my MAC running on U-Boot is 10/100 and does not support jumbo frames, and tosses the frame as a "Frame too long", and is truncated to 1556 (0x614) bytes in all cases, so if the host is not fragmenting things properly - I can't test it... :(
On Wed 22 Jul 2009 10:04, jeffery palmer pondered:
We are looking for an http client now as well. Our major issue revolves around the download times for tftp.
Can Volkmar Uhlig kindly provide the patches?
Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes.
Jeff:
Can you look at the recent changes to the net/next tree/branch?
On a slow connection -- I saw things go from 15:28 download (tftpblocksize == 1468) to 1:47 (tftpblocksize == 16268) - more than a 8x difference.
Even if you look at the your stated time of 50min - that should drop it to a more reasonable ~6ish....
participants (6)
-
Alessandro Rubini -
Ben Warren -
jeffery palmer -
Kenneth Johansson -
Robin Getz -
Wolfgang Denk