On Fri 31 Jul 2009 08:16, Alessandro Rubini pondered: > >> 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?
Yes. And I can see the same in wireshark. > Or is it loosing some? No. > 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. No problem. I want to make sure it is robust as well. > > 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. But it is for the state that you described - the user cntr-C a current transfer, and the reassembly algorithm doesn't know to throw away a partially accepted packet, when things are cancelled... > A soon as I have a fragment for a new packet, the old packet is > discarded (while unfragmented stuff flies intermixed). Which works when you receive a complete fragment. As you indicated - what really happens is it causes a timeout on the first packet. Up to you if you want to handle this or not... All that should be needed is just to clear things in the start of NetLoop() (before eth_init) - there are a few things in there for CONFIG_NET_MULTI already, so I don't think that is a big deal... (That becomes your timer - a one shot at the very beginning of the transfer :) -Robin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
