Re: HBLink and HBLink3

Cort N0MJS <n0mjs@...>

HBlink has to do a little more calculation of things than DMRlink does. In the respective confbridge applications (renamed just in hblink3), hblink has to calculate the complete LC and the embedded LC pieces for each new stream. It turns out that’s not too big of a deal. DMRlink and HBlink should be pretty close in how much resources they “hog”. There are some other things I want to fix – like depending on a unique stream ID to tell one call stream from another… that will reduce processing time, and as it turns out, statistically, the chances of two identical stream IDs on the same slot at the same time is….. a lot lower than the likelihood I’ll get killed by someone drink driving tomorrow night.

Here’s the bad news. K0USY Group has chosen (it’s not me, it’s actually a group) to pull our Motorola XPR series repeaters out of service and sell them. We’re replacing them with Motorola MTR2000s and MMDVM. We’re going to be going 100% MMDVM on our own network. This has the dubious result of eliminating my testbed for Motorola IPSC. I’m actually supportive of that because it best serves K0USY Group’s goals.

At this point it’s uncertain whether or not I’ll have the time to migrate DMRlink to Python3. DMRlink may end up being sunset and only bug-fixes in the future. I live in two worlds – the Kansas DMR network in the US, and these projects. My own radio network has decided that MMDVM is the way of the future, and is moving that way. It will have the effect of moving me with it to a great degree.

Nothing is final – nothing ever is. But the one thing we learned on KS-DMR since beginning operations in 2010 is that IPSC was great for what it was intended for. Within that scope, it’s hands-down far better than HomeBrew. But, the majority of what we (KS-DMR, probably others too) do with Ham radio is outside the intended scope of IPSC, and HomeBrew makes a better platform for what we do as hams. I’ve decided that, elegant as it is, the “simulated multicast” over unicast networking methodology of IPSC is simply too complicated to troubleshoot with more than a few repeaters and a number of random internet connections.

Likewise, IPSC is inefficient run as a one-repeater, one-bridge per “IPSC system”… you know like the c-Bridge guys do who talk about “one repeater per manager”. IPSC’s glory is wasted when you use it that way, and HomeBrew actually becomes  much better protocol.

I guess this turned into a bit of a rant about ham radio DMR – and I most assuredly will be really pissing someone off with it. I do not intend to abandon DMRlink, but the writing is kinda on the wall…. IPSC just isn’t the right protocol to build wide-area networks with lots of repeaters.

On Jan 2, 2019, at 4:20 PM, Peter M0NWI <peter-martin@...> wrote:

All sounds interesting!! 

Will DMRlink get the Python3 hurry up as some stage?  Although I have to say, even on my meagre VM With ~10 Moto repeaters, IPSC bridge to a few MMDVM on HBlink, I’ve never noticed any performance issues!! 

Is HBLink more of a performance hog that IPSC?


From: <> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 02 January 2019 22:12:38
Subject: Re: [DVSwitch] HBLink and HBLink3
HBlink 3 is non-functional at this point. It will not work. It is on GitHub because I use GitHub to sync multiple computers I do development on.

Once HBlink3 is completed and has parity with HBlink, HBlink will be depreciated and all new development will be with HBlink3. The 3 means it runs on Python3. There are a number of advantages to moving to Python3 – which wasn’t possible when I began the project. Once I have everything working, the next move will be to pull twisted out from underneath it and replace it with a combination of asyncio and uvloop. This should bring network performance close to that of a compiled machine code program.

A bit of a deeper dive for those who are interested. A few weeks ago we did some heavy duty performance measurement on the K0USY KS-DMR network – where we run my tools in production. We wanted to know how far this thing will scale with modest resources. What we ended up finding out is that the network calls through twisted are the most costly in terms of time. Twisted is a GREAT module, don’t get me wrong. But we really don’t use it the way it was intended. We use fairly low-level pieces, of which there are much faster options in Python3. How much faster? Two orders of magnitude.

That’s the roadmap as of now – get HBlink3 working, then migrate to different underlying network modules.

On Jan 2, 2019, at 3:43 PM, Kim-Benjamin Lütkemeier via Groups.Io <kbluetkemeier@...> wrote:

the HBlink and HBlink3 has the same status?

You add some functions on booth version or you only support HBLink3 now?

Good Job

Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206

Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206

Join to automatically receive all group messages.