Mail Archives: djgpp/2000/10/31/21:30:17
In article <7458-Fri27Oct2000080225+0200-eliz AT is DOT elta DOT co DOT il>,
djgpp AT delorie DOT com wrote:
> > From: dcasale AT my-deja DOT com
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Thu, 26 Oct 2000 21:00:59 GMT
> > >
> > > > My program is, obviously, extremely disk-intensive. I'm caching
> > > > reads and writes with separate 5MB buffers. Could this cause
> > > > the problem?
> > >
> > > 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. This is a DOS
program, running in straight DOS. I'd like to know why. *sighs*
> > 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.
> FWIW, I run Windows 9X for days and weeks on end without rebooting,
> running disk-intensive and CPU-intensive program on it all the time,
> and I don't see any visible time slow-down.
*shrugs* Well, I _have_ seen slowdowns. Granted, not often, but I
have seen them.
> > What's even more interesting is that the clock is slow after the
> > program finishes, but a system reboot resets the clock to the proper
> > time.
>
> That's because rebooting causes the system clock to be initialized
> from the CMOS clock, which is autonomous and doesn't suffer from the
> usual factors that can slow down the system clock.
*nod* Okay.
That makes me wonder. Is there some way to read the CMOS clock on the
fly?
Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
Annoyed and disgruntled.
Sent via Deja.com http://www.deja.com/
Before you buy.
- Raw text -