> > 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.
OK, then I am mollified and will stop worrying about it.
> > '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.
Yes, no worries. The steps are fully seperated in my code, so I had to
coin some way of unambiguously identifying which I was talking about.
There is a decision layer that works entirely with true periodicity
(budgeting) and the mostly unchanged mechanical layer that manipulates
the physical schedule (scheduling). Overall it is still 'the
scheduler'.
> 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.
? There are QHs, iso streams, sits, itds and fstns in the hardware
schedule, and a rolled up pointer union [shadow schedule] that points
to the same physical thing that may be one of many types... that may
be one data structure, but it's certainly not one type and traversing
it is not simple.
Ive implemented a parallel 'shadow budget' in response to your concern
that true periodic scheduling in the 1024 frame hardware schedule
would use too much kernel memory (I don't mean to sound contrary
there, I agree with you else I'd not have done it this way). The
shadow budget is #defineable, currently 32 frames, and consists of
only budgeting information (which is now moved out of the private
sections of the hardware schedule structures).
> 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.
New data layer, not a new logic layer. Because the decision data is a
fundamentally different thing than the schedule entries themselves, I
implemented a seperated layer to handle and store it. It is also less
expensive to inspect than the full schedule and there's no need for
continuous type-punning using unions. Decision data for a given
endpoint is 'owned' by either a specific QH or a specific ISO stream.
ISO streams are no longer freed and rebuilt between each transfer
(that they were before was accidental?), but that's a straight-up
bugfix the new layer needs, not a feature of the new layer.
> > 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.)
That's a huge problem for the iso streams I've seen where a new
transfer is not initiated until the old one is finished-- the iso
stream is fully destroyed and then rebuilt for every transfer.
[the problem and fix here are both simple; now, [s]itd_complete frees
the ehci_iso_stream when the last urb is complete, but there's usually
only ever one at a time in audio streams, especially capture streams.
The iso stream should be freed as a result of last urb completion
followed by ehci_endpoint_disable, not just as a result of last urb
completion.]
> Odd; I sure thought there were such pieces. Maybe not factored the
> way you'd prefer, but those natural divisions do exist.
There are incomplete natural divisions, yes.
The logical difference between the two tasks (budget/schedule) is
large, and even seperated in time. Schedule manipulation is happening
constantly. Budgeting happens once up front. It was easier to debug
the new budgeter when the new budgeter was fully seperated from the
scheduling machinery.
> 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.
Budgeting an efficient FS frame would be more difficult if ISO streams
were also treed. the treed QHs already complicate things
substantially. Anyway, I don't need to win this argument if we can
eventually agree that the new scheduler makes good and correct use of
available bandwidth.
Rather, this argument should probably happen later, incrementally ;-)
> 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.
In the use cases I'm watching, the queue often empties between every
submission (especially in capture). perhaps this is usbaudio being
stupid, but there you have it.
> 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.
The audio devices I'm using use multiple ISO and QH endpoints at the
same time. The current code can get into a train wreck in this case
(although I'll admit that only happens now and then, 'mostly reliable'
is not what our users are looking for).
> 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.
Fine, point granted.
> 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...)
they're not mutually exclusive. I have started up my recording
software and seen the streams reuse use the same budget for each and
every urb submission. I have also started the software and seen each
and every urb budgeted from scratch. Both cases may not be happening
at the same time for a given endpoint, but both cases happen.
> 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.
I suggested that and one point and you complained it would take too
much memory ;-)
> "isochronous budgeting" ... was simplistic, and aimed at typical
> light duty loads.
I've never seen a isoch endpoint that counts as 'light duty', but I
understand what you mean.
> 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).
Yes, that is indeed what I originally suggested, and you convinced me
to go a different route, which I have successfully.
> > 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. :)
yes, splitting it into pieces by hand the hard way now....
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
