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
|
