Mail Archives: djgpp/2001/01/31/18:51:38
In article <95a1qh$gkt4b$1 AT ID-57378 DOT news DOT dfncis DOT de>,
"Alexei A. Frounze" <dummy_addressee AT hotmail DOT com> wrote:
> "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> wrote in message
> news:9003-Wed31Jan2001192619+0200-eliz AT is DOT elta DOT co DOT il...
> > >
> > > If there's some code which runs upon timer interrupt and the
> > > number of instructions there varies from tick to tick, then if we
> > > measure time using BIOS tick counter, we end up with certain
> > > error due to that code (SMARTDRV is the case).
> >
> > I don't think so. Since the timer tick works at a constant
> > frequency, and since the time of the next tick does not depend on
> > the time of the previous tick, the system clock will not slow
> > down. What will happen is that the time when the BIOS time counter
> > increments will vary slightly, depending on how much code runs off
> > the timer tick.
> >
> > This of course assumes that the code in the TSR doesn't take all the
> > 54 msec until the next tick.
> >
> > AFAIK, SmartDRV has special code to make sure it only reads/writes
> > amount of data that is small enough to leave enough of the CPU tiume
> > to the foreground task.
> >
> > The issue with the compression program referred to by the message to
> > which I responded was that running that compression program caused
> > the system clock to lag behind the real time by significant
> > amounts. I don't think such a slow-down of the system clock can be
> > caused by any reasonable TSR which hooks the timer tick (and
> > SmartDRV is a reasonable TSR).
> Timer itself generates IRQs at a constant rate, right. But the DOS
> program being run under windows (or with presense of such things as
> SMARTDRV) can not have a perfect time measurement and perfect cycle
> measurement. Try to reread my post and see why. I guess I explained
> clearly.
Maybe I'd better explain what's going on with this program of mine. :-)
First of all, I wrote a compression program using DJGPP to store all of
the files and file information (including long filenames, file
attributes, etc.) in one big file. To access the file information not
available through straight DOS -- since that's what I'm running under --
I use direct disk access (INT13h, AH=042h, as well as other disk
access calls) to get at the info (for example, long filenames).
With compression off, the disk is constantly being read or written to.
I'm using direct file reads -- that is, I don't use DOS calls but
instead read the files directly by caching the FAT and pulling sectors
off of the drive. The system clock runs at its normal speed,
apparently. But with compression on, there are periods of disk
inactivity during which the program does its number crunching. And,
the system clock ends up running about 30% slower than normal.
Rebooting resets the system clock to its proper time.
I tried running the program again without SmartDrive loaded, and _the
slowdown did not happen_!!
Whatever the explanation, I just wanted to pass this along.
Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
"In the year 2525..."
Sent via Deja.com
http://www.deja.com/
- Raw text -