[Dxspider-support] Hop counts
Dirk Koopman
djk at tobit.co.uk
Sat Dec 31 20:24:28 GMT 2022
Needless to say, having seen these (valid) complaints from Lee, I
thought I would setup a watchdbg to determine the scope of the problem.
The results have been rather surprising, given that even GB7DJK is on
the list. It is only once but that, by itself, is surprising.
The command(s):
If you are running the 'mojo' branch, in a console do: unset/debug nologchan
WARNING: this will increase debug files between 5 and 10 times normal.
In a shell: watchdbg ' \<\- I [-\w\d]+ PC[16]1\^.*\^H[0123456]\^~'
Analysis of approx 14 hours of monitoring:
In a shell:grepdbg ' \<\- I [-\w\d]+ PC[16]1\^.*\^H[0123456]\^~' | cut
-d'^' -f8 | sort | uniq -c | sort -nr
723 F5LEN-3
164 W1NR
115 WA9PIE-2
79 IK5PWJ-6
48 VE7CC-1
27 DB0ERF-5
19 ON4KST-2
15 SR4DXC
14 S50CLX
9 W1NR-9
9 N0VD-7
9 IZ7AUH-6
8 JH1RFM-9
8 HA6DX
8 9A0DXC
7 S50DXS
7 F6GCP-3
7 DB0LJ-6
6 IQ8PQ-6
6 IK6IHL-6
5 F6BVP-3
3 SM4ONW-14
3 OH2J
3 IK2DUW-6
3 GB7MBC
3 G4ELI-9
2 SV2HRT-1
2 SR2PUT
2 SM6YOU-7
2 PY4OG-4
2 ON0DXK-5
2 EA6VQ-2
2 EA4RCH-5
1 SM7IUN-3
1 SM7GVF-6
1 SK3W-6
1 OH1RCF
1 K7AR-4
1 K1TTT
1 IZ5FSA-6
1 IZ3MEZ-8
1 IW1PSC-6
1 IV3BVK-5
1 GB7NHR
1 GB7DXS
1 GB7DJK
1 F6KVP-3
1 F3KT-3
1 DB0HGW-6
So, having found GB7DJK on the list, and then discovering why, I have
removed a local version of a file that has been there since before PC92
etc was a thing. The result of this means that GB7DJK is, at least
partially, responsible for the problems that Lee has pointed out.
If you are running any version of DXSpider, AND YOUR CALL IS ON THE
LIST ABOVE with a double digit count, then add the following lines to
your /spider/scripts/startup:
set/var $DXProt::def_hopcount 30 (or some larger number)
Then repeat this command in a console to activate it in real time
without restarting the node.
If you have a local copy of /spider/local/DXProtVars.pm AND there is an
entry for 11 and/or 61 in %hopcount, then do the following in a console
to disable the effect without restarting:
set/var $DXProt::hopcount{11} 0
and, (only) if this too is defined:
set/var $DXProt::hopcount{61} 0
Then REMOVE /spider/local/DXProtVars.pm.
If you have used this file locally, please tell me (in a private) how
you are using it and I can make suggestions as to how to get rid of it.
In the next release of the mojo branch it will be renamed or (more
likely) just removed. In modern PC9x environments it no longer has any
useful function that can't be done with 'set/var' commands in startup.
73 and HNY for 2023 Dirk G1TLH
On 30/12/2022 23:37, Dirk Koopman via Dxspider-support wrote:
> Whoever is setting hop counts to such low values should desist
> IMMEDIATELY. Frankly the hop count is now redundant, given all the
> other de-duplication measures that nodes have. But, as a backstop, the
> default value should be set to at least 30. But better yet, just leave
> it at the default.
>
> As for the best thing to do: personally, I'd just re-hop them up to
> some minimum. Having said that, I am not seeing the disparity of hop
> count that you are at VA1AAA-1. The "worst" I have seen is some nodes
> setting the initial hop count to 30 (as recommended above)[if you must
> do it at all]. But I have a job running to trap any that pass GB7DJK's
> way.
>
> I have been concerned about PC11s "winning" the spot "record slot"
> over a PC61 arriving later. I keep meaning to do something about this
> but I keep getting distracted and forget. I feel an ephemeral "per
> spot queue" coming on.
>
> Dirk G1TLH
>
> On 30/12/2022 20:48, Lee Sawkins via Dxspider-support wrote:
>> Examples of Hop problem at VA6AAA-1 node
>>
>> This is really annoying. Spots were being missed by some nodes
>> because of this.
>>
>> Since AR Clusters can't process PC61 spots and CC Clusters only down
>> hop by 1, some of the following could only happen at Spider nodes.
>> What I have done in self defense is to forward multiple spots. This
>> means that both spots you see below will be forwarded. One right
>> after another. CC Clusters can accept and forward these. I keep
>> forwarding duplicate spots until the hops count gets above 10. I may
>> have to increase this.
>>
>> GB7DJK -> 4 PC61^14031.0^Z36T^30-Dec-2022^1846Z^Frustrated OM
>> ^Z30T-10^F5LEN-3^51.68.11.211^H5^~
>> VE7CC-1 -> 5 PC11^14031.0^Z36T^30-Dec-2022^1846Z^Frustrated
>> OM^Z30T-10^F5LEN-3^H97^~
>>
>> AE5E -> 3 PC61^14023.1^AJ1AJ^30-Dec-2022^1859Z^YOTA CW TNX
>> ES HNY!^NB1N^W1NR^24.91.112.56^H2^~
>> VE7CC-1 -> 5 PC61^14023.1^AJ1AJ^30-Dec-2022^1859Z^YOTA CW TNX
>> ES HNY!^NB1N^W1NR^24.91.112.56^H26^~
>>
>> GB7DJK -> 4 PC61^14021.4^E7CW^30-Dec-2022^1908Z^YOTA CW TNX
>> ES HNY!^NB1N^W1NR^24.91.112.56^H2
>> AE5E -> 3 PC11^14021.4^E7CW^30-Dec-2022^1908Z^YOTA CW TNX
>> ES HNY!^NB1N^W1NR^H97
>>
>> AE5E -> 3 PC61^7272.0^W2T^30-Dec-2022^1949Z^
>> ^KK4ADQ^W1NR^76.106.89.109^H2^~
>> VE7CC-1 -> 5 PC11^7272.0^W2T^30-Dec-2022^1949Z^
>> ^KK4ADQ^W1NR^H97^~
>>
>> VE7CC-1 -> 5 PC61^7020.6^CT9ABN^30-Dec-2022^2028Z^
>> ^NB1N^W1NR^24.91.112.56^H2^~
>> AE5E -> 3 PC11^7020.6^CT9ABN^30-Dec-2022^2028Z^
>> ^NB1N^W1NR^H97^~
>>
>> Lee VE7CC
>>
>> ----- Original Message -----
>> From: "The DXSpider Support list" <dxspider-support at tobit.co.uk>
>> To: "The DXSpider Support list" <dxspider-support at tobit.co.uk>
>> Cc: "Dirk Koopman" <djk at tobit.co.uk>
>> Sent: Friday, December 30, 2022 8:23:18 PM
>> Subject: Re: [Dxspider-support] Hop counts
>>
>> I should add that it is technically possible for DXSpider nodes to rehop
>> PCxx sentences, particularly in the downward direction.
>>
>> On 30/12/2022 20:20, Dirk Koopman via Dxspider-support wrote:
>>> Some nodes deliberately limit hop counts to some low number like 10 or
>>> 15. A pity then, that spots that travel through nodes (IIRC AR-C)
>>> where they are "rehopped" back to 98 (or so). I did some research on
>>> this several years ago and that was the conclusion I came to at the
>>> time. But things may have changed since then.
>>>
>>> 73 Dirk G1TLH
>>>
>>> On 30/12/2022 18:41, Lee Sawkins via Dxspider-support wrote:
>>>> Can someone explain to me why my cluster receives some dx spots with
>>>> a hop count of say H3 or lower from one of my node links and almost
>>>> immediately receives another identical spot almost immediately from
>>>> another node partner with a hop count of H97. This first one is sent
>>>> out to my node connections with a hop count of H2 or less, which
>>>> means it should soon be hopped out and not further forwarded. Why is
>>>> some intermediate node doing this. Is it an attempt to sabotage the
>>>> distribution of some spots?
>>>>
>>>> Hop numbers from a couple of specific nodes are particularly low.
>>>> These include W1NR, F5LEN-3 and EA6VQ-2.
>>>>
>>>> 73 Lee VE7CC
>>>>
>>>> _______________________________________________
>>>> Dxspider-support mailing list
>>>> Dxspider-support at tobit.co.uk
>>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>
>>> _______________________________________________
>>> Dxspider-support mailing list
>>> Dxspider-support at tobit.co.uk
>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> 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