View Single Post
  #16   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.