Task priority for UI task handling menus and other controls

Dear experts,
       I am interested in learning from the rtos  software application
architectures you have come across,what would be the priority assigned
to an UI based system?
I am currently working for an consumer electronics product where A/V
tasks and processing tasks take higher priority over UI task.What
puzzles me would be that,in consumer electronics always the UI should
be able to respond fast the moment the user needs it.While processing
of A/V is time consuming should it not be the case where UI should be
given higher priority?

What is the level of priority for UI for applications involving flight
control systems,automotives and industrial automation involving lots
of controls?

I have never come across a situation to design these apps and we are
maintaining apps written by our earlier colleagues.

I also had a chance to skim through the RTOS Application design book
called CODARTS by Hassan Gamma ,(fully not completed in initial
stage).
From my understanding the author seems to favour  CPU intensive tasks
to have higher priority then Input and Output processing tasks.From
this understanding,I can see why A/V has higher priority then UI.Is my
understanding correct?Can experts help me to learn some design aspects
I should look into when designing UI based applications?

Looking farward for all your thoughts and advanced thanks for the
same,

Regards,
s.subbarayan

On Mon, 28 Apr 2008 21:37:20 -0700, ssubbarayan wrote:

> Dear experts,
>        I am interested in learning from the rtos  software application
> architectures you have come across,what would be the priority assigned
> to an UI based system?
> I am currently working for an consumer electronics product where A/V
> tasks and processing tasks take higher priority over UI task.What
> puzzles me would be that,in consumer electronics always the UI should be
> able to respond fast the moment the user needs it.While processing of
> A/V is time consuming should it not be the case where UI should be given
> higher priority?
> 
> What is the level of priority for UI for applications involving flight
> control systems,automotives and industrial automation involving lots of
> controls?
> 
> I have never come across a situation to design these apps and we are
> maintaining apps written by our earlier colleagues.
> 
> I also had a chance to skim through the RTOS Application design book
> called CODARTS by Hassan Gamma ,(fully not completed in initial stage).
> From my understanding the author seems to favour  CPU intensive tasks to
> have higher priority then Input and Output processing tasks.From this
> understanding,I can see why A/V has higher priority then UI.Is my
> understanding correct?Can experts help me to learn some design aspects I
> should look into when designing UI based applications?
> 
> Looking farward for all your thoughts and advanced thanks for the same,
> 
> Regards,
> s.subbarayan

Think about it.

You'd notice video that had even the occasional two-frame (66ms) 
dropout.  An extra 66ms to respond to a button press probably wouldn't be 
noticed at all, and it's certainly no disaster if the UI freezes for a 
quarter of a second.

So which needs to be served by the higher priority task?

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

On Apr 29, 9:51=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> On Mon, 28 Apr 2008 21:37:20 -0700, ssubbarayan wrote:
> > Dear experts,
> > =A0 =A0 =A0 =A0I am interested in learning from the rtos =A0software app=
lication
> > architectures you have come across,what would be the priority assigned
> > to an UI based system?
> > I am currently working for an consumer electronics product where A/V
> > tasks and processing tasks take higher priority over UI task.What
> > puzzles me would be that,in consumer electronics always the UI should be=

> > able to respond fast the moment the user needs it.While processing of
> > A/V is time consuming should it not be the case where UI should be given=

> > higher priority?
>
> > What is the level of priority for UI for applications involving flight
> > control systems,automotives and industrial automation involving lots of
> > controls?
>
> > I have never come across a situation to design these apps and we are
> > maintaining apps written by our earlier colleagues.
>
> > I also had a chance to skim through the RTOS Application design book
> > called CODARTS by Hassan Gamma ,(fully not completed in initial stage).
> > From my understanding the author seems to favour =A0CPU intensive tasks =
to
> > have higher priority then Input and Output processing tasks.From this
> > understanding,I can see why A/V has higher priority then UI.Is my
> > understanding correct?Can experts help me to learn some design aspects I=

> > should look into when designing UI based applications?
>
> > Looking farward for all your thoughts and advanced thanks for the same,
>
> > Regards,
> > s.subbarayan
>
> Think about it.
>
> You'd notice video that had even the occasional two-frame (66ms)
> dropout. =A0An extra 66ms to respond to a button press probably wouldn't b=
e
> noticed at all, and it's certainly no disaster if the UI freezes for a
> quarter of a second.
>
> So which needs to be served by the higher priority task?
>
> --
> Tim Wescott
> Control systems and communications consultinghttp://www.wescottdesign.com
>
> Need to learn how to apply control theory in your embedded system?
> "Applied Control Theory for Embedded Systems" by Tim Wescott
> Elsevier/Newnes,http://www.wescottdesign.com/actfes/actfes.html- Hide quot=
ed text -
>
> - Show quoted text -

Hi,
I realise that in this situation.What about situations like flight
control systems,industrial automation ?

Regards,
s.subbarayan

In article <05bfec06-ee33-4380-849f-8b1d55dfed01@y22g2000prd.googlegroups.com>,
ssubbarayan  <ssubba@gmail.com> wrote:
>On Apr 29, 9:51&#4294967295;am, Tim Wescott <t...@seemywebsite.com> wrote:
>> On Mon, 28 Apr 2008 21:37:20 -0700, ssubbarayan wrote:
>> > What is the level of priority for UI for applications involving flight
>> > control systems,automotives and industrial automation involving lots of
>> > controls?
>>
>> You'd notice video that had even the occasional two-frame (66ms)
>> dropout. &#4294967295;An extra 66ms to respond to a button press probably wouldn't be
>> noticed at all, and it's certainly no disaster if the UI freezes for a
>> quarter of a second.
>>
>> So which needs to be served by the higher priority task?
>
>I realise that in this situation.What about situations like flight
>control systems,industrial automation ?

The UI is still lower priority than flight dynamics, making certain the
bucket of molten steel stops reasonably close to the right place, etc.

In a hard realtime environment where life safety is an issue, you do
complete scheduling analysis that proves (in the mathematical sense)
that no deadline that affects safety can be missed.  The user interface
is assigned deadlines for responsiveness during that process, but it's
still the case that a 200 mS delay in UI handling won't be a problem,
given that human reflexes are in the same time scale.

Humans basically[0] aren't real-time when it comes to control inputs.
Video that one expects to be smooth needs to be updated at a given
frame rate, but in an industrial or aviation system, it's simply
not as important to show the user what's going on within microseconds
as it is to adjust the flight control surfaces.

In systems that I'm familiar with, UI output is about the lowest
priority task.  Input is near as low, but might get bumped a little
depending on system properties.

[0] OK, a continuous 200 ms lag of response in my joystick would make
landing on a carrier somewhat harder.  On the other hand, if it was
always there, it could be trained around and compensated for.
-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM                      Whois: SW32-ARIN
   Free time?  There's no such thing.  It just comes in varying prices...

Steve Watt wrote:


> [0] OK, a continuous 200 ms lag of response in my joystick would make
> landing on a carrier somewhat harder.  On the other hand, if it was
> always there, it could be trained around and compensated for.

The occasional delay in the reaction of the user interface is VERY 
ANNOYING. Remember how do you feel when the mouse cursor sticks in 
Windows. If a LED is switched on later then 50ms after a button is 
pressed, the customers will call your system "dull", "sluggush" and 
"heavy", no matter how well it performs the main functionality.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:

> The occasional delay in the reaction of the user interface is VERY
> ANNOYING. Remember how do you feel when the mouse cursor sticks in
> Windows. If a LED is switched on later then 50ms after a button is
> pressed, the customers will call your system "dull", "sluggush" and
> "heavy", no matter how well it performs the main functionality.

I encountered a team who thought they had done well to reduce the
response time from 50 seconds to 15 (seconds). In a wire-guided
torpedo control system .. OK, things happen slowly underwater and
submariners learn patience, but ..

Simon Wright wrote:
> Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:
> 
>>The occasional delay in the reaction of the user interface is VERY
>>ANNOYING. Remember how do you feel when the mouse cursor sticks in
>>Windows. If a LED is switched on later then 50ms after a button is
>>pressed, the customers will call your system "dull", "sluggush" and
>>"heavy", no matter how well it performs the main functionality.
> 
> I encountered a team who thought they had done well to reduce the
> response time from 50 seconds to 15 (seconds). In a wire-guided
> torpedo control system .. OK, things happen slowly underwater and
> submariners learn patience, but ..

Actually it could have made the perception even worse: the 50 seconds is 
enough time to be distracted to something else (get a cup of coffee, 
etc.), but for 15 seconds a person only can stare at the control panel.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On May 1, 7:32 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> Steve Watt wrote:
> > [0] OK, a continuous 200 ms lag of response in my joystick would make
> > landing on a carrier somewhat harder.  On the other hand, if it was
> > always there, it could be trained around and compensated for.
>
> The occasional delay in the reaction of the user interface is VERY
> ANNOYING. Remember how do you feel when the mouse cursor sticks in
> Windows. If a LED is switched on later then 50ms after a button is
> pressed, the customers will call your system "dull", "sluggush" and
> "heavy", no matter how well it performs the main functionality.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

Two points

one, Vlad and Steve have it right: an important factor in user
interface is consistency of response time. A system that always
responds in 1second will be perceived as better than one that usually
responds in 200ms but occasionally takes 5seconds.

two, priority must be chosen specific to the system requirements.
having a 1second delay in responding to  a key press on a DVD player
is vastly different than pressing a button on an industrial control
panel. The DVD player might use a low priority polling task, while the
controller would use an interrupt driven event sent to a high priority
task (possibly the one to stop the equipment in an emergency
situation).

  So there is no one priority level for all UI tasks in all
applications.

  Ed

In article <IoFSj.14398$2g1.4646@nlpi068.nbdc.sbc.com>, Vladimir 
Vassilevsky says...
> 
> 
> Simon Wright wrote:
> > Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:
> > 
> >>The occasional delay in the reaction of the user interface is VERY
> >>ANNOYING. Remember how do you feel when the mouse cursor sticks in
> >>Windows. If a LED is switched on later then 50ms after a button is
> >>pressed, the customers will call your system "dull", "sluggush" and
> >>"heavy", no matter how well it performs the main functionality.
> > 
> > I encountered a team who thought they had done well to reduce the
> > response time from 50 seconds to 15 (seconds). In a wire-guided
> > torpedo control system .. OK, things happen slowly underwater and
> > submariners learn patience, but ..
> 
> Actually it could have made the perception even worse: the 50 seconds is 
> enough time to be distracted to something else (get a cup of coffee, 
> etc.), but for 15 seconds a person only can stare at the control panel.

I would think if you were operating a torpedo control system ducking out 
for a cup of coffee would be frowned upon.

Robert
** Posted from http://www.teranews.com **

Steve Watt wrote:

> [0] OK, a continuous 200 ms lag of response in my joystick would make
> landing on a carrier somewhat harder.  On the other hand, if it was
> always there, it could be trained around and compensated for.

But then, it would be a continuous 200ms lag.  It would be a 20ms 
reaction almost always, with the occasional 200ms spike in reaction time.

As to landing on carriers, a friend claims that military flight 
simulators have a 1 millisecond(!) maximum force-feedback delay for 
their joysticks.  Pilots did complain if they took longer.