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