[P25nx] Welcome

[Bryan Fields]

On 7/25/18 1:29 AM, Dan Woodie wrote:
> Bryan,
> 
> What prompted the switch from Google Groups?  As far as I could tell there
> was no issue with the way it was working.  

It was tied to David's personal account, and it's not possible to move that.
Google also prevents anyone from downloading the archives.  There is the total
lack of any support with google, it's a best effort service.  If it goes
sideways, you don't have any options.

> The way I see it you just took a
> struggling project and removed access to the archives of valuable
> information and switched to a mail list with a more archaic interface.  

How so, the archives are still on google groups if you want to search them.
As the group on google was set to private, it wasn't indexed unless you were
signed in and in their "interface".

Perhaps the largest issue with google groups is the lack of inserting a ID in
the subject and the poor support of threading.

> I
> use Google Groups all the time and have had no issues whatsoever.  Now, if
> you were switching from Yahoo Groups I might support the move.  I for one
> vote for a switch back to the Google Group.

Then post there.
> I am considering bringing the K8BIG repeaters back online as V2 but have
> been a bit concerned about the stability issues - so I haven't wasted my
> time - which I don't have much of these days.  

Then don't waste ours.

> Regarding the dropped audio packets on the network - we deal with that at
> work frequently when customers don't purchase their leased lines/MPLS
> Circuits with appropriate LoS agreements.  

QoS?

> The P25 data streams can deal
> with some latency and packet loss 

They cannot deal with any packet loss.  In the current system, every 20 ms
frame is shoved onto the network, and due to the p25 super frame format,
losing a couple frames can nuke the larger super frame.  There is no error
handling or counters to know where or if drops are happening.

> but high-jitter, high latency networks
> such as the internet are not ideal.  I suspect most of the issues are due
> to this.  If a carrier's network gets busy it just dumps the traffic into a
> "Best Effort" pool and sends it when the bandwidth is available - if the
> bandwidth doesn't become available within a specified time window the
> packets are simply dropped.  

The internet is all best effort.  Once I hit a peering point my DSCP is going
to be ignored or rewritten to CS0.  Given the propensity of carriers using
unbuffered chipsets in the backbone now, even a lightly loaded link can drop
packets due to bursts.

> Other than adding buffering of some sort I
> don't know if there is a good solution to this.  

My thoughts were to have some counters and options for multiple packets.  the
bitstream is like 6.7 kbit/s, just elect to receive 2 packets, and discard
one.  It's basically cheap FEC, and the difference between 6.7 and 13kbit/s is
nothing on today's internet.

At one time I was working with a friend on this in Go, but not much has
happened with it due to work.
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net