Quote:
Originally Posted by SoftwareBug2.0
(Post 1390031)
I feel your pain with that one. There's definately been stuff that gets provided that just doesn't seem like it works the way it should. Like on the old PICs if you just took their standard template and inserted a single call to atan2() or cos() the robot would totally die. (The built-in math functions took longer than the watchdog's timeout, which was updated in the same loop)
|
Ah, nice. I've only been here in FRC for three years, so I never experienced that, but it sounds very annoying.
Quote:
Originally Posted by SoftwareBug2.0
(Post 1390031)
Why do you care about the CPU load %? If you have a latency problem then you have a latency problem regardless of CPU load. If you're not getting the throughput you want it could be because you're waiting on the internal storage. If your robot is drawing too much power, I doubt it's because of the CPU. (Does the cRIO's CPU ever go into a low power mode anyway?) And I've never heard of the cRIO having a thermal problem.
|
Actually - in rare cases with very large numbers of shared Cluck objects with a previous less optimized version of Cluck (though that reminds me that I need to finish optimizing reconnections), we had the CPU pegged at 100% for a few moments when the cRIO reconnected with the Poultry Inspector. This didn't cause any issues, but if there had been multiple other threads at 100% running at the same time, it could have noticeably affected the responsiveness of the robot.
We also had somewhere around eight threads running on our robot this season, at least a few of which were waiting for something, and that would have been a mess if those were all busywaiting. Especially if any of them had a higher priority than any of the others - even with yielding, I don't think Squawk will
ever yield to a lower-priority thread when a higher-priority thread is ready to run! AKA busywaiting is a really good way to starve important threads of resources.
We also had a
finals match in the 2013 season where the drive team had to disable a chunk of functionality on the Phidget Console due to it being broken and using 100% CPU on the Driver Station, which caused the real control functions to lag horribly.
Quote:
Originally Posted by SoftwareBug2.0
(Post 1390031)
Maybe this is just the electrical engineer in me talking but when I hear about an embedded system where the CPU usage will never spike above 2% my reaction is not that the software is super-efficient but that the desginers should have put a cheaper part on their board.
|
Yes, but in this case it's not 2%. It's 100%. This is actually relevant, as full usage can cause noticeable slowdowns. Even if the robot can handle running at 100% and perform all of its functions, it's still a recipe for disaster if you add too much more, as you'll never know how much is
actually being used instead of being consumed by busywaiting.
I've given plenty of reasons why unneeded 100% CPU usage can be or is a bad idea, and if you provide getting the current time, it won't be much more work to also provide waiting for a specific time. There's a reason that no well-built software components use busywaiting for extended periods of time. (Kernels use very brief spinlocks, but that's a fraction of a fraction of the time scale that we're working at here.) Busywaiting is a known anti-pattern and should be avoided.
Anyway, we should get back to the topic. This isn't the right place to discuss busywaiting further.
EDIT: Oops, virtuald ninja'd me with this response:
Quote:
Originally Posted by virtuald
(Post 1390034)
One reason I can think of is because if you artificially inflate the load to 100%, then when you have an *actual* load problem you won't notice it.
|
Yes, exactly. I touched on this above, even. Also, keep in mind that we're also talking about code that runs on the computer running the emulation, and usually it's not nice to have your development computer using lots of unneeded CPU.
