Introduction

The DX cluster system has expanded rapidly since the Internet has become the main connection between cluster nodes. The cluster system was, at one time, just that - small 'clusters' of users connected locally and spots generated and seen were local spots. The system is now global in nature - the whole world is connected to the whole world. That concept is subject to constant discussion - some cluster users want to see only 'local' spots, i.e. what is being spotted in their part of the world. Other users are interested in seeing every spot - no matter where it originated. But the fact remains that most users are subject to what the connected node gives them or doesn't give them, regardless of available 'user filters' on some node software.

The node here in Guam is a 'dead end' node, running WinCluster software and is capable of connecting to only ONE other node. It does not support multiple node connections, so all spots received are from a single source at any given time.

In the process of watching the cluster system grow, I have noticed the related problems grow with it - duplicate spots, redundant spots, loops, use of full announcements as a CHAT server, etc. Although most commonly available cluster software packages allow USERS to set up filters it has been my observation, at least on my node, that users don't bother to use 'user filters'. I have always felt strongly that it should be up to the authors of cluster node software to provide a means to control the overflow, so to speak.

Statistics for the Guam node during CQWW SSB

During a contest, everybody wants lottsa spots. We got lottsa spots during CQWW SSB 2000. Usually the Guam node is connected to one other node ALL the time, KE9KD-2. Due to a few minor technical problems during CQWW SSB this year, the Guam node was connected to one node other than KE9KD-2 during the contest. Most, if not all, of the following that can be considered a 'problem' was observed when the Guam node was NOT connected to KE9KD-2, but was connected to the cluster system through a different (U.S.) node. The following numbers are for the 48 hour contest period only:

Total spots received: 27,017

That number translates to 563 spots per hour or 9.4 spots per minute or 1 spot every 6.4 seconds. Personally, I don't see how anyone can operate a radio, log contacts and pay attention to a new DX spot every 6.4 seconds, but somehow we manage.

Results noticed from total number of spots: All of my VHF (radio link) users were disconnected during the first 30 minutes of the contest, except for one. The one who managed to stay connected was 35 to 45 spots behind for the first few hours of the contest, until the point that he disappeared. Telnet users all stayed connected.

Conclusion: The Internet is faster than 1200 baud packet, and stays connected longer :-)

Bad spots received: A whole bunch. Way too many.

Before I give you any numbers, let me define what I think a 'bad' spot is. I filter bad spots, i.e., I don't send them to the connected users on my node. If my users generate bad spots, I don't send them to the other node. Since my node only has ONE other node connected to it, all the 'bad' spots came from the other node (except for the rare case of a redundant spot generated by a local user), so I don't forward 'bad' spots to any other node. Bad spots at my node fall into the following categories:

DUPES - These are spots caused by obvious LOOPS in the cluster system, i.e., the same (unmodified) spot is being sent around the world more than once.

Total DUPES: 0

That's the best number there is for total dupes. It wasn't always zero but because the operator of the node that I usually connect to has spent a lot of time and effort working on the problem, the LOOP/DUPE problem we used to have has been totally eliminated.

OLD SPOTS - These are spots that arrive with a timestamp (date/time) that is so far off from the current (real) UTC time that it is doubtful that they are legitimate spots. They could be an hour old, they could be a 24 hours old, they could be time stamped an hour or two into the future. It has been my observation that the majority of spots I catch that have bad time stamps are spots that somebody's software has MODIFIED in an attempt to recirculate the spot or give it a greater coverage area, and in this contest that was most certainly the case.

Total OLD spots: 5,186

That's bad. Matter of fact, that's REALLY bad. It's 20% of the total spots received. And the fact that makes it REALLY bad is that of the 5,186 OLD (bad time, an hour old mostly) spots that I received, 4,336 of them originated from the same (U.S.) node. And the other fact that makes it REALLY bad is that I was only connected to the node that was sending them to me for about one fourth of the contest - so if I had been connected to him the entire contest, I can estimate that I would have received about 16,000 OLD SPOTS. Bummer.

The rest of the OLD spots were generated by various nodes, one node I noticed generated about 200, the rest only a minor number.

As I said before, large numbers in this category are usually generated by someone who is MUTILATING spots and resending them. Small numbers are usually generated by nodes with the clock set wrong. I've seen a few nodes during contest with the clock one day off - and usually I was thanked by the owner after emailing them to make them aware of the problem.

Time TIP for Cluster Node Operators: If you are running a node connected to the Internet, there is absolutely no reason for your Windows clock to be off. Windows has a KNOWN PROBLEM with the clock. It reads the HARDWARE clock when it boots, but then it attempts to keep time with a SOFTWARE clocks which doesn't always work.... Go to the ANALOGX web site and download a small free program called ATOMIC TIME SYNC. Then go to the National Institute Of Standards web site and find an NTP time server near you. Configure ATOMIC TIME SYNC to set your clock every five or ten minutes, and let it run all the time. You'll never be a second off again.

REDUNDANT SPOTS - These are spots aren't really necessary. With the global nature of the cluster system, it is quite possible that 30 people on 30 different nodes will spot the SAME DX station on the SAME frequency within a very short time period. Let's use XX9XX for example as the spotted DX. Once the first spot of XX9XX on 14195.00 has been delivered to my local users, I feel it's redundant and a waste of bandwidth to deliver the other 29 spots of XX9XX on 14195.00 to them, so I don't. Redundancy is based on a 10 minute time window.

Total REDUNDANT spots: Not counted for this contest.If they had been counted, there would have been plenty of them. There always are in any contest.

FILTERED SPOTS - These are spots sent to the bit bucket based on dynamically assigned filter strings, such as "BUSTED" (YCCC and PVRC care about BUSTED, we don't), "NOW QRT" (you can't work the DX if he's not there anymore) "/B" (beacons never answer, no matter how long you call them), etc. Filters on this node change on a regular basis, based on what is currently needed and who's playing monkey around at any given time.

Total FILTERED spots: 1,436

BAD CALL SPOTS - These are spots in which the call can not be resolved against a DXCC prefix lookup. They are mostly generated by the six meter guys, and are commonly seen on any cluster node. Calls in these spots include, but are not limited to WHO, NUMBERS, PIRATES, MUF, NIL, VIDEO, VID, PHONES, NOMAGIC, EUROPEA, etc. These spots aren't very useful, at least not for CQWW SSB. All of the examples are real spots, from the log.

Total BAD CALL spots: 206

BAD FREQ SPOTS - the spot frequency is not within a ham band. These are always useless.

Total BAD FREQ spots: 9

Summary of Statistics

The main problem noted in this contest was OLD spots. And the vast majority of OLD spots were caused by ONE U.S. node.

Which node? If you really need to know that, send me an email and I'll tell you which node. I'm not writing this because I want to start Cluster Wars III. I've already notified the guy who runs the node, I was sending him email all weekend, but I haven't received any reply from him yet. I'm not sure I ever will. He's a well known contester and he's been running nodes and writing software for a long time so how this happened is beyond the scope of my imagination.

The spots were MUTILATED, i.e., intentionally changed by software so they would recirculate in the cluster system.

If you run a cluster node, how can you tell what a 'mutilated' spot is? The only way you can tell is by looking at raw PC codes that another node is sending you. This is the PC code for a spot:

<05:07> PC11^3531.2^K5K^30-Oct-2000^0508Z^CQ CQ EU^N5RG^WC5P^H97^~

PC11 - is the PC code for a DX spot.
3531.2 - is the spot FREQUENCY.
K5K - is the DX call.
30-Oct-2000 - is the date the spot was sent.
0508Z - is the time the spot was sent.
CQ CQ EU - is the comment field.
N5RG - is the call of the original sender.
WC5P - is the node the spot originated on.
H97 - is 'hops' the spot should live.

Since all of today's cluster software rejects or ignores duplicate spots (if it's set up right, anyway) then my node can't send the exact same spot back to the node it received it from with any hopes of it going back into the system. But if I CHANGE something in the spot, and send it back again, depending on the software being used at the other node there is a chance it will get through as a 'new' spot.

Europe's favorite trick for a few years has been changing the COMMENT field:

Receive THIS: PC11^3531.2^K5K^30-Oct-2000^0508Z^CQ CQ EU^ N5RG^WC5P^H97^~
Resend THIS: PC11^3531.2^K5K^30-Oct-2000^0508Z>^ CQ CQ EU ^N5RG^WC5P^H97^~

Fortunately the guys who write software have picked up on the Change-The-Comment-Field Trick, so it works on fewer and fewer systems all the time.

Another favorite trick is SUCKING spots from another node or from a WebCluster and then formatting them to look like locally generated spots. I'd guess that's what was happening this weekend. A spot from a WebCluster or a node that is delivering spots to a user is:

DX de DL1RWN: 7002.0 HB0/DL2SBY <comment> 0538Z

Some of the information is there: senders call, time, DX call, frequency, and comment. The clue to finding SUCKED spots is usually TIME and NODE CALL - the time is usually wrong vs. what time it really is NOW - and the node call is the call that was inserted by the software doing the sucking. So if you are running a node and you see LOTS of spots with the times 10,15,20, or 30 minutes slow and the NODE call is always the same, you are probably seeing sucked spots. You need to get rid of the connection to the source of these spots.

It's EXTREMELY unfortunate that some of the newer cluster node software has the function to suck web cluster spots built right into the software. If you run a node and want to suck spots from wherever and give them to you local users, go for it. But putting them back out onto the network as new spots is TOTALLY NUTS as is providing anybody with software capable of doing the same....

If you are a cluster node USER, how can you tell if you are being fed BALONEY instead of DX?

It's tuff, but there are a few things you can watch for. Watch the TIME of spots you get. That's the biggest giveaway of problems. Times should be (within a few minutes) in chronological order. Here's a clip of what a node I was logged onto last night (1500Z) as a USER was feeding me:

DX de DL4DHC:	21194.0	XE1CRO	ZONE 6	XE 1502Z DL
DX de K2TR:	28724.9	V26B		V2 1355Z NY
DX de W1ZA:	14200.0	BA4DW		BY 1307Z MA
DX de K7ZO:	21364.1	TI1C		TI 1453Z ID
DX de K2TR:	21263.6	VP2EK		VP2E 1502Z NY
DX de OH1AA:	18079.4	DU3NXE		DU 1502Z OH
DX de WX4DX:	28721.5	9K9Z		9K 1334Z NC
DX de K7ZO:	21276.9	PJ7/K7ZUM		PJ7 1501Z ID

As you can see from the time of the spots, I was getting fed a considerable amount of BALONEY. Watch the NUMBER of spots you get. At one point last nite, my node was receiving in excess of 30 spots per minute from the remote node - two thirds of them were mutilated, regurgitated BALONEY. If you are getting way too many spots, that's a good indication that the Baloney Vendor is connected to a cluster node near you.

What can you do as a user if you see a problem?

Tell the guy who's running your node about it. Tell him nicely, please. If he can't fix it or doesn't want to fix it or won't admit there's a problem, just point your Telnet program to another node somewhere else that works. Maybe when he winds up with no users, he'll realize that there must be a reason why.

Did I make all of this up?

No, I have better things to do.

Why do I bother to collect all this data and then make web pages about it?

I like to share my opinions with other hams. I hope somewhere along the line somebody who has heard me rant about how hosed up our DX cluster 'network' is has done or will do some little thing to make it better. I think the DX cluster 'network' is a fun tool to use with ham radio, but I think, like the old packet BBS 'network' of days gone by, we still have some people who are asleep at the wheel and need a little nudge to wake up.

I KNOW FOR A FACT that somebody with a bad attitude and a tiny bit of programming knowledge could make the worldwide cluster system TOTALLY USELESS for a weekend contest or for how ever long he or she chose to make it useless. I know I could do it. But I'd rather think of ways we can make it better than spending my time proving I could wreck it if I wanted to. I think we are doing a better job than we were a few years ago. But I think we can still do much better if we all put forth a little more effort.

Black Helicopters - The Conspiracy Theory?

Would somebody intentionally wreck or attempt to wreck the DX cluster network? I'd like to think not, but I'm starting to wonder. Some of the other guys I know who run cluster nodes are starting to wonder too. Not everybody running a cluster node is running the same software. Not everybody who is writing cluster software has the same ideas about what it should/should not do. Not everybody who is writing cluster node software is giving it away for free, so there are some $$$$ involved. It's not a secret that there is no love lost between the producers of different software packages, or so I'm told. Other people have suggested the Black Helicopter Theory to me before...>

On Monday I'm closer to believing in Black Helicopters now than I was on Friday. Why?

One, the guy who made the big mess this weekend knows better. I can't imagine someone with his cluster and software experience could have an accident of this scale.

Two. I Telneted to the guys node who was making the big mess, and he wasn't giving his users old spots, only new ones. So why was he sending them to other nodes?

Three, I did some more Telnetting during the big mess, and I saw something that REALLY made me wonder. I logged onto a node as a user and it was feeding me BALONEY, even though it KNEW THE DIFFERENCE between BALONEY and NEW SPOTS !! It was giving me spots in two different formats:

Lower case 'DX': - > dx de CALLSIGN: Followed by a good (new) dx spot

Upper case 'DX': - > DX de CALLSIGN: Followed by a bad (old) dx spot

So if the software KNEW the difference between a bad spot and a good spot, why was it giving users bad spots?? I don't know. Why does it bother me? Well, because the guy who runs this node is also the guy who is authoring one of the currently available DX cluster node packages. So if he CODED the difference between a BAD spot and a GOOD one, why's he giving his users BAD ones? And what other nodes is he giving BAD ones also?

Cluster node software is some pretty tuff stuff to write. I know, because I wrote a SIMPLE cluster program so I know how hard it would be to write a full blown one. Software needs to be tested - what works in the programmer's head doesn't always work in somebody else's computer. I honestly HOPE these guys were doing some testing and not intentionally hosing up things - granted that CQWW SSB weekend is a GREAT time to test cluster software, because good testing requires a BIG load, but come on guys, if you are testing, give the rest of the world a break and set up some off-line nodes and test with them, don't give the rest of us 5,000 bogus spots to deal with every 10 hours.

Where do I get this Black Helicopter stuff, am I paranoid?

No, amateur radio is just a hobby, so in the big scheme of things, none of the above really matters much anyway. Bad spots don't affect anybody on my node, because our software puts them in the bad spot log, not in anybody's face. Unless I check the logs and the counters after a contest, I don't even know there is a problem.

But someplace in the back of my mind, there's this breakfast meeting of the Saturday Morning DX'ers Club going on. And the conversation is going something like this:

DX'er number 1: Wow, the cluster system was a BIG MESS this weekend!!

DX'er number 2: What software you running on your node?

DX'er number 1: I'm running FREEBASE, that UNIX stuff.

DX'er number 2: Oh. No wonder. I'm running PAYFORIT, the best there is. I didn't have any problems.

Announcer's voice from beyond the picture: Sure, he didn't have any problems with PAYFORIT. That's because the guys who made PAYFORIT are the guys CREATING all the problems, and their software is coded to IGNORE problems they create. What a sales tool!!

Could that really happen? I guess it could. I really hope it didn't. The guy on TV keeps saying anything is possible on the PGA tour, so who knows for sure?