Mail Archives: djgpp/2001/01/31/23:06:36
I think there might be either something wrong with your program or your BIOS
(specifically, with extended disk i/o functions).
There's no other logical explanation.
--
Alexei A. Frounze
alexfru [AT] chat [DOT] ru
frounze [AT] ece [DOT] rochester [DOT] edu
http://alexfru.chat.ru
http://members.xoom.com/alexfru/
http://welcome.to/pmode/
<dcasale AT my-deja DOT com> wrote in message news:95a7as$aie$1 AT nnrp1 DOT deja DOT com...
> 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 -