Hi Gary, et. al.,
A couple of comments on this thread (a good one, by the way):
My documentation for networking on the K9JY site is now a year and a half
old. Wayne has made some significant improvements in the networking
capabilities that should be reflected there. The term 'server' is probably
not a good one; I'll have to think of a different one that more accurately
reflects peer-to-peer networking. There are two salient points for the term:
1. All PC's on the network should connect to one PC for their network
connection. For example, at multi-op K4JA's where I contest a lot, all
four/five PC's connect to the 40 meter station PC even though the 40 meter
station is logging 40 meter QSO's. The recovery aspect of this has been well
explained in other emails; for us, it was always astounding to find that all
the logs matched in QSO's and score after the contest was over as compared
to that other program we used previously. However, you don't need a separate
PC all by itself as a true IT server to do this. Very few stations do.
2. All PC's need to start with the same clean, empty log in the same format
(although Wayne has improved the tolerance of this). So on one PC someplace
(or more on a DXpedition), you should have a clean, empty log that all the
other PC's open and then 'Save As' on their local machine. There is a
two-fold purpose in this: all PC's start with the same log format making
networking seamless, and, if a log file is not recoverable on a local
machine midway in a contest, there is always a clean, empty copy - not in
use by another operator so you don't have to shut an operating station down
to get the file!! - that you can go to in order to have it on your local
machine. Once up and running, this clean, empty log will then synchronize
with all the other logs. This is an outstanding feature capability for
disaster recovery. (Hint: DXpeditions...)
For those who commented on whether W/L was OK in a 10-12 station multi-op
environment or a DXpedition, I'd make three comments. First, networking and
recovery are simple and outstanding. The tricks in the networking are all
Windows related, and, with the newer operating systems, most closely related
to insuring that the same user name and password exist on each machine.
Second, WriteLog is built to network calls at 25,000 per HOUR. I have
personally tested, with automated software, to 19,000 log entries an hour;
the limitation I had was a Pentium II 233 MHz machine. I'd love to have that
rate in a contest.
Third, the ability to have another 'management' station, with packet views,
multiple band maps open on the same PC with the band map spots showing on
the station (10.36 and higher), and rates running, give a station manager a
very clear picture of what is happening in the contest across all the bands.
It's really nice to see the snapshot.
Are there other things to be done? Yup. It's just interesting to me that
we're hitting up for features on PC's, networks, disaster recovery,
automated recovery processes, electronic filing and multiple packet network
interfaces for what we do. Think about how sophisticated this program is for
a hobby! My first serious M/M used pencils and huge paper dupe sheets with
no packet and no rig control. Change is good...
CU...Scot
See K9JY's WriteLog User Support Site at:
http://www.k9jy.com
mailto:scot@k9jy.com
-----Original Message-----
From: writelog-admin@contesting.com
[mailto:writelog-admin@contesting.com]On Behalf Of Gary Ferdinand W2CS
Sent: Wednesday, November 27, 2002 10:37 AM
To: writelog@contesting.com
Subject: [WriteLog] WL in a M/M Station
Dear WLers,
I'm doing some investigation of various loggers that support a M/M
configuration. I've only used WL in a limited way so far, single op in SS,
and I'm very impressed. But I've thoroughly perused the excellent
documentation available as it pertains to M/M operations and it raises a few
questions.
1. The existence of a WL server. I presume this is a requirement when
running M/M?
2. Recovery after restart. I am intrigued and pleased by the WL design
that appears to (re)populate the local log when a position is (re)started.
I believe the implication of this is that every position sees all QSOs/Mults
even if one or more positions had to be restarted during the contest. True?
3. Recovery of the WL server. Can someone please fill me in on how/if the
server can be restarted and recovered? I did not see any details on this.
For example, if the server dies and needs to be restarted (let's say a
simple Windoze hang, no hardware breakage)... Meanwhile the positions
continue to be able to operate? When the WL server is back up, does it
resynch with the local positions like they can resynch with it after they
die? I'd appreciate a complete, clear explanation of this scenario. If
I've missed it in the doc, just stick my nose in it ;-)
4. When a local WL dies and gets restarted, does it come up with the band
map it had when it died, a clean band map, or a band map that has been
updated with the events that occurred on the other positions during its
restart?
5. At any given local position can local rate and aggregate rate be
displayed? Or is it just one or the other?
6. Can anyone relate operating a M/M or M/2 using WL to doing the same
thing with another logger such as TRLog or CT?
7. Is the Ethernet any more/less susceptible to RFI than alternative such
as a serial port daisy chain?
8. I see port choices of only COM1-4. My system has COM5 and COM6
configured. Can WL access these COM ports somehow?
Thanks and Happy Thanksgiving to all.
73,
Gary W2CS
Apex, NC
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
|