SiL3nT
Posts: 8
Joined: Mon Jul 02, 2012 2:05 am

Re: USB - the Elephant in our Room

Mon Oct 01, 2012 6:50 am

Their has not been much activity on this thread, was wondering if there was any good news about what's going on with the problem. I understand that the problem is being worked on in the spare time of one person.

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB - the Elephant in our Room

Mon Oct 01, 2012 8:57 am

The situation is improving, its a way to go before it gets as reliable as a PC's USB system, but its a lot better than it was. The latest image with the latest updates is getting fairly reasonable. With (very) careful selection of peripherals and a degree of working around, you can get the Pi to do most things. USB Webcams, Wifi adapters and USB Audio devices are troublesome, some work, some don't. Odd keyboards and mice still give problems.
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

reggie
Posts: 151
Joined: Fri Aug 26, 2011 11:51 am

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 1:50 am

My webcam still doesn't work properly :( I know loads of astronomers that would be very happy if it did. On the flipside, I've got a tiny 'edup' wifi dongle with a big fat antenna on it that works quite nicely, so things have improved for some things.

I've noticed that I can 'kill' my webcam in the only resolution it actually works in, simply by moving my mouse.

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
Contact: Website

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 2:21 am

I have had very little USB problems since the start. Occasionally lose WiFi after an update. I really have not tried to push it that much either. But I have not had problem one with the USB HDD. It is always there and waiting. I guess I may have just lucked into the right peripherals from the start.

EX100 wireless (bluetooth) keyboard and mouse.
Seagate 640GB FreeAgent go HDD.
I tried Nippon Labs 2.5" SATA/USB adapter and it worked right off. Another adapter that looked similar to that worked also.

I did have some trouble with the Lapdock and WiFI initially, but really not an issue at all anymore. I have actually had more trouble with SD cards than USB. I have not connected a camera yet, so that may change!
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 5:15 am

reggie wrote:My webcam still doesn't work properly :( I know loads of astronomers that would be very happy if it did.
You can do astronomy with a webcam? Or it's being used to detect if seeing conditions are worth driving out to some location, etc.?

If you're willing to spend a bit, and still frames instead of video is OK, I think this webcam is just about guaranteed to work, because it uses a serial interface instead of USB. And it looks like it has a screw-on lens so I suppose it could even be attached to a scope. https://www.adafruit.com/products/397

Another thought: Canon Powershot camera via USB which is running the CHDK (Canon Hack Development Toolkit) http://chdk.wikia.com/wiki/CHDK
I wonder if anyone's tried that? (it might well not work, but...)

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1442
Joined: Sat Sep 10, 2011 11:43 am

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 6:17 am

SiL3nT wrote:Their has not been much activity on this thread, was wondering if there was any good news about what's going on with the problem. I understand that the problem is being worked on in the spare time of one person.

Hi "One person" still here!

Actually it looks like I may have a partner in crime soon, I've found someone else stupid enough to be interested in the USB drivers!

So current updates...

I've found that the scheduling for split transactions is even more hair brained than I originally thought so by reducing the latency in a number of places (to improve the accuracy of transmitting split transactions) I've found that it results in the stack sending them too early!!!

OK, So having fixed that problem I've found at least another two!

One thing that was 'fun' is the linux USB stack requires that you pass back URB's to the driver whilst in interrupt context (i.e. with the interrupts disabled) I've found out that this can take up to 300us (I assume this is just a badly behaved driver like the serial one or possibly the libusb one, not casting aspersions I just don't know!) So during this delay we end up missing our assigned slot for scheduling the split transaction meaning the hub drops the data...

Whoever wrote the hub specification like this should be shot, (I've said it once, I'll say it again) basically it looks like if you send the complete one uframe early then the hub barfs, if you send it a uframe late it barfs, if you send it over a frame boundary it barfs...

In fact it's very difficult to make it not barf!

Then it looks like the driver is not handling USB1 hubs correctly... The problem is this, to talk USB1 we have to go through the USB2 hub (and we have to talk split transactions to the USB2 hub which will then talk USB 1 to the slow hub). The USB2 hub can have either one transaction translator (USB2 -> USB1) per hub or one per port, but the driver will try and use the same transaction translator more than once which will make it barf (you see how many ways there are to make it barf!)

So I do have another fix available (which will improve the latency further) but it may make some problems worse (like talking to a USB1 keyboard with integrated hub)...


What is likely to work and what is less likely...

1) USB2.0 devices work better than 1.0 or 1.1
You can check if a device is USB 2.0 by doing 'lsusb -v' and looking for the device bcdUSB version it will be 2.0 1.1 or 1.0)

2) USB 1.0 devices, don't use an extra USB hub only one USB1 device per port.

3) Bulk and Interrupt work better than isochronous, (this is mostly assumption from the stuff we've got from your reports). I'm assuming that we're getting hit by the occasional terrible interrupt latency and the streaming camera's / audio devices are over-running their fifo's.


Will try to make another bug fix in the next few days ...

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

f32mark
Posts: 36
Joined: Wed Sep 05, 2012 4:58 am

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 6:22 am

Hmmm, reading all this suggests that use of USB should be avoided if at all possible to get the most out of the Pi? Should I expect better performance out of a headless system with just an ethernet connection, or does the fact that the network and UISB traffic is shared make this an incorrect assumption?

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 6:44 am

The Ethernet connection also uses the USB bus.

Second Law of Thermodynamics: You can't win
Third Law of Thermodynamics: You can't break even
Church-Turing Thesis: You can't quit the game

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 7:33 am

As long as your supply is providing the proper voltage, the pi should work fine when you only use it's ethernet connection.
Most wifi sticks also seem to work, but they usually need more power than the 100mA that the Pi rev. 1 is capable of providing.
Usb audio devices and webcam's use the isochronous transfer. Some audio devices are reported working when the selected quality isn't 2 high. Some webcam's also work on low resolution and speed.
Usb memory sticks and harddisks also are very power hungry. I have seen reports of non working devices, but not much prove they were caused by the usb issues. A 3 TB harddisk for instance can give problems because it's not using a 512byte sector size anymore.
Keyboards and mice should work fine if they are connected to the Pi directly. If you connect them to a hub, you might observe missing keystrokes and repeating keypresses (keyup missing) wireless keyboards seem to have more issues than wired ones.
usb2serial devices and equipment emulating such still doesn't seem to work very reliable. They used to create a huge number of interrupts, but an implemented fix in the driver from Gordon reduces this now. (only when the device isn't used I think) A possible fix is reducing the usb speed to usb 1.1 speed, but that decreases network speed as well.
I tried to make this overview of the situation like it exists now as accurate as possible.
Feel free to correct where I am wrong, but not in a 'I have a working webcam setup' way. If you really feel like you should share such information to prove I am wrong, please provide as much details as possible like what webcam you are using, what distro you are using, what program you are using, what resolution you are having, what framerate you are getting. Doing so will make it possible for people to obtain the same results if they really want to try it as well.

reggie
Posts: 151
Joined: Fri Aug 26, 2011 11:51 am

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 11:24 am

jbeale wrote:
reggie wrote:My webcam still doesn't work properly :( I know loads of astronomers that would be very happy if it did.
You can do astronomy with a webcam? Or it's being used to detect if seeing conditions are worth driving out to some location, etc.?

If you're willing to spend a bit, and still frames instead of video is OK, I think this webcam is just about guaranteed to work, because it uses a serial interface instead of USB. And it looks like it has a screw-on lens so I suppose it could even be attached to a scope. https://www.adafruit.com/products/397

Another thought: Canon Powershot camera via USB which is running the CHDK (Canon Hack Development Toolkit) http://chdk.wikia.com/wiki/CHDK
I wonder if anyone's tried that? (it might well not work, but...)
You can most definitely do astronomy with a webcam :) The adafruit webcam is not suitable for this really. The spc880/900nc webcams use a ccd sensor, they can be modified to do long-exposure and already work in most of the major pieces of software for astro work. I used to use mine mainly for 'auto-guiding' but have used it for taking shots of the moon.

As for chdk, I've got a couple of canon dslr, 400d/450d and if there was a version, it probably wouldn't help, I can already do long exposure images (6minutes a shot is the longest I've done).

lb
Posts: 261
Joined: Sat Jan 28, 2012 8:07 pm

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 11:37 am

It looks like you can't really rely on the Linux kernel having low latencies. I wonder if it would be sensible and/or possible to split up the USB driver into two parts. A low-level part that does all the timing-critical stuff and is executed entirely in FIQs, and a high-level part that runs as a regular kernel driver. These two parts then communicate over a shared memory area.

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 5:58 pm

f32mark wrote:Hmmm, reading all this suggests that use of USB should be avoided if at all possible to get the most out of the Pi? Should I expect better performance out of a headless system with just an ethernet connection, or does the fact that the network and UISB traffic is shared make this an incorrect assumption?
Using a wired ethernet connection to the Pi I've never had a problem, the overlying TCP/IP protocols neutralise a lot of the inherent problems. It automatically asks for retransmission of lost packets so the packets the USB loses don't matter so much, it just slows it down a little. With wireless adapters the adapter itself does the TCP/IP thing and just passes raw data back to the Pi via the driver(s), so lost packets stay lost.
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

insanityideas
Posts: 19
Joined: Tue Oct 02, 2012 9:16 pm

Devices that work and don't

Tue Oct 02, 2012 9:40 pm

I have devices which encounter the USB packet drop problem and also ones that don't. For what its worth I post the details should it be of help to GSH in his debugging or anyone contemplating buying accessories. Here's hoping that some much appreciated hard work will rectify the problem entirely.

Plugging an 11 year old Microsoft wired USB wheel mouse optical (100ma power draw) into Pi works fine no lost clicks.

Plugging a Cherry MX3000 wired USB keyboard (16ma power draw) into Pi works fine, no lost keys

Plugging new (bought from Maplin for Pi use - not part of their new bundle) Cerulian Mini Wireless Keyboard and Mouse Deskset (2.4Ghz) into Pi works but suffers from occasional (every 30 or so characters) lost or stuck keystroke, and lost mouse clicks. Changing power supplies does not help, I suppose its down to the way it puts data packets onto the bus. Incidentally the keyboard and mouse are quite good considering the low price, but not something you would want to use all the time due to ergonomics. They work fine on a normal computer.

I have tried using different power supplies without any effect.

I have tried turning on or off the overclock, there are slightly fewer lost keystrokes with it turned off, but thats not a highly scientific measurement. The amount of CPU utilisation also appears to have no effect.

This test was done tonight using an updated raspian image. If people want any kind of data dump just tell me what to type at the console and I will provide it.

W. H. Heydt
Posts: 11016
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: USB - the Elephant in our Room

Tue Oct 02, 2012 11:52 pm

rurwin wrote:The Ethernet connection also uses the USB bus.

Second Law of Thermodynamics: You can't win
Third Law of Thermodynamics: You can't break even
Church-Turing Thesis: You can't quit the game
Fourth Law of Thermodynamics: Everything costs more and takes longer....except computers.

gritz
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 12:12 am

W. H. Heydt wrote:
rurwin wrote:The Ethernet connection also uses the USB bus.

Second Law of Thermodynamics: You can't win
Third Law of Thermodynamics: You can't break even
Church-Turing Thesis: You can't quit the game
Fourth Law of Thermodynamics: Everything costs more and takes longer....except computers.
First Law of Economics - cheaper is not always better. Especially if it doesn't work as it should.

Some time ago Nasa announced a strategy informally called "Faster, Better, Cheaper". It didn't take long for them to find out that if they were really lucky they could perm two out of three...

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 6:57 am

It's not that easy to split up the usb driver in a low latency interrupt drivven part and a not so time critical kernel driver. When an interrupt occurs, it normally means that the usb device needs data or has data available. In case of an usb audio device for instance, you will need to provide the audio stream bytes.
The usb driver is multiple thousand of lines of code. It's not a piece of software you rewrite in a spare hour of time.

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: Devices that work and don't

Wed Oct 03, 2012 8:27 am

insanityideas wrote:Plugging new (bought from Maplin for Pi use - not part of their new bundle) Cerulian Mini Wireless Keyboard and Mouse Deskset (2.4Ghz) into Pi works but suffers from occasional (every 30 or so characters) lost or stuck keystroke, and lost mouse clicks.
In my observation, this kind of 'uncorrected packet loss' is caused by mixing full and high speed USB devices on a single hub, so I wonder about your problems with the 2.4GHz set. Do you have other devices on your hub besides this wireless desktop set?
Rocket Scientist.

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 8:50 am

obcd wrote:It's not that easy to split up the usb driver in a low latency interrupt drivven part and a not so time critical kernel driver. When an interrupt occurs, it normally means that the usb device needs data or has data available. In case of an usb audio device for instance, you will need to provide the audio stream bytes.
The usb driver is multiple thousand of lines of code. It's not a piece of software you rewrite in a spare hour of time.
Plus it can be questioned weather this helps the situation. If an overrun occurs due to too many data to receive and to correct (just my guessing) the whole system would have to be made more reponsive, i.e. faster. This goes only thus far. We should accept the fact that there are limits.
Rocket Scientist.

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 9:57 am

There are no proves so far that overclocking the Pi (making it more responsive) improves the situation.
Even keyboards and mice lose packets. Those are low speed usb devices.
Saying that the Pi is pushed to it's limits by that doesn't seem the right way to deal with the situation.
The foundation accepted that there is a problem and says that it's being worked at.
They don't give much detailed technical information about it, claiming that nothing helpfull came from the community. It's a bit the "chicken egg" situation. Without detailed technical information, it's logical that the feedback from the community is low I guess. All we know is that Gordon (and likely a second person) are working on the issue in their spare time.
The issues seem to be caused by usb split transactions being rejected by downstream usb hub's due to the data arriving 2 early or 2 late.
I bet it's much complexer than that and not easily compressed into a oneliner.

insanityideas
Posts: 19
Joined: Tue Oct 02, 2012 9:16 pm

Re: Devices that work and don't

Wed Oct 03, 2012 10:01 am

Thanks fo the suggestion, the receiver dongle is plugged directly into the Pi USB socket, I don't use a hub, so the only hub involved would be the Pi's own root hub, assuming it workssssssss that way. Its the only thing plugged into the pi but obviously notthe onlyyyyyyyyyyyyyyy thing on the bus.

Judging by the comens on here the rem is now well understood so is just the non trivial matter of fixing it.

I wonder if this is one of the soe things where devices are not fully standards complient? or is a lesser used feature of the USB standard just not fullyimplemnted correctlyyyyyyyyyyyy?

BTW Ityped this on my Pi, can you ell??
thradtke wrote: In my observation, this kind of 'uncorrected packet loss' is caused by mixing full and high speed USB devices on a single hub, so I wonder about your problems with the 2.4GHz set. Do you have other devices on your hub besides this wireless desktop set?

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 10:21 am

I think you dropped a piece of raspberry pi on your keyboard and the raspberry jam you forgot to remove is making your y key stick. :D

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: Devices that work and don't

Wed Oct 03, 2012 10:37 am

insanityideas wrote:Thanks fo the suggestion, the receiver dongle is plugged directly into the Pi USB socket, I don't use a hub, so the only hub involved would be the Pi's own root hub, assuming it workssssssss that way.
Have you brigded the polyfuses? Maybe the dongle runs on the edge here. Just guessing, of course.

Directly on the Pi's hub, I never had keyboard problems, no matter what I did. Things start getting bad when using a subsequent hub and mixing protocols on it.
Rocket Scientist.

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 10:42 am

obcd wrote:I think you dropped a piece of raspberry pi on your keyboard and the raspberry jam you forgot to remove is making your y key stick. :D
Frequency of missing keyups and keydowns in his text is quite familiar to me. The jam must be within the scope of delivery of the Pi. Yummy.
Rocket Scientist.

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 10:51 am

obcd wrote:There are no proves so far that overclocking the Pi (making it more responsive) improves the situation.
Ok, you've got a point. But, while it is not a prove, problems are usually get worser under LXDE. This is not only my observation, but I've read it many times here.
obcd wrote:Even keyboards and mice lose packets. Those are low speed usb devices.
Until today, I thought this was tied to mixed protocols, but I likely was wrong.
obcd wrote:Saying that the Pi is pushed to it's limits by that doesn't seem the right way to deal with the situation.
This idea is not exclusive to me. Our gurus improved the code by speeding things up, and the outcome was less interrupts and less lost packets. At the same time, there are problems not tied to responsiveness. That's how it looks to an outsider like me.
obcd wrote:I bet it's much complexer than that and not easily compressed into a oneliner.
I was hoping it was different, but you're surely right.
Rocket Scientist.

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Wed Oct 03, 2012 11:27 am

Yes, problems used to be worse when lxde was running.
They used to think it was due to the fact that the mouse was only used under lxde. Some people started to have problems with it in terminal mode on the latest kernels as well.
Besides that, it's not like lxde is stressing the cpu much once the graphics are drawn.
At the same time, there are problems not tied to responsiveness
There are the supply problems that make things more complicated.
There could be other software or hardware problems, but I assume the software ones should be fixed by now. I can understand that timing issues are a hard to crack nut, but reproducable issues are very common in software design.
It would be great if we would have an idea of where we are standing at the moment.
At home, I can switch mice and keyboards if they don't work properly.
At work, I can't order 5 Pi's, 5 keyboards and 5 mice, and tell afterwards they aren't compatible. Devices that are on the list as being compatible don't work for other people, or only work when used in a very specific combination.
I don't mind to take into account the limits, if only I knew what they are.

Return to “Troubleshooting”