This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: libc-time-clock test doesn't seem to be written correctly??
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