[WT-support] DA0HQ and Win-Test 3.0.6-hq

[Mario Lorenz]

Hi Laurent,


Am 11. Jul 2006, um 20:21:57 schrieb Laurent HAAS - F6FVY:
> Hi Chris
> 
> Nice to hear from you.

Ah well, originally it was planned to do an internal evaluation of
the WinTest experiment first, but since Chris has already commented:

The grand summary (from what I know so far) is, that there were no
critical problems but a few interesting ones.

To what Christian already wrote, I would like to add:

- I am aware of two hard crashes (full computer lookups/blue screen),
  (therefore, I cannot cannot reasonably blame on WinTest), but
  in one of these cases, WinTest would not load the logfile again,
  complaining about containing a QSO in a wrong band. While the file
  was most likely corrupted by the operating system, this is something
  to worry after the contest is over (eg. when doing the log exports etc.)
  That QSO simply ought to be ignored, in any case the Contest should
  have been loaded. (Imagine this was a single-station contest - all
  would be lost now...)

- I "fixed" this by having the computer start a new log.
  As already stated, we had LogSync disabled. In a mail last week on
  this list you warned about bad things happening if a station with
  the same name joins the network with a new log. These bad things
  ought to be prevented. (Suggestion: for each log and each station,
  generate a GUID as unique identifier). 
  
> >3) DA0HQ had an impressive network of 30 or so stations altogether.
> >Unfortunately after an hour into the contest We had to disable the
> >sync feature because traffic/CPU usage got too high on the server.
> 
> Yep. We also got some problems @ TM0HQ. It finally worked so-so with 
> some work on the network (several bridged servers), but it has to be 
> optimized in such a configuration (many stns, several thousands of Q, 
> and limited bandwidth).

Being the DA0HQ network admin, I would like to comment further on this
issue. It is understood that the IARU HF championship is about the only
contest where this matters, but it still needs to be addressed.

a) The log sync traffic on the local network needs to be filtered by the
Tunnel client. Currently, a new computer is turned on on a local LAN,
the log sync traffic that occurs on the local LAN is broadcast to all
stations via the tunnel server, maxing out all available uplink
bandwith, and overrunning the transmit buffers on the tunnel servers.
(this is what the OE team reported two weeks ago, and on the old server
would cause dropping the connection; now it only causes massive data
loss on the network. One designated station could be allowed to sync
via the tunnel (and since all other stations would sync to that station
on the lan, this should be sufficient ?)


b) This data loss did not only happen to the log data, but also to
important traffic (GAB, Multi passing etc). Whats worse, the fact that
such traffic had been lost was not immediately obvious to the sending
station, leading to misunderstandings. In one case, I have witnessed
such data loss even on the local LAN. I wonder if an acknowledgement
for such traffic should be added to the network protocol (a warning
message would pop up on the sender if the recipient station would not
acknowledge within a certain time frame)



c) Even with logsync turned off, the traffic is too verbose. In
particular, I believe the Tunnel client should cut down on the status
messages by forwarding only one per minute or one per two minutes per
station or so, in order to allow low-bandwith (read: packet radio)
links.


> >4) Somehow we managed to start the tunnel application twice which
> >lead to kind of looping problems. After loosing the internet connection 
> >we closed the tunnel. wtTunnel.exe didn't show an icon in the taskbar 
> >but still was running in the task manager. Not being aware of that fact 
> >we started the tunnel again and had the tunnel running two times. We 
> >suggest you modify that application to be aware of another instance of 
> >the program running, probably by using a fixed port for the outgoing 
> >connection. When that port is already in use, a new instance of 
> >wttunnel.exe  cannot bind to it and will fail to start up properly.
> 
> I guess you're speaking abt WtTunnel *client* ? Did you use the version 
> 1.5 ??? Suggestion noted.

Yeah, diagnosing that during the contest was fun. I patched the server
to do more detailed logging, including the source port, after
determining that the server having to be restarted mid-contest was
probably the lesser evil.

I do however slightly disagree with Chris' suggestion about using a fixed
port. That port would have to be user-defineable, to allow legitimate
configurations involving two tunnel clients on the same PC. Perhaps,
loop detection could be implemented on the server.

> >7) We had the problem that calls where logged before the contest. In the
> >big network it wasn't possible to get rid of them when contest started.
> 
> You had to :
> 
> - Disable sync on all machines (you could use a remote command NOSYNC).
> - Clear all logs (Edit / Clear all Qso...) on all machines (you can also 
> use a CLEARLOGNOW remote command)
> - Re-enable sync on all machines (you could use a remote command SYNC).

AAARGH. And where, pray tell, were these commands documented ?
You know, when I noticed the server problems, it still took me quite a
to call up all our stations and make sure that sync was really
turned off, on all computers... (that the menu setting is inversed, ie, the
tick is visible when logsync is _disabled_, didnt help communications
either)

CLEARLOGNOW also seems to be, uh, quite dangerous ?

And this leads me to my last (minor) observation:

The "automatic backup" dialog is slightly broken.
Going to that dialog, then enabling automatic backup,
seting a time, of say 15 minutes, and _then_ selecting
the destination directory will set the backup interval
to 0 and disable the backup, so it has to be enabled again.

Also, would you please consider adding another checkbox "Add timestamp",
so that the backup file will be named with the name and the time of the
backup being made ? Space is cheap on network drives, and having
multiple backups could provide helpful in case of disaster recovery.

-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
"Your mouse has moved. Windows NT must be restarted
 for the change to take effect. Reboot now ?   [ OK ]"