dsr@stl.stc.co.uk (David Riches) (07/14/89)
Has anyone got a timestamp routine, written in C, which has a resolution of milliseconds (possibly lower)? Dave Riches PSS: dsr@stl.stc.co.uk ARPA: dsr%stl.stc.co.uk@earn-relay.ac.uk Smail: Software Design Centre, (Dept. 103, T2 West), STC Technology Ltd., London Road, Harlow, Essex. CM17 9NA. England Phone: +44 (0)279-29531 x2496
scs@adam.pika.mit.edu (Steve Summit) (07/15/89)
In article <1595@stl.stc.co.uk> dsr@stl.stc.co.uk (David Riches) writes: >Has anyone got a timestamp routine, written in C, which has a >resolution of milliseconds (possibly lower)? The implementation of such a routine would be highly system- dependent. A somewhat standard but little-known routine already exists which provides what you want: ftime(). It returns a structure which "contains the time since the epoch in seconds, [and] up to 1000 milliseconds of more-precise interval." If your vendor happens to provide an implementation of this routine, you're in luck; if not, there's not much portable you can do. (X3J11 doesn't appear to help, and neither does POSIX, which I just discovered doesn't endorse ftime, which is a miserable omission, but not a topic for this newsgroup.) Steve Summit scs@adam.pika.mit.edu P.S. Microsoft supplies ftime() for MS-DOS; the version of TurboC I've used doesn't (although later versions may have added it).
craigb@hp-sdd.hp.com (Craig Bosworth) (07/18/89)
Turbo C 2.0 does have ftime(). It returns seconds and milliseconds since
midnight GMT, 1-1-70. The actual resolution is 5 or 6 hundreths. It is
in the Reference Guide, p. 146.
BOS
--
Craig Bosworth (619) 592-8609 16399 West Bernardo Drive
Hewlett-Packard, San Diego Division San Diego, CA 92127-1899
UUCP : {hplabs|nosc|hpfcla|ucsd}!hp-sdd!craigb
Internet : craigb%hp-sdd@hp-sde.sde.hp.com (or @nosc.mil, @ucsd.edu)guy@auspex.auspex.com (Guy Harris) (07/18/89)
>The implementation of such a routine would be highly system- >dependent. A somewhat standard but little-known routine already >exists which provides what you want: ftime(). 1) "somewhat standard" is the key word here. In the UNIX world, it's in V7, and in 4.xBSD, but not in System V. >It returns a structure which "contains the time since the epoch in seconds, >[and] up to 1000 milliseconds of more-precise interval." 2) "more precise" doesn't necessarily mean "precise down to the millisecond"; it will probably reflect the resolution of the OSes clock, which is may well be closer to 10 milliseconds than one millisecond. >If your vendor happens to provide an implementation of this >routine, you're in luck; if not, there's not much portable you >can do. Unless your vendor happens to provide an implementation of "gettimeofday()", which first appeared in 4.2BSD, and upon which "ftime()" is implemented in 4.xBSD and many systems that picked up "gettimeofday()" from it. The previous comment about resolution applies to it as well....
scs@adam.pika.mit.edu (Steve Summit) (07/29/89)
In article <2247@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>A somewhat standard but little-known routine already >>exists which provides what you want: ftime(). >1) "somewhat standard" is the key word here. In the UNIX world, it's in V7, > and in 4.xBSD, but not in System V. What a miserable pity. No wonder it's not in POSIX. >>It returns a structure which "contains the time since the epoch in seconds, >>[and] up to 1000 milliseconds of more-precise interval." >2) "more precise" doesn't necessarily mean "precise down to the > millisecond"; it will probably reflect the resolution of the OSes > clock, which is may well be closer to 10 milliseconds than one > millisecond. Indeed. Given, however, that it is documented and understood that, in effect, the LSB's of the millitm field (the "more-precise interval") do not necessarily wiggle, it is extremely unfortunate that such a function is not standard. (Why in the world did SYSV drop ftime?) Subsecond timing is important for many programs, and there's no other way to get it. I don't mind it when superfluous system calls are deleted in the interests of streamlining or standardization, but ftime (or the equivalent) is irreplaceable. I submit that any vendor (that can support POSIX) can supply ftime. Given that the time() function is required, write ftime (at the very least) as: ftime(tp) struct timeb *tp; { tp->time = time((time_t)0); tp->millitm = 0; return 0; } (this ignores the timezone and DST stuff). My point is not that this is a good implementation (it isn't), but that it is an acceptable one, and therefore that "some systems couldn't implement it" is not an adequate reason for leaving ftime out of standards. Steve Summit scs@adam.pika.mit.edu
guy@auspex.auspex.com (Guy Harris) (07/30/89)
>>1) "somewhat standard" is the key word here. In the UNIX world, it's in V7, >> and in 4.xBSD, but not in System V. > >What a miserable pity. No wonder it's not in POSIX. No, but the "times()" that returns clock ticks since some arbitrary point in the past is in POSIX, so if all you want is to get the time difference between two events in clock ticks, you can do that. >Indeed. Given, however, that it is documented and understood >that, in effect, the LSB's of the millitm field (the >"more-precise interval") do not necessarily wiggle, it is >extremely unfortunate that such a function is not standard. Well, "times()" is standard; if you want wall-clock time (as opposed to deltas in wall-clock time) with higher than one-second resolution, you'll probably have to wait for the POSIX real-time standard (and, of course, set your machine's clock to whatever your national wall-clock time standard is...). >(Why in the world did SYSV drop ftime?) They may never have picked it up in the first place, going with "times()" instead.