Appreciate the comments and your hard work Pete, but I just don't get it.
I posted one screenshot showing some obviously bad flaws in the
system, and it's hard to accept that things can't be made better than
that. There's no reason it has to be democratic - if you send bad
spots (don't follow the rules), you should get cut off from sending
spots to the RBN system.
It might be enlightening to do some quality control analysis - is
there a super computer somewhere that could run all the spots dumped
into the system during the contest against the callsign database and
look at the list of spots that don't validate, i.e., what percentage
are bogus, how the skimmer nodes each performed, etc?
Taking the time during a contest to add bad spots to a logging program
list is out of the question. It already takes too much time to just
delete them individually and having a long bad list isn't going to
help cpu loading either.
Perhaps the solution is to somehow recognize the skimmers that ARE
doing the validation and not sending the bad spots and somehow filter
out the spots coming from the other skimmers. But I don't know of a
way to do this, other than simply telnet into a single known good
skimmer if that's possible.
73, Barry N1EU
On Thu, Dec 1, 2011 at 4:10 PM, Pete Smith <n4zr@contesting.com> wrote:
> As always, thanks for your comments, Barry.
>
> Keep in mind that the RBN is a network of ~70 simultaneous volunteers,
> all over the world. CW Skimmer and Skimmer Server both have bad call
> lists built in. If 50 nodes have LW3LPL or RK3LR blocked, and 20 do
> not, then the bum spots will still appear.
>
> We believe it makes better sense for users to implement their own
> filters. For example, N1MM Logger has both bad call and bad spotter
> lists that can be fed from the bandmap's right-click menu. A contest or
> two and all those RF-caused busts can be history. We're pretty well
> convinced that validation against a master.dta file is *not* the answer.
>
> The problem of callers being spotted as if they were running is
> well-known, but Alex has so far not been able to come up with a better
> solution than that which is currently implemented. I just keep an eye
> on the bandmap, and ignore stations that appear in zero beat with
> someone I've recently worked. A short bandmap timeout also helps.
>
> 73, Pete N4ZR
>
> The World Contest Station Database, updated daily at www.conteststations.com
> The Reverse Beacon Network at http://reversebeacon.net, blog at
> reversebeacon.blogspot.com,
> spots at telnet.reversebeacon.net, port 7000 AND now
> at arcluster.reversebeacon.net port 7000
>
>
>
> On 12/1/2011 10:06 AM, Barry N1EU wrote:
>> Although I greatly appreciated all the spots from the RBN and the hard
>> work by the network/server admins, I still feel a great improvement
>> would be more screening (“CQ” and callsign database validation) by the
>> skimmer servers. I noticed myself and others spotted numerous times
>> when calling dx. And there sure wouldn’t be a downside to eliminating
>> all the LW3LPL and “EK” spots. Losing potential spots of dx not in
>> the database would be a small price to pay for really cleaning up the
>> RBN contest spots. And those “lost” spots can always be entered the
>> old fashioned way by human ops. I got a laugh at one point when I
>> glanced up at my cluster client screen - have a look:
>>
>> http://n1eu.com/skimmer_spots.gif
>>
>> . . . the irony of W3LPL spotting itself as LW3LPL and W4LPL - it
>> just doesn't seem right that the system allows this
>>
>>
>> 73, Barry N1EU
>>
>> On Thu, Dec 1, 2011 at 7:29 AM, Pete Smith<n4zr@contesting.com> wrote:
>>> Wow! What a weekend - records falling in bunches, 5 bands open for
>>> contesting at once. And I'm happy to report that the RBN was mostly up
>>> to the challenge.
>>>
>>> First, the big numbers. The RBN handled 1.578 million spots on
>>> Saturday, and 1.691 million on Sunday, or an average for the 48 hours of
>>> *18.9 spots/second. This is roughly double last year's record average
>>> (also in CQWW CW)*, and is a measure both of how much the bands have
>>> improved and how many more people are contributing to the RBN. Thank
>>> you all!
>>>
>>> In case anyone wondered, we did have some trouble with the DX Spider
>>> Telnet server (telnet.reversebeacon.net, port 7000) on Sunday morning,
>>> as the load built to even a higher level than on Saturday. Felipe PY1NB
>>> did some quick first-aid and got it running again within about a
>>> half-hour. Meanwhile, the AR Cluster V6 server
>>> (arcluster.reversebeacon.net, port 7000) continued to deliver spots at
>>> full bore, though to a smaller audience than our main and
>>> long-established server.
>>>
>>> There are also some signs that the load that CW Skimmer puts on Reverse
>>> Beacon participants' computers may be starting to cause problems. A
>>> number of Skimmer ops reported trouble with less than 100% decoding of
>>> signals, due to excessive CPU loading from too many decoders running at
>>> once. At least the failure mode appeared to be graceful - my node, for
>>> example, stayed up unattended all weekend despite being on an anemic
>>> dual-core Pentium machine.
>>>
>>> One surprise, at least to me, was the strong user demand for the main
>>> Reverse Beacon web page, which peaked at 384 simultaneous users, also on
>>> Sunday. Log data suggest that most of these users were using the site
>>> to track spots of specific stations (maybe their own?), which puts an
>>> additional load on the database server. However, the new hardware
>>> handled it very well, and that gives us a good level of confidence for
>>> the rest of the contest season.
>>>
>>> Future plans? Well, we intend to do some work on streamlining DXSpider
>>> so that it will handle the heavy throughput better. There's no need for
>>> a lot of the features that put a drag on performance in the RBN server
>>> role - for example, the server doesn't accept DX spots from users, or
>>> Announce messages or WWV messages. Meanwhile, we're on the lookout for
>>> good new features to add to the mix. Tell us what *you'd* like!
>>>
>>> --
>>> 73, Pete N4ZR
>>> The World Contest Station Database, updated daily at
>>> www.conteststations.com
>>> The Reverse Beacon Network at http://reversebeacon.net,
>>> blog at reversebeacon.blogspot.com,
>>> spots at telnet.reversebeacon.net, port 7000
>>> AND now at arcluster.reversebeacon.net port 7000
>>>
>>> _______________________________________________
>>> CQ-Contest mailing list
>>> CQ-Contest@contesting.com
>>> http://lists.contesting.com/mailman/listinfo/cq-contest
>>>
>> _______________________________________________
>> CQ-Contest mailing list
>> CQ-Contest@contesting.com
>> http://lists.contesting.com/mailman/listinfo/cq-contest
>>
>>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|
