You know you can disable write-behind caching in both Smartdrv and W95/98
dont you?
I wouldnt worry about it with networked computers, but it's valid as a single
computer.
73, Ty K3MM
----- Original Message -----
From: rpb <w9zv@ce.mediaone.net>
To: <trlog@contesting.com>
Sent: Friday, September 17, 1999 18:34
Subject: [TRLog] SMARTDRV - not too smart
>
>
> >
> >Just though of one thing which should be placed AT THE FRONT of the
> >manual, and in BIG, BOLD letters. This is a note to users about
> >ADDING the following line to their CONFIG.SYS file:
> >
> > lh c:\windows\command\smartdrv.exe a+ c+
> >or
> > lh c:\dos\smartdrv.exe a+ c+
>
> WHOA.... DANGER WILL ROBINSON, DANGER !!!! ( imagine flailing robot arms
:-) )
>
> Running SMARTDRV is like planning to have a fire.....
>
> I would put it in BIG BOLD LETTERS to NEVER run SMARTDRV.... To suggest
> anything else will ensure that TRLog will get blamed for things that are
> NOT it's fault...
>
> one of the things that makes TRLog very reliable is because it DOES run
> under the auspices of DOS. The interfaces presented ensure that data is
> committed and flushed to the storage media at the point the software sez it
> wants to. If you have to wait for the floppy, that is an artifact of the
> hardware not of the software attempting to commit it do disk. What happens
> when you put SMARTDRV in place, it defers writes until some later
> time. The software which tried to commit the data to the disk "thinks" it
> has done so, but it really hasnt, and it is sitting in volatile RAM. Now, a
> power hit occurs, and you have lost all of your data that SMARTDRV has
> cached in RAM but has not yet committed to disk.
>
> Similarly, running under Win95/98 presents a similar problem since it is
> more sophisticated than DOS and inherently does disk caching behind the
> scenes. This is one of the many reasons why windows software is more
> susceptible to power failures and such. By the magic of the OS, the
> application simply is unaware that this caching is going on between the
sheets.
>
> Case in point -
> last year at field day, i came to operate on the night crawler shift and
> there was a lot of discussion being bantered about how they lost the entire
> log. Just about all the four letter words in our American vocabulary were
> used with regards to the software logging program employed (CT, another DOS
> based logging pgm). Just as i was sitting behind the ops running 20m CW,
> the jenny ran out of gas. After filling it up again and restoring power,
> it was discovered that over 200+ Q's were lost from the log.... and
> everyone was blaming the application ( TRLog or CT, the problem is the
> same). Needless to say, it took the air out of the balloons of the ops
> running the station. So much so, they wanted to pack things up and go
> home... so, i did some sniffing around, and after 30 seconds of looking at
> the configuration of the PC, i came to find that they were running SMARTDRV
> with a huge cache.... so, in this case, 200 Q's were being queued to write
> onto the physical media, but were in RAM instead of being flushed to disk.
>
> Finding this completely explained the lost data to me. In fact, after i
> explained what i found, the ops still didnt believe me, they still blamed
> that &^)*(*%#@#$ logging application.
>
> So i performed a simple demonstration of DUMBDRIVE for them to prove the
point.
>
> - i rebooted the pc with smartdrv installed, nice big cache
> - started the logging software with a different logfile
> - entered a dozen bogus calls in the log
> - turned off the power switch on the PC while everything was still running.
>
> sure enough, the logfile was empty, we lost em all !! ... i reconfigured
> the PC again this time without SMARTDRV installed ( nor any other sort of
> Atomic Powered Swiss Army Knives ) , and did the exact same sequence, and
> sure enough, all the Q's appeared in the logfile after power was removed.
> This encouraged them enough to continue on instead of packing it up from
> disgust. Of course if u have a power failure in the 500ms that the disk is
> actually being written to, you are toast as well, but that is a different
> problem. We did run out of gas again later in the early morning hours ( our
> jenny man fell asleep at da wheel ), without ANY problem.
>
> YMMV, but if you are not running on a laptop which has some kind of backup
> for a power failure, you will be in trouble if you get a power hit running
> any kind of disk caching that is not WRITE-THROUGH.... Using SMARTDRV for
> read-ahead caching ONLY is much less risky, yet provides much of the
> benefit one desires.
>
> Without SMARTDRV installed you will be affected by the floppy write delays,
> but at least you know WHEN the delay occurs, not when the caching software
> wants it to. The time required to write a quantum of data to the disk is
> the same (assuming no coalescing of sectors), and when it goes to the
> floppy you are going to have wait anyways, and it may happen at a much less
> desirable time.
>
> IMHO, SMARTDRV should be called DUMBDRIVE if you are unaware of these
> consequences. In most cases, I cant recommend it unless you make
> considerations for these limitations. Be VERY careful using it if your log
> integrity is important to you.
>
> Moreover, a very potent logging application will get blamed for the fault
> by the uninitiated. It risks the product integrity this OUTSTANDING logging
> program if using it in this way is endorsed by the manuals.
>
> Shields up Scotty :-)
> - bob, w9zv
>
>
>
> --
> FAQ on WWW: http://www.contesting.com/trlogfaq.html
> Submissions: trlog@contesting.com
> Administrative requests: trlog-REQUEST@contesting.com
> Problems: owner-trlog@contesting.com
> Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
>
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|