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

Testing pi usb packet loss

Former Member

If we can believe the official pi forums, the only remaining usb issues on the latest kernel should be packet loss when low speed and high (full?)speed devices are connected intermixed on a downstream hub.

I dare no longer asking there for confirmation as I already got a warning for what they describe as "concern trolling".

 

I am just wondering if using an usb webcam would be a good method to figure out if what they claim is true.

 

I assume, once initialised, a webcam will setup a transfer endpoint to upload it's video data to the host.

I read reports op people saying they have lines and strange artefacts in their webcam picture. This looks like lost packet issues to me.

I know streaming usb devices don't use error checking, but I assume the data flew should be fine without it if I don't start to use long cables or other

not certified setups.

If a setup with just a webcam and wifi device don't work reliable, wouldn't that mean that any usb setup is basically a hit or miss situation, depending upon how well the usb devices deal with packet loss?

 

I can live with the idea of not connecting low speed usb devices for the moment, but I am concerned about the reliability of other usb setups.

 

I had bad experiences in the past with Via's 686 uhci implementation, that I never managed to resolve. So forgive me if this is concern trolling and please let me know.  

  • Here's my understanding of USB isochronous transfers used by real-time audio and video devices.  For isochronous transfers to work propery, the error rate is assumed to be very low.  It must be, because in a real-time situation there's no time to re-transmit if the original transfer fails.  If a transfer fails, software is supposed to do something sensible like re-use the previous video frame so you don't see a flash or blank region: you might see (or hear) a minor artifact that goes away next frame.

     

    For isochronous transfers to work, host software must make sure there is enough USB bandwidth available for all active devices, and refuse to add devices if there is not enough bandwidth.  Also, the host software must be responsive enough so that it doesn't miss any transfers.

     

    It sounds like the RasPi USB software is improving, but isochronous transfers tend to be one of the last things that works properly.

  • in reply to johnbeetem

    @Luc: I agree with John's answer.

     

    @John: Yep, it's very likely to be the same in Luc's video streaming application as it is in isochronous audio streaming which I've done with MIDI gear.  Modern MIDI synths typically feature a serial MIDI comms channel over USB, plus an additional incoming and/or outgoing isochronous MIDI audio channel.  The USB system commonly denies the isochronous audio device from obtaining a connection if it cannot assign sufficient USB bandwidth for such a channel --- the message issued about there being not enough USB bandwidth is quite explicit (on Linux).

     

    If webcam software has the option to work in dumb mode and not try to fill in for missed data, then that might indeed provide a way to monitor USB losses, particularly if it also logs lost data or provides statistics about it.

     

    However, I think it's in order to mention my earlier cautions --- such tests may not provide full test coverage because of the variety of USB transfer types, which may have different loss characteristics.  Still very useful of course, but any conclusions should note that test coverage is partial.

     

    Morgaine.

  • in reply to morgaine

    Thanks for the feedback.

    I was trying to find a method to check if the usb issues still exists after the latest kernel patches.

    They try to make us believe that the only issues still there are those with the mouse and keyboard missing packets. If this would be correct, we would at least know where we stand when we avoid that setup.

    To my personal feeling, they only reduced the error rate, and if the packet loss is happening sporadically on usb isochronous and bulk transfers as well, than it's time to evaluate some other solutions.