[Trlog] Problem with "slowness" in the CQ160 Contest

[Jim George]

Thanks to all for the suggestions. Most suggested I run SMARTDRV. Believe 
it or not, I was using DOS 5.0, which does not support either DEFRAG or 
SMARTDRV. My friend and wizard in a number of areas here, Jim, W5JAW, 
helped me find a nice new OEM version of DOS 6.22 and then installed it 
with me looking over his shoulder. The DEFRAG helped a little, however the 
SMARTDRV really did the job. It seems to me (unscientific) that when I 
moved from my standby TR 6.78 to TR 6.93, the program ran slower on my 
albatross PC. In any event, going to SMARTDRV did the trick and now my 66 
MHz IBM PC is running TR like a champ again. It had gotten so slow that it 
was taking 4 to 5 seconds to "process" a QSO and complete the logging. 
Obviously that was not going to work.

Thanks to several of you who suggested the SMARTDRV and to W5JAW who helped 
me switch over.

Jim N3BB


At 12:51 PM 1/25/2009 -0800, Tree wrote:
>On Sun, Jan 25, 2009 at 10:23:45AM -0600, Jim George wrote:
>
> > I had an unusual problem with the CQ160 contest with TR 6.92. It was
> > extremely slow. Granted, I run it on a prehistoric 486DX at 66 MHz, but
> > that's what I run all the TR programs on, so the slowness is unique to 
> this
> > contest. It took almost two seconds to "process" the QSO. It was not a
> > problem when I started as I was S&Ping and the wait didn't hold anything
> > up.But later, I started CQing, and the wait was so long that I was delayed
> > going back to the callers since the wait time to "digest" the last QSO was
> > almost two seconds. I could not continue. Is there anything unique about
> > this contest (such as sorting through a large number of potential
> > multipliers or whatever)??
> >
> > This is the first time I have run into this in many years of using TR.
>
>Sounds like no disk cache.
>
>Tree