On Wed, 21 Jan 2004, David Brownell wrote: > Date: Wed, 21 Jan 2004 11:49:21 -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: > > >>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. > > Sounds to me like you should be finding out what's keeping > that tasklet from running before its deadline fires, and > resolve that. Or maybe just fixing your IRQ threshold would > resolve this. >
Perhaps I misunderstood you... My tasklet runs as the scheduler sees fit. I haven't noticed any problem w its running per se. My tasklets only do urb submission, individually or in groups. My callback routine is common to both read and write completions and merely picks a starting point w/in my urb pool so that the tasket has a start point to begin looking for free urbs it can submit. The delay I found was that the periodic frame list was completely full and no more slots were available. The callback code was not freeing urbs fast enough. Anyway, I completed the callback-by-tasklet mod today and it solved the CATC detected wait state! :) I suppose I should clarify the mod a little bit more. Early on, I split itd_complete into 2 parts: itd_complete and itd_release... itd_complete merely handles the per-transaction housekeeping. itd_release drives the callback and releases the iTD(s) These were driven from scan_periodic for fully completed frame slots only. This gave me the initial throughput w the wait at about urb 6500 or so. So my new change merely enqueued the iTDs of the fully completed slots and on exit, tasklet_schedules new rtn completion_tasklet which in turn, drives itd_complete and itd_release to exhaustion of the WIP queue. Anyway, so far the results were great and the CATC is no longer able to detect any missed data packets to we are modifying the FX2 code to check for drops instead. Meanwhile, its on to 2 FX2 on in and the other out, each at 3K. > > >>I've been meaning to oprofile this, but haven't yet done so. > > > > Me too! never enough time :) > > Speeding up the IRQ handler path will of course be a fine > thing, but from what you said so far it doesn't seem likely > that'd be your bottleneck. > > > > I did not eliminate interrupts, 'merely reduced their number... > > log2_irq_thresh = 6; > > So one IRQ every 64 msec? That's likely causing lots of > trouble all by itself. > > This means that your queue depth should be something on the > order of (64 msec + max IRQ latency + tasklet sched time). > > My testing kept much shorter queue depths (10 msec), and > never hiccupped. > > - Dave > w.r.t log2_irq_thresh = 6: see prior email... I looked over the involved code... I force EHCI_ITD_IOC in transaction 8 of each iTD. Presumably that somewhat overrides log2_irq_thresh (?) I haven't looked at that yet. 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
