[aprssig] APRS Cron Object Injector

[Steve Dimse]

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