Baho Utot wrote:
> cat /mnt/lfs/Build/glibc-build/rt/tst-cpuclock2.out
> live thread clock fffdd58e resolution 0.000000001
> live thread before sleep => 0.000053078
> self thread before sleep => 0.000169320
> live thread after sleep => 0.501525776
> self thread after sleep => 0.000186263
> process before - after 500355090 outside reasonable range (501472698)
What this test is doing is checking the difference between thread times
and process times. The values above are nanoseconds. It's saying that
the process time is shorter than the thread time (by slightly more than
one millisecond). This is a breakdown of the code:
clock_gettime (process_clock, &process_before)
clock_gettime (th_clock, &before)
clock_gettime (my_thread_clock, &me_before)
struct timespec sleeptime = { .tv_nsec = 500000000 };
nanosleep (&sleeptime, NULL)
clock_gettime (th_clock, &after)
clock_gettime (process_clock, &process_after)
clock_gettime (my_thread_clock, &me_after)
What appears to be happening is that the main process sleeps while the
thread doesn't. The thread time is thus 501525775 ns, The limits here
are 100000000 to 600000000 ( .1 to .6 seconds) and it passes.
The time for the my_thread_clock should be less than 0.1 second and that
passes. No data is given about that though. I added a printout and it
was generally about 12000 ns.
Google suggests that being in chroot may be a factor.
To check that out, I rebuilt glibc on my system outside of chroot. I
was able to duplicate the error.
live thread before sleep => 0.000057951
self thread before sleep => 0.000168869
live thread after sleep => 0.500118785
self thread after sleep => 0.000180958
process before - after 499973217 outside reasonable range (500060834)
And on other runs, I get:
live thread clock fffffffffffc65f6 resolution 0.000000001
live thread before sleep => 0.000030323
self thread before sleep => 0.000120303
live thread after sleep => 0.500091485
self thread after sleep => 0.000130988
process before - after 499295588 outside reasonable range (500061162)
bdu...@core2-64 [ /mnt/lfs/sources/glibc-build ]$ rt/tst-cpuclock2
live thread clock fffffffffffc65de resolution 0.000000001
live thread before sleep => 0.000004984
self thread before sleep => 0.000112728
live thread after sleep => 0.500025515
self thread after sleep => 0.000122332
So it is intermittent timing error. Here is another failure after I
modified the test to print out more data:
process before sleep => 0.000141026
live thread before sleep => 0.000034383
self thread before sleep => 0.000118320
live thread after sleep => 0.500092632
process after sleep => 0.500097116
self thread after sleep => 0.000130039
process before - after 499956090 outside reasonable range (500058249)
thread before - after 500058249
process before - after 499956090
my_diff before - after 11719
In this case, the timers say that the process was 102159 ns or about
1/1000 second faster than the thread. This may have some implications
in certain real time applications, but I don't see an issue for LFS.
A pass looks like:
thread before - after 505293557
process before - after 505305328
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
