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??
sandeep wrote:
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.
I think I see what you are trying to get at - the fixed overhead between
the calls to clock(). But this can't apply because we'll always wait for
the next time clock() changes so we'll resync. The only exception might be
if there is only 1 (or even 0) loop iterations within clock_loop(). But
courtesy of that new fudge factor we don't have to worry about that case
any more.
Anyway any fixed overhead should be very small compared to the frequency
at which clock() changes (if we're getting interrupts that are so frequent
that they leave little CPU time between interrupts, we deserve to report a
problem!).
Look at it this way - the way to "fix" that would be to change
clock_loop() so that it directly waited for the next time clock() changed,
and then count the number of loop changes until clock() changes again.
Well that's essentially what already happens.
Secondly, you can never eliminate fixed overhead as it occurs simply by
virtue of calling clock() in the first place.
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).
Just to give the benefit of the doubt, I tried it with 3000, and saw no
such trend, sorry.
// ???????????????
// 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.
clock() should monotonically increase for the lifetime of this test. POSIX
requires that CLOCKS_PER_SEC equals 1000000, and for a 32-bit clock_t that
means it will wrap around every 35 minutes or so. That's good enough for
this test, even with quite high values of SAMPLES. I'm not worried.
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