Go to Post It's not a problem, it's a feature! - smokescreen [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
  #16   Spotlight this post!  
Unread 16-06-2014, 02:59
Cel Skeggs Cel Skeggs is offline
Robot Software Manager Alumnus
AKA: Previously known as Colby
FRC #1540 (The Flaming Chickens)
Team Role: Alumni
 
Join Date: Feb 2013
Rookie Year: 2009
Location: Portland, Oregon, USA
Posts: 107
Cel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of light
Re: Challenge problem: 'ladder of abstraction' iterative design in FRC

Quote:
Originally Posted by SoftwareBug2.0 View Post
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 View Post
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 View Post
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 View Post
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.
__________________
Software manager alumnus. Developer of the CCRE, a powerful robot code framework based on dataflow and composibility.
Refer to as she/her/hers. Years of FRC: 2012, 2013, 2014, 2015, 2016. FLL for a few years beforehand.
Team 1540: The Flaming Chickens | Portland, Oregon | Twitter | Facebook

Last edited by Cel Skeggs : 16-06-2014 at 03:01. Reason: Ninja'd by virtuald
  #17   Spotlight this post!  
Unread 16-06-2014, 04:18
SoftwareBug2.0's Avatar
SoftwareBug2.0 SoftwareBug2.0 is offline
Registered User
AKA: Eric
FRC #1425 (Error Code Xero)
Team Role: Mentor
 
Join Date: Aug 2004
Rookie Year: 2004
Location: Tigard, Oregon
Posts: 488
SoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant future
Re: Challenge problem: 'ladder of abstraction' iterative design in FRC

Quote:
Originally Posted by virtuald View Post
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.
Certainly, if you've got the CPU pegged you have to look at some other metric to measure your performance. We just put everything together in one loop and used something like this:
Code:
class Perf_mon{
	Time start,last,worst_case_;
	unsigned iterations;

	public:
	Perf_mon():start(-1),last(-1),worst_case(0),iterations(0){}

	void update(Time t){
		if(last==-1){
			start=t;
		}else{
			auto elapsed=t-last;
			worst_case_=max(worst_case_,elapsed);
		}
		last=t;
		iterations++;
	}

	Time average()const{ return iterations/(.0001+start-last); }
	Time worst_case()const{ return worst_case_; }
};
And this was kind of overkill since we could just look at the worst case, notice it was much faster than the driver station data updated, and be done.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 19:23.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi