[TowerTalk] RE: [TRLog] SMARTDRV - not too smart

[rpb]

<<SNIP>>
 >I remember at FS5PL, I'd have three people typed in the log before
 >the first one showed up on the screen

Hi Chad,
jeez, i'd love to be in this gawdawful terrible situation just once  :-)  ....

<<SNIP>>
 >With your lost QSO's disclaimer out of the way, I'd maybe
 >rather lose 100 Q's than to suffer the excruciating slowness
 >encountered when you have a large log.

well, im happy to say that i had nothing to do with the logging PC's our 
club used for FD. If I had, this configuration with DUMBDRIVE that they had 
which caused the loss of 200+ Q's would not have occurred.  I think the ops 
were just unaware of the risks and that it was even configured and running 
with disk caching enabled. Not a happy thing to have happen in FD where 200 
Q's might represent a large proportion of the log for that band.

and, as above, again, i'd love to be in the situation having so many 
callers in the log that i can throw away 200 of em... someday i will try 
the other end of the stick... and when i do, i will probably have 
SMARTDRIVE enabled in some fashion or another when the log gets thick, but 
i will ALSO have a UPS or a charged laptop battery to ensure i wont have a 
problem when the mains go down...
As u know, having reliable AC power in other places of the globe (or at 
field day) is not like what we have gotten used to here in the states.

<<SNIP>>
 >At 02:07 PM 9/17/99 -0500, you wrote:
 >Somewhere over 1000 Q's in the log, things really slow down without
 >it.  At the 5000+ point, it's insane.  At 10,000 Q's, you wish you
 >were using a different program, but with SMARTDRV, you still get
 >to love TR.

yes,. given your example, i would agree.  However, I was addressing the 
masses of users whom are NOT in the 5K QSO end of the contesting spectrum, 
and whom are not ( and dont want to have 2 be ) computer geeks.... they 
just want reliable operation with minimum risk.

the original post suggested that one blindly cache all drives, and to place 
this recommendation in BOLD print in the manuals.  The point i was trying 
to make was that this should NOT be recommended in the manual as a 
"default" or "normal" operational mode, unless you know and fully 
understand the risks in doing so.  Doing otherwise will ensure Tree is 
spending all his valuable time answering queries about lost/corrupted logs 
( which will have nothing to do with his software ) instead of spending 
time on adding new features and supporting TRLog to the level that we have 
been accustomed to. Again, on a laptop which has a charged battery, or a 
box with a UPS on it, it's a non-issue, since an AC power outage will not 
affect your log, even when running SMARTDRIVE.

i would submit that only small subset of TRLog users are commonly running 
over 1-2K Q's in the log.  Those that are in this category are serious 
enough that they should already understand this issue and have configured 
their environment according to the level of risk they are willing to live with.

but to those whom aren't,  caveat emptor......

i still maintain that.... until one gets smart about it, consider it 
DUMBDRIVE, and...

DANGER WILL ROBINSON, DANGER !!!!  imagine flailing robot arms....

is a reasonable position to take until one fully understands the risks...   :-)

-bob








--
FAQ on WWW:               http://www.contesting.com/towertalkfaq.html
Submissions:              towertalk@contesting.com
Administrative requests:  towertalk-REQUEST@contesting.com
Problems:                 owner-towertalk@contesting.com
Search:                   http://www.contesting.com/km9p/search.htm