LFS 6.5 6.9. Glibc-2.10.1 test error

Baho Utot baho-utot at columbus.rr.com
Wed Feb 17 14:41:39 PST 2010


Bruce Dubbs wrote:
> 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)
>
> bdubbs at 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
>   

Thanks for taking the time to check this out.

I have looked at CLFS glibc build and builds from arch linux and tried 
various CFLAGS to no CFLAGS and nothing seems to change the out come.... 
always get the same results.
So I believe it could possibly be due to the hardware?

Any way I have went ahead and installed 6.9 glibc and it came back with:

CC="gcc" /usr/bin/perl scripts/test-installation.pl /Build/glibc-build/
Your new glibc installation seems to be ok.
make[2]: Leaving directory `/Build/glibc-2.10.1'
make[1]: Leaving directory `/Build/glibc-build'

So I am thinking the build is fine.
I'll keep a look out for strange happenings later in the builds ;-)




More information about the lfs-support mailing list