From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,89d65c5ea403ba58 X-Google-Attributes: gid103376,public From: tmoran@bix.com (Tom Moran) Subject: Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar Date: 1999/01/12 Message-ID: <369b9329.663033@news.pacbell.net>#1/1 X-Deja-AN: 431756114 References: <01be3c40$f93dc120$3804fbd1@longslide> <369A7B97.6AC0CA00@hercii.mar.lmco.com> <568mzAiP#GA.245@pet.hiwaay.net> X-Complaints-To: abuse@pacbell.net X-Trace: typhoon-sf.pbi.net 916165462 207.214.211.237 (Tue, 12 Jan 1999 10:24:22 PDT) Organization: SBC Internet Services NNTP-Posting-Date: Tue, 12 Jan 1999 10:24:22 PDT Newsgroups: comp.lang.ada Date: 1999-01-12T00:00:00+00:00 List-Id: The 8253 tick rate was 1/4 of the 4.77 MHz of the original PC, which was 1/3 the 14.31818 MHz rate of cheap color TV crystals. The interrupt occurs when the 8253's internal 16 bit counter hits zero, so the maximum delay between interrupts is 2**16 internal ticks. 12/14.31818*65536= 54.925 milliseconds. DOS, et al, increment a four byte counter on the interrupt, so the lower two bytes generate a carry to the upper two every 0.054925*65536= 3599.56 seconds. If the 8253's internal count is set to start at less than maximum, it will reach zero sooner and interrupt sooner. If the program reads the 8253's internal count, it can append those two bytes to the right of the software 4 bytes, giving a counter with 12/14.31818= 0.838 mics resolution. Windows' QueryPerformanceCounter does this on PC compatible hardware. There was no such system call in DOS; you had to program this yourself. Most programs, including most Ada.Calendar.Clock's, use the low-res Time system call, so they get the interrupt count, which only changes every 55 ms. It's easy enough to make your own Ada.Calendar.Clock that reads the high-res software+hardware time, but some Ada run-times may not use Ada.Calendar.Clock internally, so 'delay' might not use your new high-res Clock. Win95 has a system call to release the CPU until a certain time. That time has a 55ms resolution. So, without fancy footwork, you can't get interrupts with smaller resolution. I think NT sets the interrupt time to 10ms. Of course, if the system decides to flush the disk cache or something, it may be quite a bit longer before you get the CPU. If you have control of the hardware, eg DOS, you have freedom to poll without worrying you're slowing Solitaire, or to change the interrupt rate, or whatever.