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

[sandeep]

> No need. That synchronization is already done by virtue of this function 
> itself being called in a tight loop and the first few results discarded 
> (the SKIPPED_SAMPLES in the test). So when this function returns, 
> clock() will still have "just changed" and the function is then 
> immediately called again. If nothing else, there are a consistent number 
> of instructions between calls to clock().
yes. there are consistent number of instructions between calls to clock(). But

the time taken to reach Ith iteration in consecutive calls to clock_loop is not

guaranteed to be multiple of clock() updation time. That way it is highly 
possible that - first time the clock() value change was observed in iteration 
number (say 100) and it can deviate from this in gradual manner either on 
increasing/decreasing side.

currently SAMPLES is set to 30, changing it to a higher value say 500, is likely

to lead to a observable pattern to you too (that can explain initiation of this 
discussion).

>> // ???????????????
>> // why should following be a fail condition in test where we are 
>> trying to
>> // check for clock stability
>> // ???????????????
> 
> It's a test, and testing for stability is the main goal but not the only 
> one. Let's test for things that shouldn't happen.
you didn't clarify the doubt. But sure, for low SAMPLES values of 30 wrap

around isnot expected to happen, if that's what you mean.


-- 
regards
sandeep
-----------------------------------------------------------------------
Ashes to ashes,dust to dust,
if the Lord won't have you,
the Devil must.
-----------------------------------------------------------------------


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