USB - the Elephant in our Room

[RaTTuS]

Yes, I see the situation has improved for many users. Still, I cannot have mouse and keyboard on the hub at the same time, despite having enough juice from the PSU. It even got worser, as before recent updates, keyboard dropouts were only noticable under LXDE. Now I have them at the console, too. My solution is, of course, to have the keyboard on the internal Pi hub and the mouse on the external hub.

Guess I have to be patient and cross my fingers for those volunteers caring about the situation. Thanks to all of you. Hope you find a solution.

what keyboard / mouse / hub
you will need to provide more info than that , as one of your posts says it was fixed.

[ppuskari]

I guess it tells us the real usb stack is still screwed up.. bummer.. Okay I'll go back to the troubleshooting tree and see where that leads. Time to learn the usbmon stuff it would seem.

[thradtke]

you will need to provide more info [...]

If it helps the debugging process, I'll provide any info I have. Otherwise I have a 'mainly' working system with some tricks, and replacing any of the components is not what I intend at the moment (I know it works better with my Belkin hub, which is more expensive than the Pi itself .

I don't think my setup and experiences can be helpful in the process, as there are no standardized tests to run. If you guys need help by giving information, you should probably develop some tests and forms. I'd happily participate.

[JuulTummers]

I have just started using my Pi and am using it as a NAS and video device. But I am having issues.
When I try and transfer files over network to the PI i get some strange results. (Samba as well as FTP)

Transferring to&from maps on the SD card:
Writing to SD: ~7 MByte / sec
Reading from SD: ~6 MByte / sec

Transferring to&from maps on the USB harddrive or stick (doesn't matter which one):
Writing to USB drive: ~0.4 MByte / sec
Reading from USB drive: ~6 MByte / sec

I haven't found an answer in this thread, is this because there is none, or am i missing something here?

PS. Got all the latest updates

[piglet]

wget Big Barn Bunny, writing to a USB stick sends the processor to 100%, and eventually fails every time for me.

No problems writing to SD card.

I've given up using USB sticks on Pi.

[RaTTuS]

are the usb sticks in a powered hub - they may be drawing too much power
I've got decent results from usb hd's - [powered ]

[JuulTummers]

The USB Harddrive is powered and is directly connected to the PI. (not via a USB Hub)

[obcd]

Some usb harddrives only get the 12V from their power adapter. In such a case it could consume more than 100mA on the 5V USB supply. You could measure the voltage drop over the usb polyfuse to find out.

[piglet]

My sitck was on a powered hub.

I've also noticed that when I have a webcam running with mplayer from console, moving the mouse causes massive disturbance to the picure while it's moving. The mouse is in the hub.

This is with the latest (as of yesterday) firmware.

[ppuskari]

@piglet - can you try and turn down the webcam resolution to 320x240 or less? I've had all sorts of issues at 640x480 and the less usb traffic the better when it comes to mouse movement and usb 2.0 webcams at least in my testing. Camorama seems to work the best for me under X at least.

Also the web cams will also increase dramatically your system interrupts since that's how the fiq stuff works. When the usb device is actively doing things the interrupts climb fast. Just the way the pi works.

I've had great success with a powered USB HD on a powered hub. In fact I run my / volume from it and use the sd card just for booting. I haven't played much with usb sticks on it though.

[JuulTummers]

@ppuskari: So you don't have isues writing to your USB harddrive?

[piglet]

Hmm with the command line set to that resolution it didn't seem to make any difference (to the picture or the mouse interference).

I'll try installing cheese and see what that makes of the webcam.

[ppuskari]

@Juul - NOPE... My two Pi's work extremely well. It's a Prolific elcheapo 2.5" ide external usb case with my old latpop 2.5" drive in it. It is powered by my CyberPower 4 port hub. The hub is the ONLY device plugged into the Pi. I'll do some speed tests but I suspect it's in the normal range.

@piglet - I installed cheese and removed it since it was barely usable on my setup. I tried like 5 or six packages and the only one I could get solid and usable so far was Camorama at 320x240 max resolution. It locks up at 640x480 - AVG frame rate is 7.0 at 160x120 and 3-4 at 320x240

Oh, I'm overclocking to 905 mhz now as well and latest kernels as usual. I think I listed my usb tree in this thread or on one of the others. It took a while to get the right combination of devices and power setup but once I did, I rarely have any issues with the usb devices now.

[zagumennikov]

There is so much discussion about usb here. Can anyone make a summary of all of that (for example in the first post of this topic or in wiki)? How are things with the problem for now? What is already fixed, what will be fixed in near future, what will not be fixed, is anyone working on usb problems now? What means cmdline.txt options discussed here, what are default values? What is optimal cmdline.txt configuration for usb performance? It's hard to read whole this thread, collect and combine useful information. Someone who understands the whole situation, please make an exlaining post.
Many thanks.

[dom]

There is so much discussion about usb here. Can anyone make a summary of all of that (for example in the first post of this topic or in wiki)? How are things with the problem for now? What is already fixed, what will be fixed in near future, what will not be fixed, is anyone working on usb problems now? What means cmdline.txt options discussed here, what are default values? What is optimal cmdline.txt configuration for usb performance? It's hard to read whole this thread, collect and combine useful information. Someone who understands the whole situation, please make an exlaining post.
Many thanks.

The optimal command line options are all defaults now (assuming you have ran rpi-update). These will be pushed to "apt-get upgrade" in the next few days.

The USB problems have been significantly improved during the lifetime of this thread to the extent that most users shouldn't have problems.
One of the issues remaining is where packets can be lost from USB 1 devices when there are also USB 2 devices present.
This can be avoided by forcing everything to use USB 1 speeds (dwc_otg.speed=1). Gordon is still investigating this.

There are a number of other bug reports that are being investigated by Gordon. We think some of these problems are due to the "dumb" nature of the USB hardware.
This requires the ARM core to service interrupts in a timely manner. However linux is not a real-time OS, and if interrupt latency is poor, things can be missed.
Normally that is not critical, as USB is designed to handle loss and retransmit, but there are exceptions (isochronous transfers from webcams and audio devices for example).
We've typically found that poor interrupt latency is caused by other badly behaved drivers in the system. For example a fix to the sdcard driver caused a lot of positive reports for USB audio devices.

So, if you are not specifically hitting problems with USB, then just run "apt-get upgrade" from time to time, and you will get the recommended fixes.
If you are suffering a specific problem and like to help with testing, then rpi-udpate may get you a fix earlier, and the various command line options may help diagnose what is good and what is bad.

[clog]

Dom Wrote:
isochronous transfers from webcams and audio devices for example ......

I like to share my experience here. I bought the Pi because I thought and still think the Pi is well suited to act as an high quality audio streamer. For that reason I reinstalled Raspbian today and the latest soft- and firmware (I did an rpi-update). As powersource I use an Ipad power supply. The Pi is running headless with ethernet connection to my NAS and USB connection to my 24 bits 96 khz capable DAC. To play music I use MPD (the music player daemon) via ALSA. I played 24 bit 96 khz flac files.
The first run configured MPD to 16 bits 44,1 khz. Without doubt the music sounds fine with good detail and without noticable distortion even at high volume. Cpu usage is relatively high (45%) because it has to reencode the hires file to 16 bits 44,1 khz.
The second run I congfigured MPD to 24 bits 44,1 khz. The same file sounds distorted. BUT A LOT BETTER than my previous experiment 1.5 months ago.
At the third run I played the flac file at the full 24 bits 96 khz. Well of course this sounds awfull.
So I think progress has been made and that is wonderful. I hope that further progress is possible and that the Pi will be the streamer I think it could be.
To avoid misunderstanding here. English is not my native language. I do not intend to sound pushy or ungrateful.

[piglet]

@piglet - I installed cheese and removed it since it was barely usable on my setup. I tried like 5 or six packages and the only one I could get solid and usable so far was Camorama at 320x240 max resolution. It locks up at 640x480 - AVG frame rate is 7.0 at 160x120 and 3-4 at 320x240.

Yep - it's coming off my pi too. 100%cpu usage made the machine barely functional. I really want to get motion working... but it's not playing ball. mplayer works. motion doesn't like me : http://www.raspberrypi.org/phpBB3/viewt ... 38&t=17308 That's probably my own fault in being too noob to know how to drive the thing.

[jamesh]

Notwithstanding the USB issue, imagine running a webcam on a device from about 10 years ago....which is when desktops had the same CPU power as the Raspi does now. That should give some idea as to what sort of performance you should expect (until the camera module comes along). Since that time a lot of 'bad'* code has been written in the assumption that CPU performance would never decrease...

* Inefficient, which in my world is the same as bad.

[TarjeiB]

Notwithstanding the USB issue, imagine running a webcam on a device from about 10 years ago....which is when desktops had the same CPU power as the Raspi does now. That should give some idea as to what sort of performance you should expect (until the camera module comes along). Since that time a lot of 'bad'* code has been written in the assumption that CPU performance would never decrease...

* Inefficient, which in my world is the same as bad.

Not quite relevant though - I am running 960x720@10FPS in mjpg_streamer with a Quickcam Pro 9000 on a WNDR3000 router running Tomato (linux 2.6.xx), which contains an ARMv5 CPU of much smaller capacity than the Pi.
On the Pi I get a lot of JPEG errors and bad image distortion, but seems to have improved at least some after the later kernels.

[zagumennikov]

If you are suffering a specific problem and like to help with testing, then rpi-udpate may get you a fix earlier, and the various command line options may help diagnose what is good and what is bad.

Thanks for reply, things are much more clear now.
I have problems with web cam, like many other people here. As it was said many times, cheap routers have much better performance with usb web cams than raspberry pi, so I don't think it's because "usb is designed so" or smth like that.
If you can not replicate these problems, I would gladly help you if you tell me how can I do it.

[javatmn]

@Dom,
I also have same USB webcam issues like others, it barely works at resolution 640x480 or above. However I DO SEE THINGS GETTING BETTER AND BETTER. I remember several months ago the kernel panics at 640x480, and system hangs when i use transmission-bt or mldonkey, but now it never crashes, though i got tons of kernel messages like "smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped". But i still have some concerns about USB webcam, is this a HW design issue or only SW driver issue? The same webcam runs well on my Dockstar running kernel 2.6.32, can we build a 2.6.x version of Pi kernel?

[obcd]

A 2.6.x kernel won't work any better.
The problem is the synoptic otg usb hardware implementation.
Occasionally, usb packets get lost.
A number of improvements were made to the kernel and drivers to lower interrupt latency, but none of those fixes the issue completely.
Most usb transfer protocols have a buildin recovery for lost packets. The isochronous transfer used with webcams and usb audio adapters isn't having this. (There simply is no time to retransmit a packet with audio or video data.) Issues with those devices are hard to fix, and it's also nearly impossible to prognose how well such devices will work with the Pi.
As soon as the foundation will bring out it's own Pi cam, that can be used instead of a webcam. it doesn't use usb.
Usb audio devices seem to work if you don't choose the highest possible quality of them.
Besides that, the Pi rev. 2 boards have the I2S signals brought out on a connector, so I am expecting an audio expansion board with a codec for those who need good quality analog audio.
One remaining issue is the sticky key one when low speed and full speed usb devices are used simultanously on an usb hub.
Some say this is caused by crappy power supplies not providing enough voltage.
It used to show up only when the Lxde graphical environment was started.
This might be because the mouse is only polled at that moment.
At the moment, the issues are masked well enough so that most people won't notice them anymore.

[jamesh]

Notwithstanding the USB issue, imagine running a webcam on a device from about 10 years ago....which is when desktops had the same CPU power as the Raspi does now. That should give some idea as to what sort of performance you should expect (until the camera module comes along). Since that time a lot of 'bad'* code has been written in the assumption that CPU performance would never decrease...

* Inefficient, which in my world is the same as bad.

Not quite relevant though - I am running 960x720@10FPS in mjpg_streamer with a Quickcam Pro 9000 on a WNDR3000 router running Tomato (linux 2.6.xx), which contains an ARMv5 CPU of much smaller capacity than the Pi.
On the Pi I get a lot of JPEG errors and bad image distortion, but seems to have improved at least some after the later kernels.

I did say USB issues notwithstanding....

Does the quickcam pro 9000 export mjpg - that dramatically reduces bandwidth before it even get to the Arm. Are you using the same device on the Raspi?

[pluggy]

This can be avoided by forcing everything to use USB 1 speeds (dwc_otg.speed=1). Gordon is still investigating this.

There are a number of other bug reports that are being investigated by Gordon. We think some of these problems are due to the "dumb" nature of the USB hardware.

The first bit appears to have 'cured' a problem with a Wifi adapter I was having, it completely kills the Webcam that was working on the other port though it didn't take kindly to most of its bandwidth vaporising. Using a Wifi adapter at USB 1 speeds isn't too much of an hardship, much better than it throwing in the towel every few hours.

The second bit sums up a lot of misery.........

[pluggy]

Nope spoke too soon, running it as a USB 1 made it run for a lot longer (21 rather than 3 hours). But its still expired.....