On Mon, May 07, 2012 at 07:05:23PM -0700, Frank Rowand wrote:
| On 05/07/12 17:30, Luis Claudio R. Goncalves wrote:
| > On Mon, May 07, 2012 at 03:00:17PM -0700, Frank Rowand wrote:
| > | This is the resulting message on the ARM panda with a 'bad'
| > | 32khz timer:
| > |
| > |
| > | # cyclictest -q -p 80 -t -n -l 10 -h ${hist_bins} -R 100
| > | reported clock resolution: 1 nsec
| > | measured clock resolution less than: 30517 nsec
| >
| > How about using a fixed loop size (say 1000000 clock reads) to define
| > the average cost of reading the clock (the second value presented above)
| > instead of a variable amount of iterations? Reading the clock twice and
| > calculating the average could lead to wrong impressions. Also, it would
| > be interesting to run such test under a real time priority (FIFO:2, maybe?)
| > to avoid too much external interference on the readings, mainly involuntary
| > context switches.
| >
| > Having too different values called 'clock resolution' may be a good source
| > of confusion. The value of clock_getres() is the resolution, as per the
| > system jargon, and the second value should be granularity, reading cost,
| > the-average-time-it-takes-to-read-the-clock or something alike.
|
| The 'measured clock resolution' is not intended to be representative of the
| time it takes for clock_gettime() to execute. It really is a measure of
| the resolution that the clock is actually delivering. It is the smallest
| amount that the actual clock actually increments.
Sorry, I read your patch 'upside-down' and I was not considering the
possibility of clock_getres() returning a totally bogus value. Wouldn't
that be the case to fix the resolution information for this clocksource
in the kernel?
How about running your test for a fixed amount of time? 250ms sounds like a
safe amount of time and if the readings do not change in 250ms you surely
have a problem with the clock. A configurable amount of repetitions may
lead to wrong results... if you are locky enough to have the clock valu
changing right in th middle of you 10x loop, you may see latencies later
that are just fruit of the unreliable clock.
You could also, when reporting the findings about the clock resolution,
that said resolution could mask latencies as big as it. Or induce in the
results latencies as big as it.
Anyway, nice patch.
Cheers,
Luis
--
[ Luis Claudio R. Goncalves Red Hat - Realtime Team ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9 2696 7203 D980 A448 C8F8 ]
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
