Will Miles wrote:
>  Hi Thomas,
>
>  I think the OP has a point.  The out-of-the-box default priorities
>  for these drivers no longer make sense since the priority cap has
>  been raised to 255.  This is especially true since, as you mention,
>  by default even non-root users can starve out interrupt handling!
>  Using a standard interrupt/device priority of 21 made sense when
>  non-root users were capped at 20, but with the extended range the
>  default out-of-the-box values should at least be raised above what
>  non-root users can reach.
>
>  The answer "you can always adjust the priorities yourself" isn't
>  particularly satisfying, either.  There are two problems with it:
>
>  One, we have no idea what sort of testing you've done with an altered
>  device priority scheme.  We can safely assume that you've done
>  regression testing with the default values - but have you tested how
>  io-usb behaves if io-net or devb-eide is raised to a higher priority
>  and it suffers from higher interrupt latency as a result?  Or any
>  other combination of the above?  At what point does the behavior of
>  the code break down?  As a developer, I don't even have any way of
>  assessing the possible risks of such a change (though fortunately
>  this aspect is slowly being rectified as more driver source becomes
>  available - kudos again to the Foundry27 project as a whole :).

Do you beleive that QNX tests every combination of server with every
other server?  As soon as you get multiple clients and servers running,
pretty much every environment becomes a custom "analysis" that has
to be done for your specific product and environment.  Also I suspect
(though I can't prove it at this point in time =;-) that you'd find most of
the labs run with different command line options and parameters based
on the goal's of the labs and tests.

Adjusting the priorities on specific services 'up' won't (or shouldn't) 
provide any additional comfort to you if it is just done en-masse (ie
121 becomes the new 21 =;-)

>  Two, the overwhelming majority of QNX-supplied device drivers either
>  (a) only offer a custom, non-standard way of adjusting their primary
>  device handling priority; or (b) don't offer any such mechanism at
>  all (io-hid, for example).  Under the hood, they all do the same
>  thing: they use a pulse on their device-event handling thread, and
>  thus they completely ignore the on -p or slay -P commands in terms of
>  changing what priority they handle device events at (since the
>  priority will be based on the value stored in the pulse, which does
>  not seem to pay any attention to the startup thread priority).
>  Tracking down the myriad of custom options for every driver launched
>  by the system is a daunting task at best, and error prone at worst -
>  especially when you end up hacking the binaries because there isn't
>  any such option presented and the priority value is simply hardcoded.

There was a significant effort to address this some time ago, and those
changes should be rolled out with the 6.4.x binaries I imagine.  For those
who are trapped in a 6.3.x world, then on and slay are your best bets =;-)

Thanks,
 Thomas ... not against up'ing the priorities, but also not seeing it as 
a silver
                  bullet to the problem originally expressed.