Quoting Nicolas Dufresne (2020-08-14 22:07:11) > Follow up: > > I've tested download rate with a 125MB file over tftp. Even though > tftp code (or tftp itself?) is inefficient I could repeat the > following: > > Delay | 2 | 3 | 4 | 5 | > ------------------------------- > Mb/s | 2.0 | 2.1 | 2.7 | 2.1 | > Timeouts| 5 | 4 | 1 | 4 | > > The timeouts are the number of time u-boot pinted a T during the > transfer. I've also attempted some test form Linux side, and notice > some asymmetry, 9.7 MB/s download, and 7.8 MB/s upload. That was with > the same file with scp. > > I've then set the RX delay too, to 4, and could notice a very minimal > improvement, 8.5 MB/s upload. Now the issue is that these are all > terrible results for a gigabit ethernet. There must be other issues > around. But a delay of 4 at least makes it usable (at around 100Mb/s). > > Le vendredi 14 août 2020 à 14:26 -0400, Nicolas Dufresne a écrit : > > As asked over IRC, I have tested various TX_DELAY on Lime2 rev K. > > > > - 2, 3, and 4 was good enough to succeed a DHCP handshake. > > > > - 0 and 1 made the request to never be seen over the network. > > > > An obvious next step would be to test again with large file transfer, > > perhaps a kernel image. I will report back.
Thanks a lot for these tests. Really helpful! There _are_ other limiting factors than ethernet speed involved - I do not know what maximum to expect on this kind of board, however. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
