Jump to content

H5 usb slow speed


chris.lx

Recommended Posts

I use a NEO2 (H5), with armbian linux 4.19.13-sunxi64, and have a StarTech usb2.0 to Gigabit-ethernet adapter, which I plug in the usb slot of the NEO2 and which gives me a new additional ethernet interface.

 

iperf3 on this interface (against another NEO2 with its generic gigabit interface) gives maximum 111 MBit/sec, even with the tips in https://forum.armbian.com/topic/7001-slow-usb-speed-on-h5-devices-orangepi-prime-probably-cpu-governor-related/ (which actually dont change much)

 

Using a raspberry pi (2B) with the same adapter and cable I get 170 MBit/sec, which is significantly more (although still not what one should hope for, which is up to 300, but maybe the StarTech is not perfect)

So the usb adapter is not the problem, and I observe similar speeds (around 100 MBit/sec) with other devices too.

 

Why is the usb in the H5 so slow? I need at least 150MBit/sec (ok not really for this adapter, actually for another one, but never mind)

Link to comment
Share on other sites

11 hours ago, chris.lx said:

Why is the usb in the H5 so slow? I need at least 150MBit/sec (ok not really for this adapter, actually for another one, but never mind)

 

Try to ID the chipset in your adapter - doing a quick google search, it might be the SMSC7500 aka Microchip LAN7500 - you can check this by looking either at the dmesg output, or just do a quick lsusb and look at things there...

 

Your observed performance is similar to what I see with the Neo2 using a Trendnet 1GB USB3.0 adapter using the ASIX Electronics AX88179 chipset...

sfx@nano2:~$ iperf3 -c 192.168.1.20 -Z -P 4
[SUM]   0.00-10.00  sec   126 MBytes   106 Mbits/sec    0             sender
[SUM]   0.00-10.00  sec   126 MBytes   106 Mbits/sec                  receiver

sfx@nano2:~$ iperf3 -c 192.168.1.20 -Z -P 4 -R
[SUM]   0.00-10.00  sec   421 MBytes   353 Mbits/sec    0             sender
[SUM]   0.00-10.00  sec   419 MBytes   352 Mbits/sec                  receiver

Search around on the forums - I recall seeing a couple of posts where the realtek based USB tend to do better due to certain features that the ASIX chip for offloads

 

That being said - it might just be the H5's USB implementation... I haven't had much need to dive into it, as generally the on-board GMAC runs fine.

 

I don't think that cpu governor has much to do with this.

Link to comment
Share on other sites

I'm also experiencing extremely slow USB write speeds  (less than 60 kBps) on the NanoPi Neo2 (H5), this seems to be new for me as I don't recall to have this issue with my previous setup.

This is how I tested it
 

root@nanopineo2:~# dd if=/dev/zero of=/SD/test.txt bs=512 count=2000 status=progress
1000960 bytes (1.0 MB, 978 KiB) copied, 18 s, 55.6 kB/s
2000+0 records in
2000+0 records out
1024000 bytes (1.0 MB, 1000 KiB) copied, 18.3359 s, 55.8 kB/s


Current setup:

root@nanopineo2:~# uname -a
Linux nanopineo2 4.19.38-sunxi64 #5.86 SMP Sun May 12 18:16:25 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux





 

Link to comment
Share on other sites

Sorry, seems to have been a mounting issue after unmounting and remouting the results are very different:

 

root@nanopineo2:~# umount -A /dev/sda1
root@nanopineo2:~# mount /dev/sda1 /SD
root@nanopineo2:~# dd if=/dev/zero of=/SD/test.txt bs=512 count=2000 status=progress
2000+0 records in
2000+0 records out
1024000 bytes (1.0 MB, 1000 KiB) copied, 0.0831834 s, 12.3 MB/s
root@nanopineo2:~# mount |grep sda
/dev/sda1 on /SD type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)



It was previously mounted like this:

 

root@nanopineo2:~# mount |grep sda
/dev/sda1 on /SD type vfat (rw,noatime,sync,gid=100,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)

 

Link to comment
Share on other sites

Well the device I am using is not an SD card, but an SMSC7500 (LAN7500) usb-ethernet adapter, but anyway here is what I did to speed transmission up to 300 MBit/sec:

 

The smsc75xx_tx_fixup procedure (in drivers/net/usb/smsc75xx.c) adds 2 dwords in front of the buffer to be transmitted, using skb_push.

 

Now I do an skb_copy_expand to presumably get a contiguous buffer before doing the skb_push:

 

static struct sk_buff *smsc75xx_tx_fixup(struct usbnet *dev,
                     struct sk_buff *skb, gfp_t flags)
{
    u32 tx_cmd_a, tx_cmd_b;

// now the following 6 lines added by me:

    struct sk_buff *skb2;
    skb2 = skb_copy_expand(skb, 8, 0, GFP_ATOMIC);
    if (skb2) {
        dev_kfree_skb_any(skb);
        skb = skb2;
    }

 

This change, although bad due to massive "unnecessary" copying, increases transmission speed from 100 MBit/sec to 300 Mbit/sec , 300% !

 

It seems that the ehci-hcd driver has some problems transmitting non-contiguous buffers.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines