[Dxspider-support] PC41 loop?

Lee Sawkins ve7cc at shaw.ca
Wed Jun 16 19:30:43 BST 2010 

Hi Dirk

What you have done with PC9x messages works great.  If all the other PC 
messages could be redone to have time tags, this would go a long ways 
towards cleaning up the backbone traffic.

At times I see alternating PC41s with name information.  One PC41 for a call 
will have the name as "Bob" and it will immediately be followed by another 
one with the name "Robert" for the same call.  Accented letters in names or 
QTHs get changed to "?".  We then have alternating PC41s with different 
content.   This just keeps looping.

I set my location as 49 11 N 122 30 W.  This goes out in a PC41.  I see it 
come back alternating as 49 11 N 122 27 W and 49 11 N 122 30 W.  How does 
this happen?  This resets the dupe filtering as well.

I also see alternating PC19 and PC21 from the same node.  This goes on for 
hours and hours, one right after another.

I also at times see DX Spots come in with a hops count of H1.  This stops 
the spot from going further.  Sometimes I then immediately see the same spot 
arrive with  a hops of say H93.  I process this "dupe" spot and send it on 
as H92.  Does Spider do this?  I don't think so.  If not, it means that a 
cluster that sets all its DX Spots to a hops of H1 can stop other clusters 
from passing the spot further.  I have one cluster that sends me almost all 
spots with H1.  I do not start dropping DX spots until I see an H10 or 
higiher.

Lee

----- Original Message ----- 
From: "Dirk Koopman G1TLH" <gb7tlh at dxcluster.org>
To: <rene.chr.olsen at gmail.com>; "The DXSpider Support list" 
<dxspider-support at dxcluster.org>
Sent: Wednesday, June 16, 2010 4:32 AM
Subject: Re: [Dxspider-support] PC41 loop?


> Rene
>
> Thank you for reminding everyone of the reasons why the hop table exists. 
> One could argue that it is no longer required. I am thinking that I might 
> take it out or disable it - or maybe just use it for the "origination".
>
> However, on the substantive points:-
>
> 1) hop count decrementing to 0: I believe that Lee's concerns were dealt 
> with some time ago. AFAIK it now works as he believes it should. If it 
> doesn't, then I would like some test cases to enable me to fix it.
>
> 2) There is a dup filter on PC41, it is currently set to a loop time of 1 
> hour (3600 seconds). I can increase the default time to something else (24 
> hours?) or you can change it yourselves by doing a:
>
> set/var $DXProt::eph_info_restime = 86400
>
> I notice, taking just one example for today, that the loop time for these 
> PC41 is huge (and the hop_table is not helping):
>
> 16Jun2010 at 03:49:29 <- I SM0RUX-6 PC41^IW9GXT^1^Daniele^H3^~
> 16Jun2010 at 05:02:42 <- I ED7ZAB-5 PC41^IW9GXT^1^Daniele^H2^~
> 16Jun2010 at 07:12:48 <- I IZ5FSA-6 PC41^IW9GXT^1^Daniele^H7^~
> 16Jun2010 at 11:20:31 <- I SM0RUX-6 PC41^IW9GXT^1^Daniele^H2^~
>
> In the old days, 1 hour seemed to be enough to slug these messages, but 
> that seems no longer to be the case. It may be that even one day is not 
> long enough if these messages are getting re-hopped.
>
> My concern is that, whatever loop constant we stick on here, there is some 
> kind of slow background loop within the system as a whole that is causing 
> this sort of problem.
>
> In the limit there are three options:
>
> 1) switch them off (not at all my preferred solution, because the info is 
> useful).
> 2) fiddle with the dedupe loop constant until they go away (enough).
> 3) add a new PC9x sentence that deals with it once and for all.
>
> Dirk G1TLH
>
>
> On 16/06/10 11:03, Rene Olsen wrote:
>> Now it may be the case, that no cluser is no more than 10 hops away from 
>> each other. But
>> that was not the case back then. The hops table was not introduced just 
>> for the fun of it.
>>
>> Some of the story also is that some cluster owners, thought that the 
>> spots from their node
>> should not be able to propagate more than 5 nodes away. So they changed 
>> all hop counts to
>> 5 or lower. Again, the hops table was not introduced just for the fun of 
>> it.
>>
>> It may well all be history now, but back in the days there were a cluster 
>> "war" here in Europe,
>> where some siteops did everything in their power to prevent everything 
>> from spreading very
>> far, and hence trying to force everyone to use their clusters. This is 
>> all history now, but the
>> hops table was a way to make sure they didn't obtain their objective.
>>
>> Have done a bit of experimenting, and it seems that you can only raise 
>> the hop count and not
>> decrease it. The reason that it can't be decreased, is of course to 
>> prevent owners being able
>> to prevent things from being spread. And it doesn't seem to work on PC41 
>> frames at all.
>>
>> I did another test to see how much PC41 trafic there is.
>>
>> My debug file 166.dat has a size of just above 62 MB. I then grep'ed all 
>> PC41 trafic from it,
>> and the resulting file is very close to 17 MB !! That means that 27% of 
>> all the trafic is from
>> PC41 frames. That is just insane imo. Something needs to be changed I 
>> think.
>>
>> Vy 73 de Rene / OZ1LQH
>>
>>
>> On 16 Jun 2010 at 2:47, Lee Sawkins wrote:
>>
>>> We agree on what is happening.  You may not call it a bug, but I do. 
>>> The
>>> reason hops must always be decremented and never increased is to prevent 
>>> the
>>> exact problem we are experiencing.  Other cluster node software does not
>>> allow this "feature".
>>>
>>> A hops count of 15 or 20 should be enough to make it to every cluster in 
>>> the
>>> whole system.  As almost all clusters are now Internet linked, I doubt 
>>> that
>>> any cluster is now more than 10 hops away from any other cluster.
>>>
>>> Lee
>>>
>>> ----- Original Message -----
>>> From: "Rene Olsen"<rene.chr.olsen at gmail.com>
>>> To:<dxspider-support at dxcluster.org>
>>> Sent: Wednesday, June 16, 2010 2:25 AM
>>> Subject: Re: [Dxspider-support] PC41 loop?
>>>
>>>
>>>> As far as I know there is no such thing as a hops bug in spider.
>>>>
>>>> But, it is a feature that has helped many in the past, that is now 
>>>> showing
>>>> a bad side efect.
>>>>
>>>> Way back, when there were not as many clusters as there is now, the
>>>> problem was that
>>>> some clusters sent out the spots entered by their users with a hop 
>>>> count
>>>> of 15 or 20.
>>>>
>>>> That hop count was just too low, for spots to make it all around, and 
>>>> it
>>>> became obvious that
>>>> some spots "died" along the way, because of the hop count.
>>>>
>>>> This is why the hops table was introduced into spider. With that file 
>>>> you
>>>> can manipulate the
>>>> hop count of every PC frame as you like. This is why you will often see 
>>>> a
>>>> PC frame leave a
>>>> spider node with a higher hop count than when it entered.
>>>>
>>>> Since we have dupe checking on spots and announcements, those gets
>>>> blocked. But it
>>>> seems like there is no dupe check for PC41 frames. But if all PC41 
>>>> frames
>>>> circles around the
>>>> entire network 4 to 8 times a day, and maybe even for longer periods, 
>>>> then
>>>> we are wasting a
>>>> lot of bw, and I think this should be addressed. One way or another.
>>>>
>>>> Vy 73 de Rene / OZ1LQH
>>>>
>>>> On 16 Jun 2010 at 1:35, Lee Sawkins wrote:
>>>>
>>>>> This hops bug has been in Spider for years.  I started reporting it 
>>>>> when
>>>>> I
>>>>> was a Spider sysop.  The problem is that Spider software does not
>>>>> decrement
>>>>> hops properly.
>>>>>
>>>>> I can send out PC messages from CC Clusters to Spider with a hops 
>>>>> count
>>>>> of
>>>>> H1 and guess what, they come back to me with a higher hops count. 
>>>>> That
>>>>> is
>>>>> why I have turned PC41 off.   They just keep looping around.
>>>>>
>>>>> Lee
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Rene Olsen"<rene.chr.olsen at gmail.com>
>>>>> To:<dxspider-support at dxcluster.org>
>>>>> Sent: Tuesday, June 15, 2010 11:59 PM
>>>>> Subject: [Dxspider-support] PC41 loop?
>>>>>
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I was monitoring a bit with watchdbg yesterday and today, and started
>>>>>> to
>>>>>> wonder why there
>>>>>> were so much PC41 trafic. I tehn decided to look at it a bit closer,
>>>>>> because it looked to me,
>>>>>> like it was the same information being sent over and over again.
>>>>>>
>>>>>> PC41^IZ7ECT^2^BARI^H16^~
>>>>>>
>>>>>> That one for example, I received no less than 6 times yesterday 
>>>>>> (debug
>>>>>> file 166.dat).
>>>>>>
>>>>>> PC41^PA1LS^2^Halderberge^H3^~
>>>>>>
>>>>>> And that one I received 4 times.
>>>>>>
>>>>>> They don't come right after each other. The time stamps for the PA1LS
>>>>>> one
>>>>>> is:
>>>>>>
>>>>>> 1276560016
>>>>>> 1276572511
>>>>>> 1276620498
>>>>>> 1276634794
>>>>>>
>>>>>> Seems to me that a lot of bw is wasted on having this stuff circling
>>>>>> around.
>>>>>>
>>>>>> Is there any reason for this?
>>>>>>
>>>>>> I doubt that someone actually updates his QTH or other info several
>>>>>> times
>>>>>> a day :-)
>>>>>>
>>>>>> Vy 73 de Rene / OZ1LQH
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dxspider-support mailing list
>>>>>> Dxspider-support at dxcluster.org
>>>>>> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dxspider-support mailing list
>>>> Dxspider-support at dxcluster.org
>>>> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at dxcluster.org
>> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

More information about the Dxspider-support mailing list