response time

Peter Hansen peter at engcorp.com
Tue Nov 11 10:06:08 EST 2003


"John J. Lee" wrote:
> 
> Peter Hansen <peter at engcorp.com> writes:
> [...]
> > Strange, but based on a relatively mundane thing: the frequency (14.31818MHz)
> > of the NTSC color sub-carrier which was used when displaying computer output
> > on a TV.  This clock was divided by 3 to produce the 4.77MHz clock for the
> [...]
> > in time-keeping, which then counted on every edge using a 16-bit counter
> > which wrapped around every 65536 counts, producing one interrupt every
> > 65536/(14.31818*1000000/12) or about 0.5492 ms, which is about 18.2 ticks
> [...]
> 
> That doesn't explain it AFAICS -- why not use a different (smaller)
> divisor?  An eight bit counter would give about 0.2 ms resolution.

Can you imagine the overhead of the DOS timer interrupt executing over 500
times a second?!  It would have crippled the system.  In fact, from what
I recall of the overhead associated with that interrupt, that might well
have consumed every last microsecond of CPU time.

Also, the hardware probably doesn't even support an "eight bit counter".
That is, there's a good chance that the behaviour described comes entirely
"for free", after setup, whereas using any other value would have required
a periodic reload, in software, which would have been deemed an unacceptable
burden on performance.  I believe one of the first links to the Google 
search I mentioned has the part number of the timer chip in question, so 
you could investigate further if you're curious.

And if you wonder why Windows still had to stick with the same value, 
well, let's just say that it's one of the best proofs that I've seen
that even Windows 98 is nothing more than a glossy GUI shell on top
of DOS.

-Peter




More information about the Python-list mailing list