[P25nx] Welcome

[Dan Woodie]

On Wed, Jul 25, 2018 at 9:31 PM Bryan Fields <Bryan at bryanfields.net> wrote:

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


I am pretty sure you can assign more than one owner and also transfer
owners.  I know I can on my corporate account - but that might be specific
to those accounts.  Understood.  There are pros and cons to every service.

>

> 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.
>
> So stating that access was removed to archives might have been a bit of an
aggressive statement - they are as you say still available - but now they
are fragmented.  Manageable but less convenient.  For new members they
should be added to both lists to make sure they have access to the
archives.  The Google Groups threading does work - but it is highly reliant
on the subject line remaining the same - as soon as it changes it doesn't
thread properly - valid point.


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

Valid option - I will see how it goes here.


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

Asking valid questions and starting a discussion is not wasting time.  I am
very close to getting this going - but I couldn't find the link to the file
share for the images - is it still up?

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

LoS = Level of Service Agreement - signed with carriers.  QoS is also very
important on private networks but doesn't really apply to the internet.

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

The P25 data streams I deal with are not usually raw P25 links over STUN -
they are generally links over the Astro RNI on 7.x Astro systems.  These
have FEC, QoS, and other methods that are used to ensure the voice traffic
is delivered intact.

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

I agree, my thought, similar to yours, was to use multiple parallel streams
staggered then apply a delay at the receiving end while the superframes are
error checked and reassembled if necessary.   The packets would have to be
numbered somehow.  Beyond packet loss another issue is multi-path as
sometimes the data will take different routes - and might show up out of
order.  Delaying the traffic by 200-300 ms beyond what it is now probably
wouldn't be that noticeable - unless you have two systems co-located and
two radios, talking into one and listening to the other.

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

I look forward to seeing some new development work and would be happy to
help where I can.  I hope to have the local repeaters back online soon, as
soon as I can procure the latest image and load it into a VM.

Thanks.

Dan Woodie, CETsr
KC8ZUM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/p25nx-interest/attachments/20180726/a43d18d0/attachment.html>