<2002> 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | <2002> 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: base max thread priority |
From: | Andrew Johnson <[email protected]> |
To: | Marty Kraimer <[email protected]> |
Cc: | Eric Norum <[email protected]>, Till Straumann <[email protected]>, Jeff Hill <[email protected]>, [email protected] |
Date: | Mon, 02 Dec 2002 11:12:49 -0600 |
Marty Kraimer wrote:
Booting tornado II gives tExcTask _excTask fe80f4 0 PEND 6cd04 fe8054 0 0 tLogTask _logTask fe57cc 0 PEND 6cd04 fe5728 0 0 tShell _shell ed9540 1 READY 2cfc4 ed91e8 1c0001 0 tTelnetd _telnetd edfb38 2 PEND 253ea edfa48 0 0 tNetTask _netTask f57408 50 PEND 253ea f573b0 0 0 tPortmapd _portmapd ede5f8 100 PEND 253ea ede4b0 16 0Thus to ensure really good real time performance the priority of all of the above should be changed.
Never change the priority of tExcTask, it is used by the OS to do things that can't be run in an ISR but have been requested by one (for example outputting the message in response to a Bus Error). I would also advise not changing the shell priority here at APS at least - it has got us out of many sticky situations in the past because it's higher than everything else.
I don't think we should consider changing any existing task priorities on vxWorks, although we could adjust the way that the OSI thread priorities map to vxWorks ones if we wanted to reduce jitter by putting the scan tasks higher than tNetTask. I'd want someone to do a thorough test first though, and we don't have time for that before R3.14.1. If anyone does want to reduce the priority of tShell it's very easy to do in a vxWorks startup script.
- Andrew -- "Life is what happens while you're busy making other plans." - John Lennon