Re: [U-Boot] TCP & Overrrun
On Sun, 11 Feb 2018 00:39:05 +0000 (UTC) Duncan Hare dh@synoia.com wrote:
Duncan Hare
714 931 7952
----- Forwarded Message ----- From: Joe Hershberger joe.hershberger@ni.com To: Duncan Hare dh@synoia.com Cc: Joe Hershberger joe.hershberger@ni.com; u-boot u-boot@lists.denx.de Sent: Friday, February 9, 2018 1:11 PM Subject: Re: [U-Boot] TCP & Overrrun
On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare dh@synoia.com wrote:
On Thu, 8 Feb 2018 22:15:44 +0000 (UTC) Duncan Hare dh@synoia.com wrote:
Duncan Hare
714 931 7952
----- Forwarded Message ----- From: Joe Hershberger joe.hershberger@ni.com To: Duncan Hare dh@synoia.com Cc: u-boot u-boot@lists.denx.de; Joe Hershberger joe.hershberger@ni.com Sent: Thursday, February 8, 2018 11:40 AM Subject: Re: [U-Boot] TCP & Overrrun
Hi Duncan,
On Wed, Feb 7, 2018 at 8:40 PM, Duncan Hare dh@synoia.com wrote:
I'm gettin overrun on the raspberry pi.
Which ethernet drived does it use?
You didn't specify which one you are talking about, but here's how to find out...
Assuming rpi3, find the config first...
configs/rpi_3_defconfig says: CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" arch/arm/dts/bcm2837-rpi-3-b.dts says: #include "bcm283x-rpi-smsc9514.dtsi" arch/arm/dts/bcm283x-rpi-smsc9514.dtsi says: ethernet: usbether@1 { compatible = "usb424,ec00"; grep -rn ec00 drivers/ says: drivers/usb/eth/smsc95xx.c
Cheers, -Joe
I need to determine if it uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the "net_rx_packets" buffer pool defined in net/net.c
grep suggests it is not using net_rx_packets.
Thanks
Duncan Hare _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Joe
Two solutions:
Option 1.
I think option 1 is the way to go.
Thanks, -Joe
Joe
The overruns were caused by printing error messages. The print process is (very) slow compared with packet and computer speeds, and causes overruns.
I turned off all the error messages in tcp.c and the overruns also stopped.
Makes debugging harder.
Duncan
Hi Duncan,
On Sat, Feb 10, 2018 at 6:44 PM, Duncan Hare dh@synoia.com wrote:
On Sun, 11 Feb 2018 00:39:05 +0000 (UTC) Duncan Hare dh@synoia.com wrote:
Duncan Hare
714 931 7952
----- Forwarded Message ----- From: Joe Hershberger joe.hershberger@ni.com To: Duncan Hare dh@synoia.com Cc: Joe Hershberger joe.hershberger@ni.com; u-boot u-boot@lists.denx.de Sent: Friday, February 9, 2018 1:11 PM Subject: Re: [U-Boot] TCP & Overrrun
On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare dh@synoia.com wrote:
On Thu, 8 Feb 2018 22:15:44 +0000 (UTC) Duncan Hare dh@synoia.com wrote:
Duncan Hare
714 931 7952
----- Forwarded Message ----- From: Joe Hershberger joe.hershberger@ni.com To: Duncan Hare dh@synoia.com Cc: u-boot u-boot@lists.denx.de; Joe Hershberger joe.hershberger@ni.com Sent: Thursday, February 8, 2018 11:40 AM Subject: Re: [U-Boot] TCP & Overrrun
Hi Duncan,
On Wed, Feb 7, 2018 at 8:40 PM, Duncan Hare dh@synoia.com wrote:
I'm gettin overrun on the raspberry pi.
Which ethernet drived does it use?
You didn't specify which one you are talking about, but here's how to find out...
Assuming rpi3, find the config first...
configs/rpi_3_defconfig says: CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" arch/arm/dts/bcm2837-rpi-3-b.dts says: #include "bcm283x-rpi-smsc9514.dtsi" arch/arm/dts/bcm283x-rpi-smsc9514.dtsi says: ethernet: usbether@1 { compatible = "usb424,ec00"; grep -rn ec00 drivers/ says: drivers/usb/eth/smsc95xx.c
Cheers, -Joe
I need to determine if it uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the "net_rx_packets" buffer pool defined in net/net.c
grep suggests it is not using net_rx_packets.
Thanks
Duncan Hare _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Joe
Two solutions:
Option 1.
I think option 1 is the way to go.
Thanks, -Joe
Joe
The overruns were caused by printing error messages. The print process is (very) slow compared with packet and computer speeds, and causes overruns.
I turned off all the error messages in tcp.c and the overruns also stopped.
You could probably make the printing buffered (maybe just turn on such a thing) to speed it up. You can also have different log levels to turn on different traces so you can reduce the load for printing.
Makes debugging harder.
Duncan
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Mon, 12 Feb 2018 13:35:11 -0600 Joe Hershberger joe.hershberger@ni.com wrote:
I need to determine if it uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the "net_rx_packets" buffer pool defined in net/net.c
Two solutions:
Option 1.
I think option 1 is the way to go.
Thanks, -Joe
Joe
The overruns were caused by printing error messages. The print process is (very) slow compared with packet and computer speeds, and causes overruns.
I turned off all the error messages in tcp.c and the overruns also stopped.
Duncan
----------------------------------------------------------------------- Joe
I'm now at the state where I'm satisfied the selective acknowledgment implementation is working well, having re-written the code.
I've transferred 20 4 Mbyte kernels from cloud to desktop without a failure.
How to proceed?
Issue the patch set again? Or just the TCP module?
Then what's the next step?
Regards Duncan
Hi Duncan,
On Wed, Feb 21, 2018 at 6:39 PM, Duncan Hare dh@synoia.com wrote:
On Mon, 12 Feb 2018 13:35:11 -0600 Joe Hershberger joe.hershberger@ni.com wrote:
> I need to determine if it > uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the > "net_rx_packets" buffer pool defined in net/net.c >
Two solutions:
Option 1.
I think option 1 is the way to go.
Thanks, -Joe
Joe
The overruns were caused by printing error messages. The print process is (very) slow compared with packet and computer speeds, and causes overruns.
I turned off all the error messages in tcp.c and the overruns also stopped.
Duncan
Joe
I'm now at the state where I'm satisfied the selective acknowledgment implementation is working well, having re-written the code.
I've transferred 20 4 Mbyte kernels from cloud to desktop without a failure.
How to proceed?
Issue the patch set again? Or just the TCP module?
Then what's the next step?
I think the next step is to rework your patch submission process, sending the patches to just yourself, until they meet the standard ( http://www.denx.de/wiki/U-Boot/Patches ) so that all of the tooling I use can work with them. Otherwise I spend lots of time, sometimes hours, trying to shove malformed patches through the process. I really don't have time for that, so I have to ask that you use patman and send properly formatted patches. Once you have that down, I'll re-review what you have at this point and go from there.
Thanks, -Joe
participants (3)
-
Duncan Hare -
Joe Hershberger -
Joe Hershberger