Since the comment about the network came from one of the ops
at our effort (W4WA), I'll explain what was happening. I think
Tree has figured it out.
As a competitive M/S operation, we were doing a lot of 2-radio
operation with two computers and a lockout box to keep it all legal.
Numerous times during the contest we had this situation:
Stn. 1 gives out number 1500 (say) and waits for the return exchange
Stn. 2 gives out number 1501 while Stn. 1 listens
Stn. 1 gets return exchange and hits return. However, the QSO doesn't
make it to Stn. 2
So, Stn. 2 can't hit return because the number hasn't bumped up to
1501 yet. Stn. 1 says QRZ and a stn comes back. But, stn 1 can't
log it until stn 2 gets the first message which died and hits return,
bumping the stn 1 counter up to 1502.
So, the whole effort comes to a halt. Two guys sitting with QSOs
on the screen who can't hit return until this message makes it across
the network. And, we're waiting for a 30sec. Timer to expire.
As you know, it's very frustrating in a contest to have to stop working people
and wait on your computer.
Certainly it's possible or probable that RF was causing our problems. We
had no other noticeable RF problems, but it seemed to be correlated with
transmitting on one of the radios. In this case, though, I think a software
solution is more appropriate than everyone in the world trying to make their
networks bullet-proof from a hardware standpoint.
Suggestions:
1. The timer is basically a worst-case round-trip propagation delay, I think.
This would clearly be dependent on the number of stations in the network.
Why not allow that to be input and multiply that by a per-station time constant.
If that delay had been reduced to 5 or 10 sec., it probably would have been
barely noticeable. Tree also suggested this. If the network could
automatically
calculate the number of stations, that would be neat. How about each station
picking a random number. Pass that around the network, along with a hop
counter. When it gets back to you, use the hop counter as your station number.
One question, though is when to do this, i.e. when the program is started?
Every
10 minutes, what?
2. Each computer should generate a unique number, like a station number.
This could be a random number if you don't trust the users to set the station
number uniquely on each computer. Or, use another way (see above) to assign
each station a number. Embed this number within each message and a message
ID. When a station receives a message with its own originating ID, it removes
the
message number from the transmit queue and doesn't retransmit the message.
This way, the message retransmit could be set very short.
The problem with the original setup was that if a retransmitted message was
received
after the original was received and the message deleted from the queue, the
retransmit
wasn't recognized as such and it was relayed. The station ID could get rid of
this.
I'll keep thinking about this. The network is very close. If it weren't for
serial
numbers, it would have been perfect. At the end of the contest, the two
computers
had exactly the same numbers of Q's and the same scores. Try that with any
other program.
73 Jeff N9HZQ (op at W4WA SS SSB)
--
Jeff Tucker, N9HZQ
Williams Consulting, Inc.
jefft@atlanta.com
|