Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 30 replies
  • Subscribers 678 subscribers
  • Views 4530 views
  • Users 0 members are here
Related

Self-powered hub + RF mouse + network = Fail

morgaine

Over the last several days, I've been doing a lot of testing of Pi with self-powered USB hubs.  Of the 3 hubs I possess, one is not Pi-compatible so I won't refer to it any further here.  The other two are nominally Pi-compatible and USB-compliant (they don't supply power upstream through the A-B lead), and the Pi boots fine with either of them connected, even when its power comes from one of their ports.  They are well-known and moderately expensive 4 and 7-port Belkin hubs, powered with hefty 2.5A and 3.8A mains adapters respectively:

 

  • Belkin TetraHub Hi-Speed USB 2.0 (4-Port) Hub F5U231
  • Belkin USB 2.0 Plus (7 Port) Hub F5U307

 

The testing had a single goal, to get the Pi to work correctly with 2 common USB devices attached to the self-powered hub, a mouse and a keyboard, while at the same time being connected to my local wired network.  The definition of "work correctly" for these tests was "A. Not lose any USB events" and "B. Operate normally over the local LAN without RTT anomalies nor packet loss".  Nobody could call this requirement ambitious --- it's the minimum one could demand of a networked computer today, or even less than minimum since the tests involved no thumb drive for backup for example.  (Such expansion is the reason for the hub.)

 

Soon after receiving my Pi I reported here about the substantial USB event/data loss I was seeing, which made the Pi barely usable for me.  (No USB hubs were connected at the time).  I found a wired mouse and keyboard that worked with only occasional dropouts so the Pi became more or less operational, but I had no time to pursue the USB loss issue further, until now.  "More or less operational" means I wasn't cursing too frequently, despite the losses.

 

Tethered keyboards aren't too bad for me because the keyboard rarely moves around, but I find tethered mice a poor human interface as the wire just gets in the way.  Therefore my main focus was to find an RF mouse that works with the Pi in the above configuration, and I planned to check out RF keyboards only later.  I have 6 RF mice of 4 different types:

 

  • Logitech MX-1000
  • Logitech MK320 Desktop combo (mouse only)
  • Logitech EX110 Desktop combo (mouse only)
  • Sandstrom SMWLL11

 

I won't list my wired keyboards nor wired mice for the simple reason that they all work "mostly OK" both when plugged into the Pi's on-board USB sockets and also when plugged into the self-powered hubs --- they're a combination of Logitech, Dell, and unbranded others.  "Mostly OK" means that there is an occasional USB event lost, but other than that, they fall into my "more or less operational" category.  (Not really satisfactory, but then, this is the Pi ...)

 

To avoid this post getting too long, I'm going to summarize my results ruthlessly, because despite a little variation, they all fall into the same ballpark:

 

  • If any of the above RF mice is plugged into either of the above self-powered hubs, then USB event/data loss increases from minimal to massive, USB response often disappears altogether for 5-10 seconds at a time (both mouse and keyboard), network ping RTT changes from a nominal 0.5 ms to thousands of times longer (1-13 seconds),  Ethernet controller read and write failures appear repeatedly in /var/log/messages, and all higher-level network activity such as ssh or NFS ceases or fails.
  • Replacing the RF mouse by a wired one usually ends the problem and returns the system to normal (but not perfect) operation.  Sometimes, unplugging the RF mouse is not enough and the hub needs to be unplugged from the Pi and replugged, which almost always ends the problem as long as no RF mouse is connected.  A couple of times I also had to reboot to recover.

 

This difference between RF and wired mice is so striking and so unambiguous that I'll just leave it at that.

 

From my experience, the Pi is not usable with RF mice attached to self-powered hubs, if my hubs are representative.

 

These tests were carried out with Raspbian updated to the latest packages and RPF firmware.

 

Morgaine.

Parents

  • Great analysis.  Personally, my feeling is that a mouse must have a tail, otherwise it's more like a vole.  Also, the correct way to carry a dead mouse is always by the tail image so carrying a dead wireless mouse is icky.

     

    Still, it's quite silly that tail-less mice would misbehave so significantly.  I wonder what's going on?  The RasPi Verified Peripherals wiki http://elinux.org/RPi_VerifiedPeripherals#USB_Mouse_devices does list a number of wireless mice (none of yours as far as I can tell).  One wireless "gaming" mouse is listed as a problem device, but includes a work-around where the user added "usbhid.mousepoll=8" to the kernel command line.

     

    The heading of the Mouse list does give this caveat: "USB mouse devices that present themselves as a standard HID (Human Interface Device) device should work, however some hardware requires special drivers or additional software, usually only compatible with Windows operating systems."  So maybe your wireless mice are in that category.

     

    Have you tried plugging the wireless mouse controller directly into a RasPi USB jack, or does it draw too much current?

  • in reply to johnbeetem

    The Logitech MK320 mouse and the Sandstrom both have RF dongles that run stone cold, so high power draw is unlikely.  The other two connect to a host port via a lead and their receivers are encased in a larger plastic body so it's hard to tell, but I certainly can't detect any warmth at all, just ambient.

     

    I haven't tested all 4 plugged directly into the Pi, but back when I originally received the board I tested the two RF mice that I had spare at that moment, the Sandstrom and Logitech MK320 again.  In fact I bought the MK320 just for use with the Pi.  Both of them gave me a lot of trouble with lost USB events, but I didn't quantify it at the time and just switched over to wired as soon as I discovered that that made most of the problem go away.

     

    Regarding networking problems at that time, they were nothing like this --- I was playing music over NFS, and I think I'd have noticed a complete outage. image image

     

    PS. Those early days were on Squeeze though, before RPF began tinkering with USB poll rates.

     

    Morgaine.

  • in reply to morgaine

    PS. Those early days were on Squeeze though, before RPF began tinkering with USB poll rates.

    Maybe a useful thing to do would be step through kernel versions and find out when the problem got worse. That might help identify the offending 'fix' which could then be removed.

     

    It's going to be rather annoying when a possible fix for one issue causes so much problems for others. I don't see any light at the end of that tunnel though, not until someone manages to re-write the driver at least.

  • in reply to Former Member

    selsinork wrote:

     

    I don't see any light at the end of that tunnel though, not until someone manages to re-write the driver at least.

     

    Yep.  Which means that for the forseeable future, the Pi is only fully operational without USB-based HIDs at all (bearing in mind that there are still occasional USB errors even with wired mice+k/b and no hubs), or else entirely headless.

     

    Both of those scenarios have possible applications (the first for media devices controlled through the network, and the second for stateless servers that don't use USB for anything other than networking), but it's a small subset of the Pi's target application areas.

     

    What's more, I haven't fully quantified the Pi's networking behaviour yet, and since that works over USB it would be unsafe to state that it's fine without comprehensive testing.

     

    Morgaine.

  • in reply to morgaine

    most of my use cases are headless and I haven't come across any obvious network problems recently. There were some ways to oops earlier kernels with heavy network traffic along with something else on usb, but that got fixed some time ago now.

     

    Still, It's why I suggested in an earlier thread that I could be happy with a model A, then use one of the SPI based ethernet chips and disable usb completely.

Reply
  • in reply to morgaine

    most of my use cases are headless and I haven't come across any obvious network problems recently. There were some ways to oops earlier kernels with heavy network traffic along with something else on usb, but that got fixed some time ago now.

     

    Still, It's why I suggested in an earlier thread that I could be happy with a model A, then use one of the SPI based ethernet chips and disable usb completely.

Children
  • in reply to Former Member

    selsinork wrote:

     

    Still, It's why I suggested in an earlier thread that I could be happy with a model A, then use one of the SPI based ethernet chips and disable usb completely.

     

    That's an excellent suggestion.

     

    What's more, a microcontroller with embedded MAC and external PHY doesn't cost hugely more than an Ethernet controller device with embedded PHY, so there is the potential for TCP offload to the micro to partially mitigate the slow speed of SPI if networking speed is important.  (In many cases it's not.)

     

    There's no shortage of alternatives, and a fully working Model A can be far more useful than a Model B on which the "extra features" don't work.

     

    Morgaine.

  • in reply to morgaine

    Morgaine, there have been suggestions that mixing USB 1.1 and 2.0 devices causes problems and that having too many interrupt and isochronus endpoints  cause problems. I have a feeling these aspects may be more important than power draw (which can be overcome by a good hub) (unless hubs themselves are a problem, of course!).

    You have to check these things on a working system, of course; I use my desktop Ubuntu system. For those who aren't familiar with usb stuff, I use 'lsusb' to identify the vendor and product id of the device in question, and then sudo lsusb -v -d vvvv:pppp to retrieve the usb version and endpoint descriptions. That's Linux of course, I don't know how to get this information from Windows or Mac systems.

     

    I have checked my keyboards and mice and some Bluetooth dongles. The dongles had a lot more endpoints than I had expected. Currently I only have a 1.1 keyboard and a 2.0 mouse and my system seems reliable, although I have not started an X11 display yet.

     

    Any suggestions on how and where to set up a public spreadsheet are welcome... The elinux wiki maybe?

  • in reply to pholynyk

    Morgaine, there have been suggestions that mixing USB 1.1 and 2.0 devices causes problems and that having too many interrupt and isochronus endpoints  cause problems.

    Why don't we just leave it at USB causes problems. image

  • in reply to pholynyk

    Phil Olynyk wrote:

     

    Morgaine, there have been suggestions that mixing USB 1.1 and 2.0 devices causes problems and that having too many interrupt and isochronus endpoints  cause problems.

     

    They're all Pi problems, not device problems, since the devices are class-compliant as shown by working perfectly with generic class drivers in countless millions of installations throughout the world.

     

    It's these Pi problems that the testing is designed to narrow down.  Totally repeatable black-white tests are extremely valuable in this context, and if the driver developers come up with improvements then retesting will show whether the issue has been resolved or not.