On Tue, 20 Jan 2004, David Brownell wrote: > Date: Tue, 20 Jan 2004 18:09:43 -0800 > From: David Brownell <[EMAIL PROTECTED]> > To: John Heil <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > linux-usb-devel <[EMAIL PROTECTED]> > Subject: Re: [linux-usb-devel] Re: Test of ehci iso patch > > John Heil wrote: > > On Tue, 20 Jan 2004, David Brownell wrote: > > > >>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... > > Contributions are always welcome here! Especially from folk who > are using the high bandwidth modes; so far off-the-shelf devices > don't try to do such stuff. So the testing is harder than usual. > > > > 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. > > Could you elaborate a bit more about your queue setup, notably > how big each urb's buffer was and how many you had queued?
Each urb at present has 2048 bytes so the mult bit is on and it comes in 1K chunks. The production version will be about 2800+ so 3 chunks. Each of my urbs is max density @ 8 transactions per and each urb can be looked upon as a read/write pair and I make sure that each periodic frame list slot points to an enchained read/write pair of iTDs so that each uframe has 2/3K in and out, always. (This is for video and my requirement is to _never_ drop a frame. The input hardware, once started is relentless ~3K in per uframe.) My current attempt is (haven't completed/tested it yet tho...) ...2 q's added to ehci_hcd. scan_periodic deposits fully completed itd pairs to one queue and when a tasklet awaken, it xfers that queue's contents to a work-in-progress queue where it drives std completion processing. > > And also, how much work you were doing in your urb completion > callbacks ... rather than in a tasklet? I set it up to vary the urb submission count. After the initial kickoff, the 1st callback of a pair, is for the read urb and is essentially a nop which returned directly. The write urb mate to it, looks to see how close it is to the ehci and IFF there is space, it outputs from 1 to 8 more urbs pairs. > > I certainly noticed that doing much printk() in completion > routines -- which ran about every (11/8) milliseconds in many > of the tests I did, sometimes more often -- could make big > trouble in the high bandwidth modes. Zero printks... all debugs were off and CATC set to max at 128KB. The pause happened about 4/5 of the way into the catc buffer on a 32K test run. > > > > 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'd recommend you do that in your device driver, instead. > Your completion callback can use urb->urb_list (so long as > the URB hasn't been submitted!) and schedule the tasklet. I did the tasklets driver thing first and in that mode I had perfect throughput w no dropped frames, till I hit this 'callback backlog', I added messages to prove what it was. > > I don't think the schedule scanning should actually be very > costly ... though there is an optimization that could stand > to be applied. (See the FIXME at the end of ehci-sched.c > about inching up.) It's possible that the URB completion > code paths could be made shorter, or cache-friendlier. > > I've been meaning to oprofile this, but haven't yet done so. > Me too! never enough time :) > Also I'm not sure how a tasklet _alone_ could change things. > The data is streaming at the same rate regardless of what > the CPU is doing, and the CPU would take the same amount of > time (ignoring cache effects) regardless. > Yes, but the EHCI is essentially a uprocessor of its own so its kinda like an asymetric mp setup. I load the periodic list, up front, sort of 'step back' and let fly... > > > 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? > > In fact, that's how the EHCI driver worked in its first incarnation! > The hardware is friendly to that approach; it could run entirely > without IRQs, using just timer-based polling. I did not eliminate interrupts, 'merely reduced their number... log2_irq_thresh = 6; > > However, Dave Miller wanted to get rid of that to make some of > the keyboard/HID integration work sanely on SPARC. And that made > for some simplifications; I agreed, and here we are. (See the BK > history from early December 2002.) > > I'd rather avoid going back to that strategy if we don't need to. > As for "need", I like to consider myself open to evidence ... > > - Dave > Well this first cut is for a reference design and a lot of tuning and changes will be coming too. My first task is to support the video rate and then I need to piggy back in isoc audio about every 8th transaction. It seems tho that the shorter our interrupt path the better especially given that we have preemption capability and deadline sched'ng. johnh - ----------------------------------------------------------------- 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
