USB Slowdown

Submitted by redyeti on #1

I am currently seeing a 10x slowdown of USB speeds while operating via virtualhere vs direct, is this normal?

I'm generally seeing throughput of 5000-6000Kb/s via direct usb, but only seeing 500Kb/s through virtual here. I'm running on a Raspi server, with the client connected to the same switch. I'm still debugging if this is related to the Raspi hardware, the hub, or the software, but figured I'd start here to see if anyone has seen the same thing.

Thanks!

Submitted by Michael on Fri, 2015/07/24 - 12:44

#2

No thats not normal, the throughput from a raspberry pi is about 4000kb sec via virtualhere

Submitted by redyeti on Sat, 2015/07/25 - 08:56

#3

Oddly I'm still seeing this, even if I remove the hub, and connect devices directly into the pi. Are there any settings in my configs that could help with this? I'll put the full config file (minus license), below.

CLIENT .vhui
[General]
AdminMode=0
EnableSSL=0
AutoFind=0
ReverseLookup=0
AutoRefreshLookupPeriod=30
SSLClientCert=
[Settings]
ManualHubs=nts-android-pi.lab.netflix.com:7575
[Transport]
CompressionLimit=384
PingInterval=3
PingTimeout=10
[AutoShare]
All=1
00000000618760fa=0
00000000618760fa.26720.1256.1123=0
00000000618760fa.26720.1256=0
00000000618760fa.1123=0
00000000618760fa.20194.6353.1153=0
00000000618760fa.20194.6353=0
00000000618760fa.1153=0

SERVER config.ini
It=1436569278
PingTimeout=9
TraceMsgs=0
TCPNoDelay=1
AutoAttachToKernel=0
TCPPort=7575
UseAVAHI=1
IgnoredDevices=424/ec00,424/9514,c45/7401,4b3/3025
PingInterval=4
ServerName=Android Hub
CompressionLimit=384

Submitted by Michael on Sat, 2015/07/25 - 11:16

#4

Setting files look ok. im assuming you are not running this over a VPN (as VPN's sometimes dont honor the TCP_NODELAY flag virtualhere uses which slows throughput a lot) as you said its a direct cable connection to the client via a switch.

It seems you are connecting a lot of devices at once, are you getting 500kb sec per device or in aggregate? If you are getting 500kb sec per device that is expected if you are using/updating multiple devices at once whichbecause the pi is not that powerful and it shares is USB with the network cable.

If you are getting 500kb sec in total then that is not right, so see what cpu usage on your pi your are using via top. See if its waiting in the kernel/user or idle.

The way i test pi throughput is to run apple configurator or my ipad and that transfers approx 1.2GB via usb over 10mins via Bulk/Interrupt and control transfers, and i can see the throughput on this is 4MB by looking at the osx process manager network throughput tab. Also another test is to copy a large file to a shared USB disk via virtualhere in windows and see the throughput there.

If possible install the virtualhere on an linux amd64 box and try whatever you are doing and see if its substantially better than 500kb sec on that. If so then its another clue the pi might be underpowered for your application.

Submitted by redyeti on Tue, 2015/07/28 - 07:16

#5

When running this, I see the CPU usage for the vhusbarmhf process shoot up to 73%, with 5.5% idle on the pi, which seems to be normal for this.

I am getting 500kb/s on one device, not in aggregate.

Submitted by Michael on Tue, 2015/07/28 - 11:27

#6

Ok, looks like the pi cpu is really busy so i think its a cpu limitation of the pi, i think its underpowered for your use-case

Submitted by osiris990 on Fri, 2015/09/04 - 12:59

#8

Thought I might comment on this thread based off of my own experiences in using this product with the Pi and Pi2. Depending on the amount of USB devices you have connected, the type of devices they are, and how much data they each push across the USB bus, you might be running into the bandwidth limitations of the Pi USB bus.

See, the Pi (and Pi2) USB ports actually all share a USB bus. This isn't abnormal on its own, but what is problematic is that this bus is also used by the ethernet port. In situations where you have multiple highly-active devices connected, you can wind up inadvertantly throttling your USB busses or your ethernet port. I had this exact problem, and unfortunately the only solution that I could identify was to reduce the overall load on the bus by connecting to the network via ethernet instead of using the wifi card that I had attached.

This may not be your problem, but it's a problem I ran into that caused me a ton of problems until I finally identified the issue. I hope that might help some.