[TRLog] SMARTDRV - not too smart

[rpb]

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