Hi Gary,
Thanks for the reply. See below.
On Tue, 29 Oct 2002 04:06:09 -0500 W2CS@bellsouth.net wrote:
> 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.
We rebooted into dos mode.
>
> 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.
We ended up trying that, but often the time reset would not
take place on the run station (yes, we were answering "yes"
to the reset network at the end of the process.) Even so, it
was a real pain.
>
> >
> > 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.
No, I did not have SMARTDRV set up, because we were trying to use
DVPTSR with a ramdrive, but ended up abandoning it, trying to deal
with the clock problem above, which made things better, but did not
solve the problem. I will use SMARTDRV in the next configuration,
for cw, but do you know if SMARTDRV can be used with DVPTSR, and if
so, how?
> >
> > 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...
This is good to know, I will pass it on to those concerned.
> 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.
Great advice, I will do that.
> 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.
Personally, I don't run windows on my contesting computers, but at
the station in question, one of them must, in one form or another.
We don't have an internet connection, but for my own information,
would appreciate a copy of the Wintelnetx for TR paper.
>
> 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 again, very much for the assistance.
cheers, Paul - VA7NT ex VE7CQK - email: paule@sfu.ca
"Those who hear not the music. . . think the dancers mad."
|