[wt4hq] Win-Test at HQ Stations

[Laurent HAAS - F6FVY]

Hi John

John Warburton G4IRN a écrit :

> Now that the IARU contest is finished for another year (thanks everyone 
> for the QSO's with GB7HQ) I wanted, please, to make a request for next year.

Glad to know you finally made it. BTW, where is your claimed score ? ;-)

> _Larry/Oliver - do you intend to improve the tunnel/server technology 
> for next year? GB7HQ would really like to use WT but at the moment, we 
> don't feel in a position to do so. I am sure that other HQ stations 
> would like to use it over the WAN also._

[[ Disclaimer ]]

Olivier being a bit "off" for personal reasons these days, the opinions 
expressed below are mine...

> We did extensive testing early this year with WT over Hamachi VPN and 
> with the WT server/tunnel software; our testing gave the following results:
>  
> 
>    1. WT works well as stand-alone software and on a LAN with many PCs,
>       however the WtTunnel and WtTunnelServer do not work reliably or
>       predictably enough in their existing forms for WT to be used with
>       the wide area network.

As the protocol is absolutely the same (more on this later), the 
reliability is not related to the LAN *or* the WAN topology. It is only 
related to the network bandwidth and stability, in a large sense of this 
term.

It means that, even in a LAN, you could have faced the same issues you 
had in a WAN.

In a ideal world with, say, a 100 Mbps _WAN_ access for every computer, 
and a VPN solution, Win-Test would act the same as in a 100 Mbps LAN.

>    2. The existing WT server uses a ‘broadcast’ technique, with no
>       attempt to ascertain whether every PC on the WAN has received each
>       broadcast correctly (one of the issues of UDP!)

Absolutely. We are totally conscious of that. I might even add that it 
has been designed like this for several technical reasons. You have to 
deal with it (or not). And I'm afraid you will still have to deal with 
it (or not) in the near future.

>    3. There are random ‘timeouts’ when connected stations disappear for
>       a few seconds or minutes from the WT ‘status’ (Alt/J) window.

Bandwidth and disconnections issues. More on this later.

>    4. In the event of a PC disconnection, log updating/synchronising is
>       relatively slow (100 QSOs/min via VPN, 400 QSOs/min via WtTunnel)
>       – this could be a major problem late-on during the contest.

On more time, if your network is not reliable at all (being LAN or WAN), 
Win-Test does its best. Sync is done in background, to not "kill" the 
network with massive data transfer. It is the drawback of the advantage, 
if you see what I mean. If you know that your network will fail 
regularly, whether improve it, whether consider another option (no sync 
for ex.).

>    5. Remotely-issued logfile emptying commands (as will be needed at
>       the start of the contest) were not received consistently by all
>       PCs on a 7-PC WAN.

See 2/

On the other hand, WT displays in the gab wnd on which stations the 
command were executed. It is the "IT master" responsibility to ensure 
everything is clear before starting (more on this later).

>    6. VPN technology gave more robust peer to peer connections (as
>       indicated by Alt-J)

Maybe, but it uses more bandwidth and requires more knowledge to set it 
up (more on this later).

>    7. Non-transactional – messages can be lost

See 2/

>    8. De-centralised (peer to peer), as opposed to serialised through a
>       central server

It is not a bug. It is a feature ;-)  It is the way we chosed to ease 
network deployment and "management".

> After the contest, I sent emails to nine HQ stations that were using WT, 
> to find out if the WTserver/tunnel worked OK.

(snip)

Here is our experience at TM0HQ this year :

FYI, I maybe only worked 10 QSO in this edition (!), and rather 
concentrated on the network and various other occupations during the 
full 24 hours...

We had around 30 machines, spread in 12 LANs, on 9 different sites.

The weakest network links were 3G links (two of them). The other were 
plain-ADSL links.

1/ Despite of WtTunnelSvr issues (more on this later), we are 
considering the network never worked so well, EVEN if it is NOT perfect, 
I totally admit it.

2/ After gathering all logs and merging them, it appears that the vast 
majority of them were totally identical. One more time, it is *not* 
perfect, but it is (IMHO) very acceptable.

BUT, to achieve this result, we had to :

1/ Having an IT person responsible on _every_ site. I mean, a computer 
literate ham who *knows* how a network is working, how Win-Test is 
working, how the Tunnel is working, etc. It was a prerequisite for the 
site to be accepted in the TM0HQ team.

2/ No low bandwidth link. No 9600 bauds packet stuff, no 56k link etc. 
One more prerequisite for the site to be accepted in the TM0HQ team.

3/ One person responsible to maintain a live WtTunnelSrv. By all means.

4/ A VERY detailed timed-checklist to follow before the contest starts 
(log cleaning procedures, bridgehead settings etc.). And I ensured ALL 
sites were ready before starting.

5/ A WtTunnelSrv sandbox has been setup for one COMPLETE week to train 
involved people who were not using Win-Test so often.

To make a long story short, setting up a Win-Test WAN for an HQ station 
requires knowledge and organization. It is definitely *not* similar as 
setting up a LAN with 3 PCs in the same room for a casual contest 10 
minutes before it starts. If you think so, you're in big trouble.

The _ONLY_ big problem we faced was the behavior of WtTunnelSrv... It 
sometimes went into a much resource consuming state (a sort of endless 
loop), and we had to setup an automatic script to monitor its state, 
kill and restart it if needed. Thanks to Mario (DL5MLO @ DA0HQ), I think 
we finally solved the WtTunnel (client) and WtDxTelnet memory leaks we 
had last years. But the WtTunnelSrv still needs some work...

Another solution was to use a conventional VPN solution like Hamaichi, 
but it also has other drawbacks :

1/ It consumes more bandwidth as there is no "bridgehead" involved. It 
means that if you have 30 PCs, they all are equal.

2/ It also means (for the same reason) that -ideally- one WtDxTelnet 
only must be running on the VPN. It also consumes bandwidth. Which is 
not the case with the WtTunnel suite.

3/ It is (IMHO) more difficult to setup.

So, now, what next ?

1/ I think I found a way to decrease a bit the required bandwidth for 
sync. It requires to modify the bridgehead concept. I intend to work on 
it in the coming weeks.

2/ We hope to seriously debug someday the WtTunnelSvr to prevent (or 
limit) the "endless loops" we had. But, I'm afraid it will require to 
setup a test bench I can't afford now.

3/ There are no plan today to modify the protocol nature (broadcast). 
The WAN usage of Win-Test is only an extension to the usual usage of 
Win-Test. When we wrote the WtTunnel suite for that in 2005 
(http://www.f5mzn.org/pipermail/support/2005-June/069981.html), we 
thought it was interesting to share it with the other users of Win-Test. 
This is also the reason why we decided to make them free and public, and 
having a free limited edition of Win-Test for HQ teams.

> Having spoken personally to Larry, I kind of get the feeling that the 
> server/tunnel software is low on the priority, but think guys - if more 
> HQ stations could speak highly of WT then that would generate more money 
> for FY5KE !

Sure, but having more money is not our major aim. Before, having 10 WT 
users in the top ten boxes of contests *is* our major aim...

> Yours, hoping that GB7HQ might be able to use WT one day...

BTW, where is your claimed score ? ;-)

73

Larry - F6FVY