706 had the curse of all curses

[boomergeek]

"That's not strictly true is it?"

My understanding is there are several tasks that run "timeshared" with the user program. The default teleopcontinuous() method provides a 1 millisecond task delay every cycle.

If a team removes this task delay by defining a different teleopcontinuous() in an attempt to run their code faster, then they are actually reduce the overall performance because the operating system ends up with fewer chances to run both higher and lower (and the same) priority tasks.

The complexity and processing that some teams attempt to put in their code can overstress the CRio. The library of canned code available to monitor the performance of the system is sort of non-existent.

Ten years ago, I did some time as a performance SW developer responsible for assuring fiber optic telecommunications systems would be able to always switch within 25 ms of fiber cuts and other failures under VXWorks.

Anyone that has spent time in performance software can tell you that time logging of critical events and measuring the CPU resource being used up, monitoring queues of messages between tasks by all the processes in the system is critical to understanding how close to overloading a system is operating.

I'm guessing that more experienced teams that don't actually log/monitor system performance have developed rules of thumb for themselves to know if they are in the safe zone of loading a system down without overloading it.

I'm toying with the idea of getting team 241 to create a library of performance and logging tools and then share it with the FIRST community.

Then during practice a team can determine if it is coming close to using up scarce resources.
And if a special problem occurs during a field play that never showed up during practice, then a file logging of all the key parameters can be used to diagnose "misbehavior".

It would be a lot of work, but looking at perplexed teams at Regionals and reading here on CD, I perceive a serious need.