Re: If you use HBlink OR dmr_utils, you need to read this


JJ Cummings
 

Cort - great stuff I just switched over so the stack now looks like this (for those that care)

DMRLink <-> IPSC_Bridge <-> HB_Bridge <-> hblink3(bridge) <-> Analog_Bridge <-> ASL

On a separate note, I noted a an error in the log specifically related  to openbridge (outbound only connections) looks like it's not registering that the END event has occurred when it happens and thusly it times out?.  Posting here but hopefully I can post a pull request if ever I get time to debug at all.

INFO 2019-01-14 14:16:30,526 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 2752969323 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.02
INFO 2019-01-14 14:16:35,780 (OBP-3103) *TIME OUT*   STREAM ID: 2752969323 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.02
INFO 2019-01-14 14:19:21,827 (ANALOG_BRIDGE) *CALL START* STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1
INFO 2019-01-14 14:19:21,878 (ANALOG_BRIDGE) Conference Bridge: 310815, Call Bridged to OBP System: OBP-3103 TS: 1, TGID: 310815
INFO 2019-01-14 14:19:24,859 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.03
INFO 2019-01-14 14:19:30,780 (OBP-3103) *TIME OUT*   STREAM ID: 205043449 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.03

On Fri, Jan 11, 2019 at 11:04 AM Cort N0MJS via Groups.Io <n0mjs=me.com@groups.io> wrote:
Folks,

PYTHON2 BASED VERSIONS OF HBLINK AND DMR_UTILS ARE NOW SUNSET – ONLY BUG FIXES WILL BE OFFERED.



If you go looking at my repos on GitHub, you’ll see a couple of new things:

HBlink3 and dmr_utils3

These are Python3 versions of HBlink and dmr_utils. Currently, dmr_utils3 does not include ambe_bridge.py and HBlink3 does not include parrot or bridge_all – effectively leaving it as the base stack and the conference bridge application… there have also been some things renamed. I removed “hb_” from the beginning of all of the files, and I also renamed hb_confbridge.py to bridge.py. Likewise I renamed hb_confbridge_rules.py to rules.py. The main goal with the name changes is to make the first character or few unique. I’m a shitty typist to begin with, so being able to type b(tab) and get bridge.py is a lot easier than having to type out hb_confbridge.py all of the time… and I have to type those things a lot when I’m in full-on coding mode :)

As for the future of the other HBlink programs – some of that is going to be dependent on community support. I would love to see someone step up and port all_bridge.py and parrot.py to Python3. I will eventually get to them, but not soon because….

The master branch of HBlink3 is stable and has been running on the K0USY Group’s “KS-DMR” network all week. On our particular system, with the things we have configured, just moving to Python3 (ok, a few bits of refactoring as well) has given us a 15-20% performance boost (measured in time between packet ingress and processing completion). You will also notice another branch of HBlink3 called uvloop. With this branch I’m swapping out the venerable Twisted module for Python3’s built-in Asyncio module, and a “drop in replacement” for portions of it called uvLoop, an ultra-fast drop-in replacement for parts of Asyncio… just moving to Python3 gave us a nice bump. My hope is that the move to uvloop makes HBlink work much faster – potentially rivaling statically compiled to machine-code software.

I’ve already moved off of the master branch to work on the uvloop branch. This development will be rapid – because the goal is to have hblink.py and bridge.py working on uvloop ASAP. Once that is completed, I will go back and start filling in the gaps as well as adding features. I do not intend to back-port new features to the Python2 versions.

The HBlink3 master branch will support the existing python2 hbmonitor software. The uvloop branch will not. I intend to “burn down” the reporting “stuff” and start over with HBlink3 on uvloop. I am looking for javascript (and related browser code) developers to help with this. Hbmonitor is a bandwidth HOG. It renders the entirety of the HTML tables on the server for every incremental change, and pushes all of that HTML out to the browser. A busy system on HBmonitor can use close to 1Mbps of bandwidth for a single browser connected. The goal is to send much less information to the browser, and let the browser build the tables… but I don’t have a clue about programming that stuff. Co-developers welcome!!!

0x49 DE N0MJS



Cort Buffington
785-865-7206




Join main@DVSwitch.groups.io to automatically receive all group messages.