On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote: > On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
> Odd ... "interwoven" certainly allows gaps, and all of your > additional details agree completely with the facts as I had > pointed out. I think we both actually agree on all but the semantics at this point, so there's no real reason to continue this particular argument... > In particular, that transfer errors will start > long before usbcore has any clue that the root cause is that > the device has been disconnected. You need to be re-thinking > a bunch of things if you believe otherwise. I see that's exactly what's happening. It merely seems.... unfortunate. > Even so, incremental patches are a requirement. The problem is that the patch isn't a modification; it's a redesign. It removes the old frame/uframe budgeting code entirely and implements a new self-contained abstraction to perform the budgeting task. The ehci code that does the physical schedule manipulation is essentially unchanged. Regardless, I intend to follow policy to the best of my ability here, so I'll be looking for fissures I can use to split it apart. Some auxiliary pieces can indeed be split out. > There are several > independent chunks of the scheduler ... in fact, several distinct > schedulers (for TT, QH, and ISO), and lots of non-scheduler code > that's just to maintain data structures. The independent chunks are largely unified now. Let me clarify some terminology I'm using so this doesn't get confusing (I've been screwing this part up till now, so I'm going to be more careful): 'Scheduling' is the act of manipulating the hardware and shadow schedules, that is, interaction with the HC's physical periodic schedule [and the shadow schedule]. In fact, this code is largely unaffected. The changes I've made here are incremental and can be split out (primarily adding machinery to manipulate sITD backpointers and FSTNs). 'Budgeting' is the precalculation of where transactions are to be scheduled, determining in entirety where the scheduler will put all future transactions before the scheduler does anything. This is a new, self-contained layer that implements new data structures. It is truly periodic (no sliding windows; budgeting is done for the lifetime of an endpoint's activity). It does not interact with the scheduler; the scheduler inspects the results of the budgeting layer to determine where to schedule things. This is the piece of code that isn't splittable into pieces as it simply didn't exist before. > From what you've said so far, there is no evidence of anything > that's "logically flawed". I disagreee, and we've already discussed that. I'll name a few, and they all go directly to the way the current budgeting is designed, not the way it's implemented. 1) Budgeting is [potentially] done from-scratch with every new URB submitted. It is possible, for example, for an isoch stream to suddenly throw ENOSPC two hours into a professional recording session because the budget wasn't fully determined beforehand, and it just got 'unlucky'. 2) Continuous rebudgeting is computationally expensive; you were worried about CPU usage, here's likely the biggest sink in the usb code. 3) When a previous URB's budget is reused in the same stream (the opposite of the continually budgeted case; I see streams randomly fall into one camp or the other), the reused budget is not checked for correctness; it merely assumes no new endpoints have become active and blindly installs it into the schedule. Accordingly, new URBs cannot budget against a complete periodic schedule, only what is in the fraction of it used right now by the current sliding windows. For this reason, overallocation errors are rampant. 4) despite 480Mbps, so much bandwidth is wasted, i can't push 9Mbps to a FS audio device behind a hub. Dan's patch does improve things significantly, but not enough for my devices to work. This is a problem that goes to the heart of the budgeting algorithm, and this is mostly seperable from the scheduling mechanics (until you realize that FSTNs and sITD backpointers are an integral part of wasting less than half of every FS frame). > Such evidence can, in my experience, > be boiled down to a number of individual flaws ... and if it can't, > that's highly suggestive of the wrong problem being addressed. Budgeting against a sliding window is more than half of the problem and it is fundamental to the way the current code works. It's not so much that ehci-sched needs to be chucked out a window; it's that the periodic budgeting code barely existed. The code removed was about 100-200 lines; the rest is mostly untouched. It's just that it needed an extra thousand lines to handle doing real EHCI budgeting within the constraints you put forth early in our discussion. Eg, it would have been alot more concise to do real budeting within the hardware schedule itself, but you'd objected to that on the grounds of memory consumption, so I implemented a shadow budget layer.... etc.... Anyway, I really do think you'll like the design fine, I just need to figure out how to split it up. Monty Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
