[Dxspider-support] PC41 loop?

Rene Olsen rene.chr.olsen at gmail.com
Wed Jun 16 14:20:17 BST 2010 

Hi Dirk.

I thought that some historical background might be a good idea :-)

You might be correct that in current age we no longer need the hop table. I see quite a few 
spots arriving here with very low hop counts though (1-3).

Of the options you mention for PC41 handling I would vote for 2 or 3.

As you say there is a big time gap between them, and I must say that I was amazed to see 
how big a percentage of the total trafic was PC41.

Would it not be possible to "reset" the dupe timer each time a dupe is received?

That means setting the dupe time to 12 hours or whatever, and each time a dupe is received, 
reset the counter to 12 hours again. I am not a programmer, so there might be some very 
bad side effect to this. And maybe making a new PC9x frame would be just as easy to code 
:-)

After 12 hours without any dupe, that PC41 would be cleared again.

But, even setting it to 24 hours as it is now, I believe would lower the trafic substantially.

Vy 73 de Rene / OZ1LQH

On 16 Jun 2010 at 12:32, Dirk Koopman G1TLH wrote:

> 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
> >
>

More information about the Dxspider-support mailing list