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. > > regards, > Nicolas >
