[wt4hq] Win-Test at HQ Stations

[John Warburton G4IRN]

<<Uh, John, perhaps the strongest point in favour of Win-Test would be
the fact that the team using the allegedly superior log sync technology
called "StarLog" still hasnt claimed scores :)>>

I know, I know!! I've been carefully avoiding the question so far!

To be honest, I did see our score at the end of the contest but I have 
forgotten what it was. We have a special department within the team that is 
responsible for announcing the claimed score - I am not part of that 
department!

John, G4IRN.




--------------------------------------------------
From: "Mario Lorenz" <ml at vdazone.org>
Sent: Saturday, August 02, 2008 2:03 PM
To: <wt4hq at win-test.com>
Subject: Re: [wt4hq] Win-Test at HQ Stations

> Am 02. Aug 2008, um 13:20:48 schrieb John Warburton G4IRN:
>
>> Fortunately, all our stations have broadband internet access, so slow 
>> data
>> comms isn't really a problem.
>
> "slow" is such a relative term. Logsync on, on the local LAN, in
> situations where many stations have slightly different logs (hence the
> synchronisation is "complicated" can easily generate significant
> ammounts of bandwith. Even with the "learning bridge" filtering
> introduced to server and client last year. I would see Megabits of
> Uplink traffic from Ilmenau to the central server, so even DSL hits the
> limit.
> Flow control in a non-homogenous network is a difficult problem; even TCP
> took several attempts to get it right.
> It has also been said that the only worm/virus that really could bring
> the internet down would do so by modifying the TCP Flow control / 
> Retransmit
> timers of the operating systems.
>
>> To be honest, I was hoping that the whole WT server/tunnel issue might be
>> re-thought and redeveloped. I realise that the broadcast style networking
>> isn't going to disappear, but maybe there are better ways of dealing with 
>> it
>> from a central server perspective?
>
> I am lacking the knowledge of the network protocol (reading the traces
> only gets you so far...) but my suggestion -- with least impact to the
> general protocol -- mind you, HQ is the only contest I know of that
> allows multi site operation -- is to modify the tunnel client and
> implement configurable filters *there*, where you can filter on a
> per-station-name basis. This would allow to configure all stations to
> a LOGSYNC-ON-LAN-ONLY mode (on the assumption that bandwith is cheap),
> with one station per site logsyncing with only a configured ammount of
> WAN peers. You could even go as far as having a win-test computer at the
> tunnel server, and thus emulate a single-server sync model.
>
> Please note that all the logsync business is only required if you have
> outages on the WAN links. You will have most of the log data from the
> regular ADDQSO broadcasts.
> I have been debating on wheter the Tunnel clients should also reduce the
> ammount of status messages sent over the WAN, and the other tunnel
> clients would reproduce the missing status messages --- on a non-logsync
> WAN, the status messages are the significant factor.
>
>>
>> Any way, thanks again for your efforts at Win-Test HQ, the post-contest
>> discussion has been interesting.
>>
> Uh, John, perhaps the strongest point in favour of Win-Test would be
> the fact that the team using the allegedly superior log sync technology
> called "StarLog" still hasnt claimed scores :)
>
> Ducking & Running
>
> Mario
> -- 
> Mario Lorenz                            Internet:    <ml at vdazone.org>
>                                        Ham Radio: 
> DL5MLO at DB0ERF.#THR.DEU.EU
> Trust the computer industry to shorten "Year 2000" to Y2K.  It was this 
> kind
> of thinking that caused the problem in the first place.
> _______________________________________________
> Wt4hq mailing list
> Wt4hq at win-test.com
> http://www.f5mzn.org/cgi-bin/mailman/listinfo/wt4hq
>