clock(3) non-functional?
Hi,
Looking at libsamplerate test problems, I found that clock(3) used
there is not reliable. Strange results are obtained on too Linux with a
simple test program. Using clock_gettime(2) instead on both Linux and
Hurd works perfectly. The Linux man page for clock(3) says that it is
implemented on top of clock_gettime(2) since glibc 2.18 and later, not
on times(2) as before. Is that true for Hurd too?
The following simple program gives unreliable results both on Linux and
especially Hurd:
clock_t start, end;
double cpu_time_used;
start = clock();
printf("start = %ld\n", start);
sleep(3);
end = clock();
printf("end = %ld\n", end);
cpu_time_used = (double) (end - start) / CLOCKS_PER_SEC;
printf("cpu_time_used = %f\n", cpu_time_used);
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404052542.2088.18.camel@PackardBell-PC
Processed: reassign 752237 to hurd
Processing commands for cont...@bugs.debian.org: > reassign 752237 hurd Bug #752237 [libc0.3] libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd Bug reassigned from package 'libc0.3' to 'hurd'. No longer marked as found in versions eglibc/2.19-3. Ignoring request to alter fixed versions of bug #752237 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 752237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752237 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.140406430022716.transcr...@bugs.debian.org
Re: clock(3) non-functional?
Hello, Svante Signell, le Sun 29 Jun 2014 16:35:42 +0200, a écrit : > Looking at libsamplerate test problems, I found that clock(3) used > there is not reliable. Strange results are obtained on too Linux with a > simple test program. What do you mean by "strange"? The output I get $ ./test start = 3870 end = 3910 cpu_time_used = 0.40 makes sense. > Using clock_gettime(2) instead on both Linux and > Hurd works perfectly. Err, but clock_gettime returns something completely different than clock(). > The Linux man page for clock(3) says that it is > implemented on top of clock_gettime(2) since glibc 2.18 and later, not > on times(2) as before. Is that true for Hurd too? See the various clock.c files in the glibc source: the hurd one hasn't changed at all, while the Linux one has indeed. > The following simple program gives unreliable results both on Linux and > especially Hurd: Again, what do you mean by "unreliable"? What did you expect? Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140629205603.gy6...@type.youpi.perso.aquilenet.fr
Re: clock(3) non-functional?
On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote: > Hello, > > The following simple program gives unreliable results both on Linux and > > especially Hurd: > > Again, what do you mean by "unreliable"? What did you expect? I'd expected an elapsed time of 3 seconds with a sleep(3) in between start and stop. That's the usage in the libsamplerate code. If it is computer CPU time to execute the command sleep(3) the result seems reasonable. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404076274.17964.13.camel@PackardBell-PC
Re: clock(3) non-functional?
Svante Signell, le Sun 29 Jun 2014 23:11:14 +0200, a écrit : > On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote: > > Hello, > > > > The following simple program gives unreliable results both on Linux and > > > especially Hurd: > > > > Again, what do you mean by "unreliable"? What did you expect? > > I'd expected an elapsed time of 3 seconds with a sleep(3) in between > start and stop. That's the usage in the libsamplerate code. If it is > computer CPU time to execute the command sleep(3) the result seems > reasonable. sleep(3) does not consume CPU, so the value returned by clock() is not supposed to increase much. You have to use a busy loop in order to consume CPU. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140629212349.gb6...@type.youpi.perso.aquilenet.fr
