Subject:
|
RE: Ooops! NXT Software Comparison correction
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Thu, 6 Sep 2007 06:28:23 GMT
|
Reply-To:
|
<dickswan@sbcglobal#StopSpam#.net>
|
Viewed:
|
22050 times
|
| |
|
|
> John Hansen wrote on September 02, 2007 4:47 PM
>
> I can further manipulate the numbers for this timing test by using
> the enhanced standard firmware's support for adjusting a thread's
> priority.
>
> Here's the results when I tweak priorities:
>
> W/O LCD LCD Priorities
> ---------------------------------
> 50617 22608 40/5
> 63211 27375 80/5
> 73418 31070 200/5
After tuning, NBC achieved 73K test cycles. It achieved these great
results by setting the task "priority" to 200. Unfortunately, unless
the NXT-G task scheduler has been rewritten, these results might be a
little too high.
A NXT-G task (or "clump") priority of 200 will result in VM opcode
interpreter time slices taking up to seven milliseconds. The VM is
only supposed to take whatever time is left in the current
1-millisecond "tick".
All the firmware device drivers expect to get a CPU time slice on a
1-msec tick basis; their reliability -- rotation sensor counts may be
dropped, possible failures in USB / BT communications, driver errors,
etc -- is now compromised if they are called less frequently.
I will explain more details on this in a subsequent post.
|
|
Message is in Reply To:
 | | Re: Ooops! NXT Software Comparison correction
|
| I can further manipulate the numbers for this timing test by using the enhanced standard firmware's support for adjusting a thread's priority. Here's the results when I tweak priorities: W/O LCD LCD Priorities ---...--- 50617 22608 40/5 63211 27375 (...) (17 years ago, 2-Sep-07, to lugnet.robotics.nxt)
|
13 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
