On Mon, Nov 03, 2003 at 10:45:40PM -0800, Michael Tope wrote:
> Anyone have trouble with Trlog's dupe checking function in
> SS. At W6UE we had two PC's connected in a multiport
> network for SS. On Sunday afternoon on one of the two
> computers (the IBM Aptiva) stopped finding dupes as if the
> program lost its internal dupesheet. Mike, KA6SAR first
> noticed it when he started getting "QSO B4" replies from
> all of the callsigns on the bandmap that appeared to be
> "fresh meat" (e.g. no asterisks in front of the callsign). As
> soon as he realized what was going on (and mumbling
> something about using CT instead of TRlog), he started
> using alt-L (log search) to dupe calls, and sure enough it
> became clear that the program wasn't duping properly.
> The other computer in our two computer multi-port network
> (our Dell P-133) was still tracking dupes just fine.
Any idea what the free memory display was showing on that
computer? I haven't seen this problem before.
> I don't know if it was a coincidence, but the IBM Aptiva
> with the duping problem also seemed to be having
> trouble handling all the activity on the multi-port. At times
> the keyboard latency got so bad that it was almost
> impossible to edit in the exchange window (at these
> times it would take a few seconds between a key press
> and the corresponding call/exchange window update).
> This PC was getting its packet feeds over the multi-port
> from the other logging computer which was in-turn
> connected to our Telnet computer using the Trlog
> packet port function.
The network really shouldn't have anything to do with keyboard
latency. This is probably more related to not using a disk
cache and the longer write times to the disk as the log grew.
Tree
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|