kink@hscfvax.UUCP (10/06/83)
#N:hscfvax:400003:000:635 hscfvax!kink Oct 5 17:30:00 1983 Hi, I just moved to a place where they don't have IPC. I have some interesting games that require real-time increments in the milli-sec. range, and I've been trying to hack something together. I tried a loop doing repeated FTIME calls (which should return all the clock info, as of the time of the call), but found to my dismay that whatever clock this uses is updated in some saltatory (periodic?) manner. In otherwords, it says "384 milli-sec" for several calls to FTIME, then changes immediately to "415 millisec." Why is this, and how would you suggest I proceed??? Thanx in advance for your genious, Andy Papp (kink)
sdyer@bbncca.ARPA (Steve Dyer) (10/06/83)
Ftime's concept of milliseconds, at least on machines without millisecond clocks, is incremented in values of HZ/1000, where HZ is usually 50 of 60. You probably want to see about getting the "nap" device driver/system call if your applications really require <1 sec sleeps. I don't have it myself, but others might give you pointers. /Steve decvax!genrad!wjh12!bbncca!sdyer ...!ima!bbncca!sdyer P.S.: Looping in ftime() is pretty antisocial!
dyer@wivax.UUCP (Stephen Dyer) (10/07/83)
OOPS! I meant that ftime's conception of milliseconds jumps by 1000/HZ every clock tick (NOT HZ/1000). Redfaced, Steve Dyer decvax!wivax!dyer decvax!genrad!wjh12!bbncca!sdyer ...!ima!bbncca!sdyer sdyer@bbncca
gwyn%brl-vld@sri-unix.UUCP (10/13/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> The UNIX kernel only updates its internal time counter on a clock interrupt, usually every 1/60th of a second (maybe 1/50th or 1/100th depending on your hardware). There is no way it is going to be able to tell you what time it is between "ticks". You can buy a clock peripheral from Digital Pathways (maybe other vendors too) and write a device driver to interrogate it. Sometimes you can output NUL characters to get small delays in updating video terminal displays. It would be interesting to hear what game you have that could take advantage of high-resolution time on a time-sharing system.