[wt4hq] Win-Test at HQ Stations

[Milan Pelech]

Larry wrote:
--------------
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.
--- end of previous text ---

Absolutely agree Larry. Big congrats to your fine WT network functionality. 
There is my idea from another HQ team:

OL4HQ team didnt use WT internet logging mechanism by WtTunnel or any next 
VPN this year. I used WT only like postcontest software for final logsync 
from cabrillo logs. I am sorry, but poor experience last 2 years said me 
DONT try again the same way. Why ?

1) I dont think, that contest software released 3 days before contest and 
used only for this one contest in a year, could be the better solution than 
any logger used every day. (I mean WT-HQ version for those HQ team members 
who normaly dont use WT and troubles generated from workplaces where was 
used this solution) Where is your time for train involved members ? Yes, 
they could train in old software version, but who knows how many differences 
and bugs will be in lastest version ? Its really big problem release WT-HQ 
earlier ?

2) I dont have lot of IT specialist for WT network maintainance during 
contest. I think IARU HFC isnt IT specialist competition. We are mainly 
ham-radio contesters and this is our main limitation of WT usage in big 
network like HQ activities.

3) Each of us dont have acceptable internet connection. Its the fact. In the 
past were some GPRS or CDMA connections having big troubles in WT network.

4) Understanding and flexibility from others in team. (problem with general 
WT platform acceptance etc.)

I must say big congrats again to you and your team, because setup big team, 
satisfy of WT advantages or only one software platform used in team, have 
complete WT network in operational state all time in contest and achieve 
super score like TM0HQ needs HARD job and understanding lot of people.

GL de Milan, OK1VWK





----- Original Message ----- 
From: "Laurent HAAS - F6FVY" <f6fvy at free.fr>
To: "John Warburton G4IRN" <qrz at dxdx.co.uk>; <wt4hq at win-test.com>
Sent: Thursday, July 31, 2008 2:59 PM
Subject: Re: [wt4hq] Win-Test at HQ Stations


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
_______________________________________________
Wt4hq mailing list
Wt4hq at win-test.com
http://www.f5mzn.org/cgi-bin/mailman/listinfo/wt4hq