On Tue, 20 Jan 2004, David Brownell wrote: > Date: Tue, 20 Jan 2004 19:38:13 -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 > > Hi John, > > More later, but one quick comment: > > > 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. > > Interesting ... so eight urbs per uframe, one IRQ each 125 usec. > > What happens when you make each URB larger, like maybe taking up > a full frame with each one (16 KB)? Or if you set URB_NO_INTERRUPT > on some significant fraction (7/8 or better) of those urbs? >
Oops. Sorry Dave! I meant: 2048 bytes per transaction and 8 transaction per URB/iTD and each read iTD is laterally chained to a write iTD and the pair is anchored by a single periodic frame list slot so that the controller re-reads the pair 8 times per slot. There is a 1 to 1 mapping of urbs to iTDs. Each iTD uses all 8 of its transactions so each uframe gets 2048 bytes inbound and 2048 outbound for 4096 bytes on the bus per uframe, overall 4096 bytes * 8 uframes = 32K bytes on the bus, in my testing mode. The actual hardware will increaes that to about 2800 bytes in + 2800 bytes out per uframe (Right now I'm on Cypress FX2 boards). I do set the transactions URB_NO_INTERRUPT for 7 of the 8 transactions per iTD. I will try setting it to 15 of the 16 (8 read + 8 write), thus placing the interrupt on the last of the write transactions (which always must follow the read). > > > It seems tho that the shorter our interrupt path the better especially > > given that we have preemption capability and deadline sched'ng. > > Getting 1/8 as many interrupts is for many purposes the same > win as an interrupt path 1/8 as long ... :) > > - Dave > True, but really tight top half code is still beneficial... for everyone :) Also, I won't have the luxury of staying on fast Intel silicon in the final and prod versions and at that point, every cycle may count. johnh > > ------------------------------------------------------- > 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
