[TRLog] Troubles in a MS environment during CQWW SSB

[Gary Ferdinand W2CS]

Paul,

See interspered comments.

<<SNIP>>
>
> 1. Computer losing time. Someone else mentioned losing a few seconds
> per hour, but we had one of ours losing about 5 minutes per hour...
> This ended up playing havoc with the logs... the two were different
> by over 100q's. The computer in question is a pentium I running Win 95,
> but running the program in dos mode.

Are you running TR in under Win95 in a DOS window or in DOS after rebooting
in DOS mode?  Some people succeed with the former, some do not.  If running
under windows, try instead running under a DOS reboot.  You might just try
booting DOS itself natively, either from a DOS partition on your HDD or from
a floppy.  Bring up the configuration and see if it helps.  See also #3
below.

Also, you can reset the clocks on any one of the computers and have the
reset broadcast to the others via the TR time command.  While you don't want
to be taking the time to do this on the run position, you can probably do it
on the mult position periodically to keep this from being too much of an
issue.

>
> 2. Also, the q numbers were all out of whack. I realize
> that in the end the numbers don't matter, except when one is trying to
> keep track of what happened during the contest by looking at the log...
> It would really help if the q # could be assigned just when the q is
> logged, rather than the way it currently is...

Yup.  Time is key, not Q#.

>
> 3. There was also a significant delay in the call window being cleared
> after the enter key is pressed to log the q, this is really annoying
> when the rates are up around 200/min.

Did you have SMARTDRV or equivalent properly specified?  #3 sounds
suspiciously like you had no disk cache enabled.  You need to have write
caching (in windows) enabled or SMARTDRV (in DOS) set to allow write caching
of your log drive.


>
> 4. Apparently in cw, if the start sending now key is pressed, and
> one backspaces to correct the end of the call before it is sent, the
> program sends the call as originally typed, not as corrected...
> while this is not a big issue for me, and my sending style, it is
> a really big issue for them, and I don't need any more reasons for
> them not to like the program...

This is not the way my TR has worked, for years!  If I'm starting to send
DF2AC and it's on the F and I backspace to correct the AC to an AD, it gets
sent as corrected as DF2AD. That's assuming my fingers are fast enough to
reenter before TR gets around to sending at that position.  I agree with
them that if I couldn't make such corrections, I would toss TR out the door
in an instant.  But TR is not the problem here...

Sounds like not enough CPU is being allocated to TR and/or that you're
running TR under windows.  Try DOS with SMARTDRV and I think some of your
issues will disappear. Sounds like you have something else competing for the
CPU and there are not enough horses left to get the updated callsign
reflected in the output buffer.  If you're running under windows and insist
on doing that, strip out EVERYTHING from your started programs list that is
not needed for the task at hand.

Basically, I suggest you start with simple native DOS+SMARTDRV first.  Get
all the TR settings set the way you like them.  Make it work.  Then, if you
insist, bring it up under Windows by itself.  No clock synch, no telnet
sessions, no handy statistics program running in the background, no SETI or
other CPU hog, etc etc.  Use msconfig to see exactly what's getting started
when you boot windows.

If you think you need windows to get access to internet DX spots and thus
need to run TR under windows for that reason...you can reconfigure to put
the telnet session on another computer, much like a standalone TNC and route
the spots to one of the computers in your DOS TR network.  I can dredge up a
small paper I wrote using Wintelnetx for TR if that's of interest and email
it to you.

You didn't specify the size of the computers you're using. I've been
assuming all along that raw CPU speed was not a problem. If you're on
Pentium class CPUs, it probably isn't.

73,

Gary W2CS







>
> Thanks in advance for the help.
> --
> cheers, Paul - VA7NT (ex VE7CQK) - email: paule@sfu.ca
>
> "Those who hear not the music, think the dancers mad..."
>
> _______________________________________________
> TRLog mailing list
> TRLog@contesting.com
> http://lists.contesting.com/mailman/listinfo/trlog
>