[ECOS] libc-time-clock test doesn't seem to be written correctly??

[Jonathan Larmour]

Brij Bihari Pandey wrote:
> Hi Jonathan,
> 
> 
>>>Another related thought - shouldn't the analysis of going through valid
>>> results and comparing against average -- be done using floating point
>>> arithmetic for mean/err computation and comparision?
>>
>>Why bother?
> 
> Say if things are pretty stable and the the counter values are mostly 3 but for
> some samples where there are 2 (even a single 2 does it), summation will turn
> out to Not exact multiple of 3, hence integer mean calculation will give the
> mean as 2, so notion of mean is kinda way off rather than being close to actual
> mean.
> 
> Also if clock is pretty stable but counter values turn out to be on smaller
> side, then test will incorrectly cause failures for tolerance values of say
> 40%,  because err(100*(3-2)/2) > TOLERANCE(40).
[snip]

I suppose it's possible with small values, although I've never seen a port 
do this in practice - the processor would have to be slow and the clock 
rate fast.

But I would like to avoid putting in a dependency on floating point in 
this test.

>>>- Should test fail on first err value, that is not within TOLERANCE? It
>>>may be better if failure-tolerance (another parameter) is taken on 
>>>number-of-samples not within TOLERANCE limit, to decide the
>>>test-failure.
>>
>>If the system disappears into the middle of nowhere for a long time before 
>>coming back even once, then something needs investigating. It may be 
>>alright, but that's not up to this test to know.
> 
> That's right reason to look for, but test seems to be overdoing in deciding
> test failures.

Not in my experience in boards I've so far encountered - are you saying it 
has in your case?

> I will put forth another suggestion. Rather than looking for percentage
> tolerance, what if we look for how much +/- from the average we can tolerate? 

I would accept a patch on those lines; or more precisely, something that 
checks for the %tolerance, and then checks if the difference is greater 
than an absolute amount. A fudge factor really :-). That will allow minor 
anomalies to pass, as well as small values.

Send me a patch like that and I'll review it.

>>>Though I don't quite get - - What is meant by stability of clock? - In
>>>what way the nature of test ensures it is testing stability of clock?
>>
>>Roughly equal period between clock increments.
> 
> Sorry, but I still don't get - how "equal period between clock increments"
> governs consistent/stable (from the point of view of test) return values from
> clock_loop.

If the underlying clock is correctly periodic, the return value of clock() 
should change similarly periodically. And counting how long it takes to do 
this in a for loop in a consistent way should therefore result in similar 
numbers.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss