From:	mauch AT uni-duisburg DOT de (Michael Mauch)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: testing uclock()
Date:	Sat, 26 Apr 1997 19:02:06 +0200
Organization:	Home, sweet home (via Gesamthochschule Duisburg)
Lines:	91
Distribution:	world
Message-ID:	<336208f2.110883@news.uni-duisburg.de>
References:	<1 DOT 5 DOT 4 DOT 32 DOT 19970424124818 DOT 002d7ec8 AT ubeclu DOT unibe DOT ch>
NNTP-Posting-Host:	ppp103.uni-duisburg.de
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

On Thu, 24 Apr 1997 12:48:18 GMT, Roger Noss <noss AT pupk DOT unibe DOT ch> wrote:

> I am trying to follow the many recommendations to use uclock() but am
> getting inconsistent results.  I am working in a DOS window of WinNT3.51 on
> a 200MHz Pentium Pro.  Below is a test program to see just how long a call
> to uclock() takes.  I call uclock() 100 times, store the values in an array,
> and print the difference array.  The output is in uclock ticks, about 840 ns
> each.  The first value printed is not 0, although the info page says the
> first call to uclock() resets it.  Why should each call take more than 10
> ms?  Also, every third or fourth value is negative - why?  What am I doing
> wrong?
> 
> Roger Noss
> 
> #include <time.h>
> #include <stdio.h>
> 
> int main(void)				/* testing uclock() */
> {
> 	uclock_t t0, dt[100];
> 	short i;
> 
> 	printf( "%d\n", (int) t0 );	/* first call resets clock to 0 */

I suppose this should be:
	printf( "%d\n", (int) (t0 = uclock()));	

Then the program works like it should - on plain MS-DOS 7 in virtual x86
mode. The first call to uclock() returns 0 and the other values are
always from 4 to 7 on my Pentium 75. 

However in a DOS window of Win95, I also get negative values sometimes
(i.e. not in each run, and only one of the hundred numbers).

To test this problem, I changed your program so that it prints the
uclock values in hex, not the differences. 

  printf( "%x ", (int)( dt[i] ) );

This is one output:

0
561 579 591 5a9 5c1 5d9 5f1 609 622 639
651 66a 681 699 6b2 6ca 6e1 6fa 712 72a
743 75a 772 78b 7a3 7bb 7d3 7eb 804 81b
833 84c 863 87b 894 8ab 8c3 8dc 8f3 90b
924 93b 953 96c 983 99b 9b4 9cb 9e3 9fc
a13 a2b a44 a5b a73 a8c aa3 abb ad4 aeb
b03 ffff0b1d ffff0c86 ffff0c9e ffff0cb6 ffff0cce ffff0ce5 ffff0cfd
ffff0d15 ffff
0d2d
ffff0d45 ffff0d5d ffff0d75 ffff0d8c ffff0da5 ffff0dbd ffff0dd4 ffff0ded
ffff0e05
 ffff0e1c
ffff0e35 ffff0e4d ffff0e64 ffff0e7d ffff0e95 ffff0eac ffff0ec5 ffff0edd
ffff0ef4
 ffff0f0d
ffff0f25 ffff0f3c ffff0f55 ffff0f6d ffff0f84 ffff0f9d ffff0fb5 ffff0fcc
ffff0fe5

So the values seem to be correct, if we would look only at the 16 least
significant bits. This would give us a maximum timing period of about 55
ms, though - not enough for "real life", but enough for your test
program. To confirm this, I casted away the high bits of your program:

  printf( "%d ", (int) ( (short int)dt[i] - (short int)dt[i-1] ) );

One of the outputs is now:

0
28 23 24 25 23 24 25 23 24 25
23 24 25 23 24 26 6812 25 25 24
23 25 24 24 25 24 23 25 24 25
23 24 25 23 24 25 23 24 25 23
24 25 23 24 25 23 24 25 23 24
25 23 24 25 23 24 25 23 24 25
23 24 25 23 24 25 23 24 25 23
24 25 23 24 25 23 24 25 23 24
25 23 24 25 23 24 25 23 24 25
23 24 25 23 24 25 23 24 25

There are not many occurences of values above 30, and these could be
caused by multi-tasking events.

So my conclusion is: there is a problem with uclock() (thanks for
pointing it out, Roger!), but it is not a matter of principle, but there
seems to be a bug in the code. I think I'll have to get the libc sources
and have a look at it.

Regards...
		Michael

- Raw text -