From: "Alexei A. Frounze" <dummy_addressee AT hotmail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP timer slowdown
Date: Wed, 31 Jan 2001 22:53:03 -0500
Lines: 82
Message-ID: <95amh1$gi8k1$1@ID-57378.news.dfncis.de>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010131103626 DOT 29266V-100000 AT is> <959emd$g57sf$1 AT ID-57378 DOT news DOT dfncis DOT de> <9003-Wed31Jan2001192619+0200-eliz AT is DOT elta DOT co DOT il> <95a1qh$gkt4b$1 AT ID-57378 DOT news DOT dfncis DOT de> <95a7as$aie$1 AT nnrp1 DOT deja DOT com>
NNTP-Posting-Host: ip56.rochester6.ny.pub-ip.psi.net (38.26.84.56)
X-Trace: fu-berlin.de 980999522 17375873 38.26.84.56 (16 [57378])
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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/