This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]