N9FH replied to Tree:
> > > I ran 6.85 for my first 300 or so qso's and the bandmap / 2nd radio /
> > packet
> > > stuff seemed to work perfectly. Unfortunately, I had another issue that
> > > nobody else has mentioned yet. I started seeing a significant delay
> > when
> > > logging a qso. At first it seemed normal but after a couple of hundred
> > q's
> > > it was a show stopper. I estimate it was around an 800msec delay when I
> > > swapped in 679 to finish up and seemed to get longer as the log size
> > grew.
> > > It would send the TU message and then hang there with the last guy's
> > call in
> > > the window. For a while I could just type the next caller (without the
> > > display changing) and it would let loose with CW after the pause but the
> > > time delay made it just about impossible to run. Of course, 679 was as
> > > responsive as ever...
> >
> > Interesting. I am not sure I have any explanation for this.
> >
> > Are you using a disk cache like smartdrv?
> >
> > Tree
>
>I was at first but eliminated it when I switched to 6.79. I'm out of town
>for another week or so but I plan to see if I can sort it out some time
>before CQWW. Probably read in some logs with and without the disk cache and
>compare 679 to 685. Will report back when I have time for a more systematic
>approach.
I think I have seen the same delay - working some
EUs yesterday, I was sending RSTs by hand & then
^-entering the Q, then going back up into edit
window to correct RST sent. There would be a
substantial delay between ^-enter & when call &
exchange windows would clear (data from last Q
would display during delay) & then let me move
cursor up into editable log.
DOS 6.22, QEMM, no caching.
73, VR2BrettGraham
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|