[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