> > 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.
That sort of behavior is inevitable in hardware-parallel systems.
But it's also a rather minor failure mode, and the only folk who
seem to run into it are people tweaking host controller drivers
and adding lots of temporary fault mode diagnostics.
> 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).
I tend to use that term more broadly. Not just manipulating the
data structures ("data structure updates") but also budgeting
and choosing between potential budgets.
That is, "schedule updates" are just data structure changes.
While "scheduling" is the whole task of managing bandwidth that's
available, and then budgeting/allocating it so that two different
endpoints won't both think they reserved the same bandwidth.
And as a simplification: to date there's been only one data
structure, which encodes both the schedule and all allocations.
This is a Good Thing (tm) because it's less error prone ... and
it's also a useful simplification.
> '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;
Only ISO endpoints ever had a sliding window... and I'm not sure what
you mean about this being a new layer, considering that the scheduling
decisions are already separated from the actual data structure updates.
> budgeting is done for the lifetime of an endpoint's activity).
I'm not clear what you mean here either. An endpoint is active if
it has URBs queued. By that definition, this is again a description
of the current driver behavior. (Modulo the glitches noted for ISO.)
> 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.
Odd; I sure thought there were such pieces. Maybe not factored the
way you'd prefer, but those natural divisions do exist.
> > 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.
I'll summarize these as just that ISO budgeting has issues, since it
doesn't use the exact schedule tree that interrupt budgeting uses.
Now, I'll call "no schedule tree" an implementation issue, but suspect
you will disagree.
> 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'.
I'd say that differently: ISO scheduling needs more work. Because
of that sliding window thing, mostly.
> 2) Continuous rebudgeting is computationally expensive; you were
> worried about CPU usage, here's likely the biggest sink in the usb
> code.
But the current code does NOT continuously rebudget. Each endpoint
records its last scheduling slot(s). The most typical case is that
the queue doesn't empty; in which case there's no rescheduling done.
The next most typical case is that the queue empties, but no other
endpoint needs to re-use those schedule slots. In which case those
slots are still available, and they're reused after just a sanity
check.
> 3) When a previous URB's budget
Conceptual bug alert: URBs do not have budgets. Endpoints do.
> 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.
Again, you must be focussing on ISO here, because the problem can't
appear for interrupt endpoints. Interrupt transfers sit cleanly in
a schedule tree, so those slots can't be invalidated.
In any case, the action is correct even for ISO transfers, given the
assumption that the original schedule didn't overcommit. (And by the
way: your #2 complains about continuous rebudgeting, but your #3 here
complains about lack of same. One claim or the other is clearly wrong...)
That is, better ISO budgeting -- e.g. by sticking an dummy "ISO QH"
in the schedule tree instead of using the window thing -- would fully
resolve this issue.
> 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.
Depends what you're doing. But again, that's specific to ISO reservations;
interrupt transfers don't do the windowing thing.
> 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).
Sure; those more advanced features haven't had many requestors yet.
But keep in mind that not supporting such features is very different
from being "logically flawed".
> > 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.
Current ** ISO ** scheduling only. Interrupt scheduling doesn't
involve any sliding window ... it's a straight schedule tree, as I'd
have preferred for ISO.
> It's not so much that ehci-sched needs to be chucked out a window;
> it's that the periodic budgeting
"isochronous budgeting" ... was simplistic, and aimed at typical
light duty loads.
> 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....
It's possible to have better isochronous scheduling without having an
ITD in every schedule slot, which is what you had initially suggested
(and agreed would make trouble, given a potential need for 1024*8 ITDs).
> Anyway, I really do think you'll like the design fine, I just need to
> figure out how to split it up.
Yes, let's see it first. :)
- Dave
> 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
