On Tue, 20 Jan 2004, David Brownell wrote: > Date: Tue, 20 Jan 2004 15:10:15 -0800 > From: David Brownell <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: linux-usb-devel <[EMAIL PROTECTED]> > Subject: [linux-usb-devel] Re: Test of ehci iso patch > > Michal Sojka wrote: > > > > We transfer a stream of four 16 bit channels over USB. In one channel > > there is a sample number that increases every sample period. We use this > > "counter" to detect errors in a stream. With my ehci patch I can > > transfer aproximately 3 MB of data without any error. It's quite small > > number, but this is due to a bug in our USB device (buffer overrun). > > When I use your ehci iso patch, an error apears every 10 kB on average. > > It seems to me that this "error rate" depends (not lineary) on number of > > packets per urb. > > You should explain more about your tests. Sounds like IN transfers > with two 1KB packets per uframe. How big are your URBs ... how many > uframes each? And how deep is your URB queue? Are these "errors" > paired with urb->iso_frame_desc[i].status faults, or do you just see > strange looking data landing in the buffers? Do you maybe have any > CATC confirmation what's going on? > > It might help if you were to post copies of the EHCI debug files, made > while your tests are running. They're found in /sys/class/usb_host > for the bus (probably "usb1"), and they most interesting ones here > will be called "periodic" and "registers". And of course, if there > were any debug messages from EHCI that'd be good too. > > > > The ehci is made by Intel and the stream is high-bandwith (16 MB/s). You > > wrote that you had done lots of testing of your patch, so I'm wondering > > why there are so big differences. Do you have any explination of this. > > Not without some details to go with your report! > > I tested IN and OUT transfers at a variety of periods and transfer sizes. > The 16 MB/s rate was covered, as was 24 MB/s and various rates that could > also be handled by full speed transfers. Right now I see a test script > that uses 32 KB/URB and a queue depth of 8 URBs, which will run 10,000 > times (32*8*10000 KB, streamed). Gave no errors in iso_frame_desc[], > no scheduling glitches (uframes skipped) ... nothing like that. > > At one point I noticed schedule glitching if the URB queue got short enough > to empty; for now, that'll force a big (10 msec!) gap in the stream. If > that's an issue, the fix is using deeper queues in your host side driver.
Forgive my jumping in here... I found that 'deeper' is actually limited in its effectiveness. I found (w a CATC) @ 2Kb in and 2Kb out per uframe and preloading the frame list by starting w a large enough start_interval, I also got a 'big' gap in the stream. This gap was because the callback layer couldn't clear them fast enough. It occurred to me that too much is probably being done in_interrupt() so I thought I'd try making scan_periodic merely offload the list to a queue and at end of scan, schedule a tasklet to drive complete/callback logic. Thus callback runs at the taskelet level rather than in_interupt(). I'm not quite finished w it yet, but reducing the in_interrupt() ~path and adding kernel robustness by removing driver callback code from the interrupt path seemed like intrinsically good things to do anyway. Your thoughts/comments? johnh > > - Dave > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > - ----------------------------------------------------------------- John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] http://www.sc-software.com ----------------------------------------------------------------- ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
