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

[Laurent HAAS - F6FVY]

Hi Mario

Tnx for your email.

Mario Lorenz a écrit :

> - 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.

We have to think abt that, even it is not so obvious.

> (Imagine this was a single-station contest - all
>   would be lost now...)

A single station should *always* use the integrated backup function on a 
different media. What if your HDD breaks on Sunday @ 2355z ? ;-)  It 
sometimes happens...

> - 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).

Actually, loading an "old" log while joining the network is the most 
dangerous thing, because sync starts immediatly and all logs become 
corrupted ! We already circumvent the name problem.

-- Further comments are on my own --
-- I can't speak for Olivier who is the lead dvper of WT, and the sync 
feature coder --

> 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 ?)

Not very easy to manage (because it needs the user to set such things 
and you know that in such a configuration (HQ team), some teams are not 
very aware - to say the least - of these things). But, of course, it is 
a good way to reduce traffic. There are also other ideas around (read 
proxies).

> 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)

We deliberately choosed un-acked broadcasted frames to ease networking 
for non-geeks with no central server. It also requires much less 
resources. And it also allows "third-party" softwares to easily join the 
party (we are even freely providing a DLL to be included in various 
language projects). IMHO this architecture is totally acceptable in a 
contest station LAN. The sync feature (to be improved - I totally 
agree), prevents "QSO loss", which is the most annoying, especially when 
the LAN is not "solid rock" (read WiFi, HF-disturbed, etc.) !

> 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.

I'm not very convinced that status frames are a big waste of BW, but we 
can think abt such an option. In all cases, I'm a pretty skeptical on 
the ability to pass WT traffic on such very low BW links.

>>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 should find them in the release file. Well, I think so ;-)

> 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)

Don't worry, it also happened @ TM0HQ, even if we had several testing 
evening sessions during the previous week of the contest.

> CLEARLOGNOW also seems to be, uh, quite dangerous ?

It is *VERY* dangerous ! But it is the only way to be sure the log is 
cleared before starting the contest ! You can also use the CLEARLOG 
command, but it requires the user to acknowledge... If you want to 
remotely clear all logs, it is not very practical.

> 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.

We will check that. Tnx for report.

> 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.

Noted.

Many tnx for your very complete report and suggestions.

We thought that we could break off after WRTC and IARU, but it seems we 
will have to wait a bit more to rest ;-)

73

Larry - F6FVY