[aprssig] APRS Cron Object Injector

Mon Mar 23 20:06:50 EDT 2015

I'm not going to bother responding to Steve line by line, but it seems
like the issue comes down to differing objectives, as well as the
tendency on here to take single sentences out of context to disagree
with them.

If you're only interested in tracking your vehicle online, then sure,
local info objects are a waste of bandwidth, them clustering at the
top of the minute/interval is perfectly fine, and them overwhelming
any local RF LAN isn't important. Amortizing CSMA costs is different
than beaconing so many objects that token buckets and buffers run out
and half of the objects are NEVER gatewayed to RF.

My paragraph on interval dithering isn't supported in anything I
actually wrote in my thesis, but I still believe it's a more correct
behavior.  Let's not confuse my gut feeling in that one paragraph with
calling my entire thesis theoretical. I put a tremendous amount of
effort into producing an applied thesis with useful, actionable
conclusions.  I do not appreciate how many armchair reviewers have
questioned the overall value of my work. The next grad student that
asks me for help on what to do for their thesis gets at least five
different choices on what parts of APRS they can work on; there is
plenty of science left to examine here.

Just because you have a bad attitude about the future of APRS doesn't
mean you need to discount my work on it. I'm not trying to fix all of
APRS here; just enable everyone to make new parts of it slightly
better.

Minimalistic isn't the same thing as simple; accomplishing something
in fewer lines of code isn't necessarily better than exposing fewer
parameters for the user to get wrong. I've hidden the concept of
interval offset, because it's not something users should have to worry
about or understand. Most of those 100 lines of code are defensive
programming to try and keep bad packets off the APRS network.

I'm not really interested in having philosophical debates about every
behavioral decision I make in my APRS code; I just spent a year having
those arguments with myself (and reading the last 10 years worth of
them on the APRSsig archives) while earning a masters degree.

I think APRS Cron Injector is a valuable reference design, and will
happily answer any questions specifically about it.
https://github.com/PhirePhly/aprs_cron_injector

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/

On Mon, Mar 23, 2015 at 5:52 AM, Steve Dimse <steve at dimse.com> wrote:
>
> On Mar 22, 2015, at 11:55 PM, Kenneth Finnegan <kennethfinnegan2007 at gmail.com> wrote:
>
>> On Sun, Mar 22, 2015 at 7:55 PM, KF4LVZ <aprssigZbr6 at acarver.net> wrote:
>>> For any user that does need regularity in the beacon (without a random
>>> delay)
>>
>> Why would users want regularity in APRS-IS beaconing?
>
> For example, things like telemetry and weather. There is a big difference in the graphs between a one with a data point every 5 minutes and one with datapoints randomly spaced with a 5 minute average.
>
>> My script still
>> ensures that the average interval is exactly what the user specifies,
>> so what is the advantage of hammering the APRS network on the top of
>> any minute?
>
> The effect is hardly hammering. Yes, the APRS IS shows higher traffic at the top of some minutes, but there is plenty of capacity. The number of packets that make it from the APRS IS to a given local RF network are very small. Most of those are user driven events like messages which are self-randomizing.
>
> If a local network has a lot of fixed stations beaconing at the top of the minute (and likely at minute 0, 15,30, and 45 or other specific minutes), it would not necessarily be a bad thing as most of the packets will still get organized at digipeaters, they are the less important traffic anyway, and that will leave the channel with less load the rest of the time.
>
>> APRS channel access depends on being a stochastic process;
>> based on the original Abramson AHOLA models, introducing entropy
>> should improve overall APRS network performance.
>>
>> I mentioned dithering in section 7.1.4 of my thesis, but sadly didn't
>> have the time to expand on the evidence I had collected showing the
>> poor level of entropy on the current network.
>
> It is impressive you managed to extract enough science out of APRS to fulfill your thesis requirement. However don't expect that to translate into changes in APRS, APRS doesn't work that way. APRS is a giant, home-made swiss army knife with things duct-taped and hot-glued all over it. It is ugly. It was built by people who cared about making something work, not making it pretty, and certainly not about optimizing entropy! Stuff only changes when it doesn't work.
>
>> Congestion on the
>> network collects around even intervals, even while the channel is
>> relatively empty. http://digitalcommons.calpoly.edu/theses/1341/
>
> Your thesis, and this conclusion, is theoretical, is it not? I don't see any methods describing how you actually measured what was happening on RF. Indeed, that is quite difficult and you would either need people cooperating all over to send you TNC outputs without the de-duplication of the APRS IS. And again, I would argue that things that collect around even intervals actually improve the network by making more bandwidth available the rest of the time for unscheduled packets of more import.
>>
>> This is a minimalistic solution.
>
> Nothing that involves github and a hundred+ lines of code is minimalistic! What I do, adding a one line delay to time the packet entry to a known lull in the network is minimal.
>
>> Why should users be depended upon to
>> correctly pick a random offset themselves? That's what the current
>> scripts depend upon, and users keep picking zero.
>
> This is not a matter of users but of programmers. Early on we saw a problem which showed itself on MacAPRS and the HF network, and so MacAPRS was changed to use the time it started up as its "zero second". Problem went away. Now there are dozens of different devices and programers, each doing things differently enough that there is quite a bit of spread. That is actually one of the themes of your paper, is it not?
>
>> By the time they
>> have the understanding to properly offset their beacons, I would hope
>> they're no longer using a cron job to beacon their objects.
>
> I suspect VERY few use a cron job now. Most mobiles are free-running microcontrollers without time sync and certainly without cron. Most APRS programs are monolithic, and while many may poll the clock and wait for the minute to roll over, they aren't using cron.
>
> Here is some actual data, off the top of my head I picked 20150320 at 1300 UTC, counting the timestamps on findU for the minute:
>
> 0: 86
> 1: 120
> 2: 220
> 3: 142
> 4: 198
> 5: 140
> 6: 127
> 7: 147
> 8: 152
> 9: 111
> 10: 96
> 11: 132
> 12: 110
> 13: 113
> 14: 117
> 15: 85
> 16: 89
> 17: 117
> 18: 99
> 19: 88
> 20: 72
> 21: 81
> 22: 105
> 23: 81
> 24: 80
> 25: 85
> 26: 85
> 27: 72
> 28: 73
> 29: 90
> 30: 74
> 31: 73
> 32: 81
> 33: 68
> 34: 84
> 35: 72
> 36: 81
> 37: 73
> 38: 75
> 39: 67
> 40: 61
> 41: 63
> 42: 60
> 43: 74
> 44: 76
> 45: 62
> 46: 57
> 47: 56
> 48: 75
> 49: 41
> 50: 78
> 51: 65
> 52: 62
> 53: 51
> 54: 53
> 55: 73
> 56: 61
> 57: 57
> 58: 81
> 59: 50
>
> But this is all findU traffic, specifically including CWOP, which is entirely internet based. If I do the same query excluding CWxxx, DWxxxx, and EWxxxx I get this
>
> 0: 56
> 1: 93
> 2: 170
> 3: 96
> 4: 112
> 5: 82
> 6: 76
> 7: 96
> 8: 104
> 9: 76
> 10: 59
> 11: 75
> 12: 78
> 13: 74
> 14: 88
> 15: 57
> 16: 48
> 17: 67
> 18: 63
> 19: 61
> 20: 54
> 21: 62
> 22: 76
> 23: 64
> 24: 54
> 25: 63
> 26: 60
> 27: 48
> 28: 49
> 29: 66
> 30: 55
> 31: 54
> 32: 61
> 33: 55
> 34: 54
> 35: 53
> 36: 63
> 37: 54
> 38: 56
> 39: 50
> 40: 44
> 41: 48
> 42: 38
> 43: 54
> 44: 57
> 45: 48
> 46: 47
> 47: 41
> 48: 58
> 49: 31
> 50: 60
> 51: 54
> 52: 47
> 53: 39
> 54: 44
> 55: 56
> 56: 48
> 57: 47
> 58: 63
> 59: 41
>
> So this clearly shows the top of the minute effect. However it is only roughly a doubling that lasts a few seconds. Most minutes do not show this effect, here are the next two minutes
>
> 0: 49
> 1: 62
> 2: 49
> 3: 53
> 4: 43
> 5: 58
> 6: 75
> 7: 48
> 8: 46
> 9: 88
> 10: 58
> 11: 51
> 12: 43
> 13: 66
> 14: 62
> 15: 49
> 16: 35
> 17: 165
> 18: 36
> 19: 46
> 20: 38
> 21: 66
> 22: 43
> 23: 50
> 24: 59
> 25: 35
> 26: 78
> 27: 51
> 28: 56
> 29: 42
> 30: 42
> 31: 57
> 32: 42
> 33: 55
> 34: 51
> 35: 69
> 36: 36
> 37: 55
> 38: 48
> 39: 42
> 40: 40
> 41: 57
> 42: 48
> 43: 60
> 44: 56
> 45: 53
> 46: 48
> 47: 47
> 48: 50
> 49: 51
> 50: 36
> 51: 46
> 52: 43
> 53: 44
> 54: 51
> 55: 47
> 56: 47
> 57: 55
> 58: 54
> 59: 64
>
> 0: 52
> 1: 56
> 2: 68
> 3: 53
> 4: 60
> 5: 68
> 6: 59
> 7: 53
> 8: 75
> 9: 76
> 10: 49
> 11: 49
> 12: 50
> 13: 45
> 14: 39
> 15: 44
> 16: 45
> 17: 46
> 18: 39
> 19: 46
> 20: 45
> 21: 56
> 22: 50
> 23: 52
> 24: 39
> 25: 39
> 26: 53
> 27: 49
> 28: 47
> 29: 53
> 30: 48
> 31: 61
> 32: 57
> 33: 38
> 34: 53
> 35: 52
> 36: 55
> 37: 54
> 38: 53
> 39: 51
> 40: 55
> 41: 47
> 42: 41
> 43: 44
> 44: 49
> 45: 32
> 46: 66
> 47: 35
> 48: 51
> 49: 55
> 50: 47
> 51: 53
> 52: 50
> 53: 42
> 54: 50
> 55: 45
> 56: 51
> 57: 46
> 58: 52
> 59: 33
>
> The peak at 20150320130117 is odd so I looked at it and it is caused by a list of russian repeater objects all dumped at once on the internet like
>
> RR9LA>R0,qAS,rptr1:=5708.67N/06533.32Er R0 FM repiter 145600kHz
>
> There's a bad citizen for you!
>
> But back to the topic at hand.
>
> I have a traffic graph I use to monitor findU, this measures the raw packets processed every minute, by using large sizes I can space out the lines so each minute is visible:
>
> http://www.findu.com/cgi-bin/aprsis.cgi?last=5&xsize=2000&ysize=500
>
> There is clearly a pattern here, but most of it is the CWOP data.
>
> So the data shows there is peak use in the 15 seconds at the top and half hour, smaller peaks at the 5s in between. The higher rates are happening much less than 5% of the time. And this is the worst case, the internet side including CWOP, and it is not causing a problem there.
>
> I just don't see this as an issue that requires action.
>
> Steve K4HG
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig