[Dxspider-support] Weekend data

[Dirk Koopman]

I have a direct connection to K1TTT and he was the primary source of the 
copy attack traffic. It appears that AR Cluster does not have the same 
resource issues when used just as a "bounce node" (A node that only 
allows connections to other nodes - no users). I would see a genuine 
spot come in from somewhere and then, within seconds, the copy attacks.

Now it's not K1TTT that is responsible, his node is just the vehicle.

Dirk G1TLH

On 2025-03-31 17:37, Kin via Dxspider-support 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
> 
> 
> 
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support