Mail Archives: djgpp/2000/11/01/05:19:22
On Tue, 31 Oct 2000 dcasale AT my-deja DOT com wrote:
> > > > No disk I/O should ever affect the system clock.
> > >
> > > Are you absolutely sure about that?
> >
> > Yes. The timer interrupt has the highest priority, and so should not
> > be affected by almost anything else.
>
> _Should_ not be? Well obviously it _is_ being affected.
I'm not arguing with the facts. I'm trying to give you feedback,
based on the best of my knowledge, as to whether a given direction of
trying to figure out the causes for the slow-down are worth your
hassle. To the best of my knowledge, unless some TSR or device driver
messes with your clock, disk I/O cannot slow down the timer, and
neither can any CPU-intensive code such as compression. So I'd suggest
to look for the reasons not in disk I/O or compression code (if none of
them messes with the timer interrupt), but elsewhere.
> > > I've noticed the WinBloze clock slowing down sometimes, when there's
> > > a lot of disk activity or processor-intensive activity going on.
> >
> > Is that the same machine, or did you try this on several different
> > systems? If that's the same machine, my first suspicion would be
> > either some optional software that you have installed there, or a
> > hardware problem.
>
> At least two different systems.
What OS/versions did you run on both machines? Do both machines have
similar or identical setup (TSRs and device drivers loaded)? Did you
try to run the program on vanilla DOS system, without any TSRs and
device drivers? How about posting CONFIG.SYS and AUTOEXEC.BAT?
> That makes me wonder. Is there some way to read the CMOS clock on the
> fly?
Of course. You can read that clock by accessing ports 70h and 71h.
- Raw text -