[Dxspider-support] Weekend data

Rudy Bakalov r_bakalov at yahoo.com
Mon Mar 31 18:07:03 BST 2025


Since my cluster is one of the bad guys on the list, I am considering a hybrid approach:

1/ Running a spider to filter out bad backbone traffic. This node will only connect to other nodes and won’t be advertised to end users. Let’s call it N2WQ-73
2/ Running the existing N2WQ-1 node exclusively for end users as I find CCC far more end user friendly. This node will be connected only to N2WQ-73 and no other nodes.

Thoughts?

Rudy N2WQ

Sent using a tiny keyboard.  Please excuse brevity, typos, or inappropriate autocorrect.


> On Mar 31, 2025, at 12:37 PM, Kin via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
> 
> Hi,
> 
> In case anyone is interested.
> This is the data for the weekend. It includes build changes made over the
> last two days (CQ WPX SSB 2025).
> 
> The test setup was:
> 
> Peers Nodes: 7
> Total Users: 1
> 
> --------------------------------- Spots Vars
> -----------------------------------
> 
>                        Slot Time  (s):    $Spot::timegranularity = 60
>                        Slot QRG (kHz):    $Spot::qrggranularity = 1
>                        Dupe Page  (s):    $Spot::dupage = 300
>           Length text in the deduping:    $Spot::duplth = 15
>             Max length call for dupes:    $Spot::maxcalllth = 12
>       Granularity input time Spot (s):    $Spot::spotage = 125
>                             Bad spots:    $DXProt::senderverify = 1
> 
>        Enable/disable 'node' checking:    $Spot::do_node_check = 0
>        Enable/disable 'call' checking:    $Spot::do_call_check = 1
>          Enable/disable 'by' checking:    $Spot::do_by_check = 1
>      Enable/disable 'ipaddr' checking:    $Spot::do_ipaddr_check = 1
> 
> Check 'call' is not spotted too often:    $Spot::dupecall = 10
> Threshold 'call' to become a duplicate:    $Spot::dupecallthreshold = 35
> Check 'node' is not spotted too often:    $Spot::nodetime = 10
> Threshold 'node' to become a duplicate:    $Spot::nodetimethreshold = 50
> 
> ----------------------------------------------------------------------------
> ----
> 
> Results:
> 
> String             Total
> ---------------  -------
> DXDupe::add       376926
> DXDupe::del       373686
> DXDupe::clean      32100
> Bad Spot            1113
> Bad Node           16496
> Badwords              98
> 
> Normalised call      171
> RFC1918-dropped     5214
> 
> PC11 in            78519
> PC11 out            7019
> PC61 in           449619
> PC61 out          135223
> 
> PC92 A in         423802
> PC92 A out        497918
> PC92 D in         324649
> PC92 D out        377591
> PC92 C in          68236
> PC92 C out         68343
> ------------------------
> 
> Observations:
> There were delays of up to 9 minutes on some nodes.
> Some nodes failed. It took me 15 minutes to reconnect to VE7CC-1 (CC
> Cluster).
> The retransmission of bad points on VE7CC-1, N2WQ-1, and AE5E was massive.
> On EA3CV-2, EA3CV-3, and WA9PIE-2, bad point discarding was very effective,
> as the avalanche of bad points was not detected.
> I selected the CCCluster and DXSpider nodes, which I knew were on the latest
> version.
> 
> I am attaching a plain text file for those who cannot see the data
> correctly.
> 
> Conclusions are at the discretion of the reader.
> 
> Kin EA3CV
> 
> 
> <results.txt>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support




More information about the Dxspider-support mailing list