Quoting Jonas Smedegaard (2022-06-09 12:23:53)
> Version: 2022.04+dfsg-1
>
> This bug was fixed since u-boot 2022.04 - specifically in git commit
> f11513d9: https://source.denx.de/u-boot/u-boot/-/commit/f11513d
Correction - the actual fix was the later git commit 85da5587:
https://source.denx.de
Quoting Nicolas Dufresne (2020-08-14 22:07:11)
> 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 mak
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
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 timeout
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 b
5 matches
Mail list logo
