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

[Jonathan Larmour <jifl at eCosCentric dot com>]

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