>> or simply your >> ether+uboot can't keep up with the data rate. > > That doesn't explain, why does it work, when there is no fragmentation???
Well, with no fragmentation there is less traffic. Each tftp packet is one patch, instead of a burst of packets (intermixed with pings). Is the target replying to all pings? Or is it loosing some? If it looses say 30%, I expect one fragment in 3 to be lost as well. If your big-tftp is 4 fragments, 20% passes it loss is equally spread ((2/3)^4), but I fear much less as the burst saturates the incoming queue. >> I'm pretty sure it's like this. > > I'm not convinced yet - but need to do some further poking on a different > network... Thanks for these tests, mine is just guessing. > What is missing in the reassembly code (that is described in RFC815) is the > timer. (quote from the RFC): > -------------- > The final part of the algorithm is some sort of timer based > mechanism which decrements the time to live field of each partially > reassembled datagram, so that incomplete datagrams which have outlived > their usefulness can be detected and deleted. > -------------- But I reassemble one packet only, so I don't need to timeout partly-filled packets to recover memory. A soon as I have a fragment for a new packet, the old packet is discarded (while unfragmented stuff flies intermixed). /alessandro _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
