<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 9:31 PM Bryan Fields <<a href="mailto:Bryan@bryanfields.net">Bryan@bryanfields.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7/25/18 1:29 AM, Dan Woodie wrote:<br>
> Bryan,<br>
> <br>
> What prompted the switch from Google Groups? As far as I could tell there<br>
> was no issue with the way it was working. <br>
<br>
It was tied to David's personal account, and it's not possible to move that.<br>
Google also prevents anyone from downloading the archives. There is the total<br>
lack of any support with google, it's a best effort service. If it goes<br>
sideways, you don't have any options.</blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The way I see it you just took a<br>
> struggling project and removed access to the archives of valuable<br>
> information and switched to a mail list with a more archaic interface. <br>
<br>
How so, the archives are still on google groups if you want to search them.<br>
As the group on google was set to private, it wasn't indexed unless you were<br>
signed in and in their "interface".<br>
<br>
Perhaps the largest issue with google groups is the lack of inserting a ID in<br>
the subject and the poor support of threading.<br>
<br></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I<br>
> use Google Groups all the time and have had no issues whatsoever. Now, if<br>
> you were switching from Yahoo Groups I might support the move. I for one<br>
> vote for a switch back to the Google Group.<br>
<br>
Then post there.<br></blockquote><div><br></div><div>Valid option - I will see how it goes here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I am considering bringing the K8BIG repeaters back online as V2 but have<br>
> been a bit concerned about the stability issues - so I haven't wasted my<br>
> time - which I don't have much of these days. <br>
<br>
Then don't waste ours.<br></blockquote><div><br></div><div>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? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Regarding the dropped audio packets on the network - we deal with that at<br>
> work frequently when customers don't purchase their leased lines/MPLS<br>
> Circuits with appropriate LoS agreements. <br>
<br>
QoS?<br></blockquote><div><br></div><div>LoS = Level of Service Agreement - signed with carriers. QoS is also very important on private networks but doesn't really apply to the internet. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> The P25 data streams can deal<br>
> with some latency and packet loss <br></blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
They cannot deal with any packet loss. In the current system, every 20 ms<br>
frame is shoved onto the network, and due to the p25 super frame format,<br>
losing a couple frames can nuke the larger super frame. There is no error<br>
handling or counters to know where or if drops are happening.<br>
<br>
> but high-jitter, high latency networks<br>
> such as the internet are not ideal. I suspect most of the issues are due<br>
> to this. If a carrier's network gets busy it just dumps the traffic into a<br>
> "Best Effort" pool and sends it when the bandwidth is available - if the<br>
> bandwidth doesn't become available within a specified time window the<br>
> packets are simply dropped. <br>
<br>
The internet is all best effort. Once I hit a peering point my DSCP is going<br>
to be ignored or rewritten to CS0. Given the propensity of carriers using<br>
unbuffered chipsets in the backbone now, even a lightly loaded link can drop<br>
packets due to bursts.<br>
<br>
> Other than adding buffering of some sort I<br>
> don't know if there is a good solution to this. <br>
<br>
My thoughts were to have some counters and options for multiple packets. the<br>
bitstream is like 6.7 kbit/s, just elect to receive 2 packets, and discard<br>
one. It's basically cheap FEC, and the difference between 6.7 and 13kbit/s is<br>
nothing on today's internet.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At one time I was working with a friend on this in Go, but not much has<br>
happened with it due to work.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks.</div><div><br></div><div>Dan Woodie, CETsr</div><div>KC8ZUM</div><div><br></div></div></div>