>
>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
|