Unexplained ping delay with "USB to Ethernet" adapter

[CodeFan99]

Hi everyone,

I am running Linux with old kernel 3.10 on custom board with Huawei HiSilicon ARM Hi3536 chip.
The board includes 2 identical USB 2.0 ports. According to HW engineers there is nothing
in between of these two ports on PCB board and chip itself, only simple lines.

I am using the USB to Ethernet dongle "USB2-E100" with AX88178 chip.
The USB drivers used by that dongle are: asix.ko, usbnet.ko and static usbcore module in kernel.

I connect laptop directly to that "USB to Ethernet" dongle (no routers, switch etc in between).
I experience very strange behavior.

When I ping first usb port Round-trip time (RTT) is very stable under 1 ms.

lrwxrwxrwx 1 root root 0 Feb 16 17:49 1-1 -> ../../../devices/platform/hiusb-ehci.0/usb1/1-1
lrwxrwxrwx 1 root root 0 Feb 16 17:49 1-1:1.0 -> ../../../devices/platform/hiusb-ehci.0/usb1/1-1/1-1:1.0

C:\>ping -t 172.20.20.20

Pinging 172.20.20.20 with 32 bytes of data:
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64


However if I ping second usb port, every second ping has significantly longer RTT.

lrwxrwxrwx 1 root root 0 Feb 16 17:42 1-2 -> ../../../devices/platform/hiusb-ehci.0/usb1/1-2
lrwxrwxrwx 1 root root 0 Feb 16 17:42 1-2:1.0 -> ../../../devices/platform/hiusb-ehci.0/usb1/1-2/1-2:1.0

C:\>ping -t 172.20.20.20

Pinging 172.20.20.20 with 32 bytes of data:
Reply from 172.20.20.20: bytes=32 time=873ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time=866ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time=855ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time=841ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time=835ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time=827ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64
Reply from 172.20.20.20: bytes=32 time=812ms TTL=64
Reply from 172.20.20.20: bytes=32 time<1ms TTL=64

Can anyone advise what might cause this strange behavior?
The same drivers, identical configuration registers, both connected to the same USB hub ...
Thanks in advance

 

[f33dm3bits]

Do you mean you get different results when having plugged the usb dongel in two different usb ports using the same usb hub? Maybe there's a deffect causing a delay in the second port? Also you seem to be running on Windows since letter drives are a Windows thing.

 

[f33dm3bits]

C:\>ping -t 172.20.20.20

Do you mean you get different results when having plugged the usb dongel in two different usb ports using the same usb hub? Maybe there's a deffect causing a delay in the second port? Also you seem to be running on Windows since letter drives are a Windows thing.

 

[CodeFan99]

Do you mean you get different results when having plugged the usb dongel in two different usb ports using the same usb hub? Maybe there's a deffect causing a delay in the second port? Also you seem to be running on Windows since letter drives are a Windows thing.

Yes, exactly I get different results when plugging the usb dongel in two different usb ports sitting on the same internal usb hub. The ping comes from Windows laptop connected via direct cable, but question is about Linux side.

 

[f33dm3bits]

Yes, exactly I get different results when plugging the usb dongel in two different usb ports sitting on the same internal usb hub. The ping comes from Windows laptop connected via direct cable, but question is about Linux side.

I already mentioned what I think it is. Since with the one usb port you get normal results and the other one you don't. I think there maybe a slight defect causing a delay with the second usb but not bad enough to completely prevent the communication from going through since you don't need to configure anything specia for usb ports. If it was a Linux problem you would probably get the same result from both usb ports, the best way to test this would be to plug the dongle into another system running Linux either an installed system or from liveboot.

 

[CodeFan99]

I already mentioned what I think it is. Since with the one usb port you get normal results and the other one you don't. I think there maybe a slight defect causing a delay with the second usb but not bad enough to completely prevent the communication from going through since you don't need to configure anything specia for usb ports. If it was a Linux problem you would probably get the same result from both usb ports, the best way to test this would be to plug the dongle into another system running Linux either an installed system or from liveboot.

Do you mean HW defect? The same problem appears on all same boards, but I am not HW engineer, to prove that this is HW issue.

 

[f33dm3bits]

The device(Huawei HiSilicon ARM Hi3536), is it something like a raspberry pi where you have the OS on an sd card?

 

[CodeFan99]

No, I don't think so. OS is on hard drive. The Huawei HiSilicon Hi3536 is ARM7 (H.265 Decoder Processor V100) chip. The HW board based on that chip.

 

[f33dm3bits]

Are you able to install another OS on it, for example Raspberry Pi OS? If so that way you can test your dongel from a newer OS and kernel and see how your donger reacts then. If you then get the same result from both ports then from Raspberry pi OS then it probably has something to do with the older kernel which I doubt. Since a usb device is a usb device, if it was a kernel problem the ports would react the same way on both ports. And if you get the same result as on the original Linux distribution that came with the device you can probably assume it's something to do with the hardware since it also occurs on your other devices. Then you could still see if you it is possible to do a firmware upgrade on your device to see if that makes a difference, I hope that helps but that should give you some answers.

 

[CodeFan99]

Are you able to install another OS on it, for example Raspberry Pi OS?

I doubt, I can install another OS on that board. HiSilicon has no other linux distributions which support that specific chip. Obviously I am not able to customize new linux kernel for that old board by myself

 

[f33dm3bits]

Then your only option would be to try a firmware upgrade on the board but like I said it's unlikely that it's a Linux kernel problem because then it would most likely effect both ports and not just the one.