Date   

Re: fob startup - was: DAHDI timing and ASL

Steve N4IRS
 

Ken,
Thanks for Googleing that for me. ;) We have a list of bugs (and fixes) I'll see if I can correlate. If not, I'll add it. Since most of the changes are not published, any info would help.

Steve

On 12/30/19 3:59 PM, Ken KE2N via Groups.Io wrote:
My experience is with the usbradio channel. Not sure if it will happen with simple usb.

The "fix" could be a hack as you say.  Although, if the hardware requires it ... then you might say it's a feature ;-)

To me it seems like some pipeline underflows, or overflows, right at the start.  My observation is that it happens when ASL tries to key up the radio and talk ... essentially at the same time.  It does not happen *every* time.  But I heard the effect three times in a short while after starting the repeater up last night.  And I think I heard one chopped up CW ID today sometime. Once the audio gets going, it's fine.

People whose radios are slow to open the squelch will never have heard this.  They will also never have heard the first letter of the repeater ID on a cold key-up (and probably don't care anyway).

Doing a Google search I am reminded that this fix was for simple usb (I do not know if it is applicable to usbradio - as you know, that driver is not favored in the other flavor of asterisk controller).

Re-reading the text below (which google just found for me), this fix was actually intended for another problem. Although it might also fix the issue I am talking about.

... the simpleusb driver continues
> to send frames of silence to the audio adapter at all times; even when the
> transmitter (PTT) isn't active. This reduces the impact of the variable
> start-up latency issues which simpleusb has classically exhibited.


fob startup - was: DAHDI timing and ASL

Ken KE2N
 

My experience is with the usbradio channel. Not sure if it will happen with simple usb.

The "fix" could be a hack as you say.  Although, if the hardware requires it ... then you might say it's a feature ;-)

To me it seems like some pipeline underflows, or overflows, right at the start.  My observation is that it happens when ASL tries to key up the radio and talk ... essentially at the same time.  It does not happen *every* time.  But I heard the effect three times in a short while after starting the repeater up last night.  And I think I heard one chopped up CW ID today sometime. Once the audio gets going, it's fine.

People whose radios are slow to open the squelch will never have heard this.  They will also never have heard the first letter of the repeater ID on a cold key-up (and probably don't care anyway).

Doing a Google search I am reminded that this fix was for simple usb (I do not know if it is applicable to usbradio - as you know, that driver is not favored in the other flavor of asterisk controller).

Re-reading the text below (which google just found for me), this fix was actually intended for another problem. Although it might also fix the issue I am talking about.

... the simpleusb driver continues
> to send frames of silence to the audio adapter at all times; even when the
> transmitter (PTT) isn't active. This reduces the impact of the variable
> start-up latency issues which simpleusb has classically exhibited.


Re: DAHDI timing and ASL

Steve N4IRS
 

Ken,
Not sure what you mean by running the data stream continuously. I'm thinking a startup delay may help, but both seem like a hack rather then a fix. What channel driver are you seeing this with?

Steve N4IRS

On 12/30/19 1:43 PM, Ken KE2N via Groups.Io wrote:
This (dahdi_dummy) worked well with my RPI3 and it even helped results on a big hulking quad core machine, by raising the occasional worst-case result..

The remaining problem that I see with ASL1.01 is - for lack of a better name - usb fob startup.  When the repeater has been quiet and decides to spit out a morse or voice ID, sometimes the first morse character or the first syllable or two of the voice comes out choppy. 

In the other camp I believe they fixed this problem by running the data stream continuously, is that hard to do?

Ken


Re: DAHDI timing and ASL

Ken KE2N
 

This (dahdi_dummy) worked well with my RPI3 and it even helped results on a big hulking quad core machine, by raising the occasional worst-case result..

The remaining problem that I see with ASL1.01 is - for lack of a better name - usb fob startup.  When the repeater has been quiet and decides to spit out a morse or voice ID, sometimes the first morse character or the first syllable or two of the voice comes out choppy. 

In the other camp I believe they fixed this problem by running the data stream continuously, is that hard to do?

Ken


Re: DAHDI timing and ASL

Andrew Koenig
 

Steve,

This really seemed to do the trick with the dahdi_test results. I'm really looking forward to audio reports from users.

Any idea on why that line was commented out?

I'll be sure to pass the thanks along to Bryan as well.

73 de KE5GDB

====================

From an RPi 2B+ w/ ASL 1.01:

root@43776-BridgePi:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.618% 99.565% 99.620% 99.631% 98.447% 99.601% 99.602% 99.603%
99.601% 98.445% 99.598% 99.601% 99.585% 99.617% 98.436% 99.593%
99.601% 99.601% 99.597% 98.441% 99.603% 99.601% 99.572% 99.630%
98.445% 99.600% 99.609% 99.594% 99.592% 98.480% 99.601% 99.647%
99.601% 99.600% 98.445% 99.602% 99.602% 99.573% 99.629% 98.486%
99.600% 99.595% 99.650% 99.601% 98.491% 99.601% 99.599% 99.648%
99.605% 98.508% 99.612% 99.600% 99.648% 99.602% 98.489% 99.583%
99.636% 99.621% 99.607% 98.450% 99.610% 99.593% 99.605% 99.602%
98.444% 99.545% 99.653% 99.600% 99.605% 98.447% 99.592% 99.600%
99.606% 99.600% 98.442% 99.593% 99.605% 99.598% 99.610% 98.456%
99.537% 99.626% 99.639% 99.611% 98.450% 99.601% 99.602% 99.601%
99.603% 98.447% 99.602% 99.601% 99.602% 99.613% 98.450% 99.597%
99.601% 99.600%
--- Results after 98 passes ---
Best: 99.653% -- Worst: 98.436% -- Average: 99.382118%
Cumulative Accuracy (not per pass): 99.980
root@43776-BridgePi:~# modprobe dahdi_dummy
root@43776-BridgePi:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.986% 99.981% 99.991% 99.992% 99.991% 99.992% 99.992% 99.992%
99.993% 99.988% 99.992% 99.992% 99.992% 99.993% 99.991% 99.991%
99.991% 99.991% 99.992% 99.990% 99.992% 99.992% 99.991% 99.993%
99.991% 99.991% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992%
99.991% 99.991% 99.991% 99.992% 99.991% 99.992% 99.992% 99.991%
99.992% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992% 99.992%
99.992% 99.990% 99.992% 99.992% 99.992% 99.993% 99.991% 99.992%
99.992% 99.991% 99.992% 99.992% 99.992% 99.992% 99.992% 99.991%
99.992% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992% 99.992%
99.992% 99.991% 99.991% 99.992% 99.992% 99.992% 99.992% 99.991%
99.992% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992% 99.992%
99.992% 99.991% 99.991% 99.990% 99.991% 99.992% 99.992% 99.992%
99.992% 99.991%
--- Results after 98 passes ---
Best: 99.993% -- Worst: 99.981% -- Average: 99.991408%
Cumulative Accuracy (not per pass): 99.991
root@43776-BridgePi:~#

RPi 2B+ w/ DIAL:

root@Rosston220:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.999% 99.989% 99.991% 99.980% 99.995% 99.994% 99.996% 99.995%
99.999% 99.986% 99.989% 99.985% 99.993% 99.995% 99.996% 99.995%
99.996% 99.993% 99.997% 99.992% 99.994% 99.981% 99.992% 99.993%
99.997% 99.616% 99.996% 99.615% 99.986% 99.993% 99.626% 99.613%
99.987% 99.992% 99.628% 99.613% 99.997% 99.990% 99.980% 99.997%
99.995% 99.993% 99.993% 99.995% 99.995% 99.995% 99.986% 99.993%
99.992% 99.993% 99.987% 99.625% 99.601% 99.993% 99.995% 99.995%
99.993% 99.985% 99.983% 99.615% 99.600% 99.995% 99.993% 99.615%
99.602% 99.612% 99.991% 99.602% 99.613% 99.603% 99.997% 99.992%
99.994% 99.613% 99.602% 99.612% 99.601% 99.996% 99.996% 99.990%
99.992% 99.981% 99.994% 99.994% 99.996% 99.993% 99.994% 99.999%
99.999% 99.991% 99.988% 99.990% 99.993% 99.989% 99.990% 99.986%
99.993% 99.994%
--- Results after 98 passes ---
Best: 99.999% -- Worst: 99.600% -- Average: 99.914483%
Cummulative Accuracy (not per pass): 99.993
root@Rosston220:~# modprobe dahdi_dummy
root@Rosston220:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.990% 99.979% 99.980% 99.992% 99.991% 99.988% 99.994% 99.995%
99.995% 99.994% 99.994% 99.995% 99.994% 99.996% 99.993% 99.995%
99.995% 99.996% 99.995% 99.988% 99.988% 99.995% 99.994% 99.996%
99.993% 99.994% 99.995% 99.995% 99.996% 99.994% 99.995% 99.995%
99.995% 99.995% 99.993% 99.994% 99.995% 99.998% 99.992% 99.991%
99.988% 99.994% 99.995% 99.996% 99.993% 99.995% 99.995% 99.997%
99.994% 99.987% 99.987% 99.995% 99.994% 99.996% 99.993% 99.994%
99.994% 99.994% 99.997% 99.987% 99.991% 99.991% 99.989% 99.996%
99.993% 99.994% 99.994% 99.995% 99.995% 99.994% 99.995% 99.995%
99.995% 99.995% 99.995% 99.995% 99.995% 99.994% 99.995% 99.995%
99.995% 99.995% 99.995% 99.995% 99.995% 99.995% 99.995% 99.995%
99.995% 99.994% 99.994% 99.994% 99.994% 99.996% 99.993% 99.997%
99.991% 99.990%
--- Results after 98 passes ---
Best: 99.998% -- Worst: 99.979% -- Average: 99.993478%
Cummulative Accuracy (not per pass): 99.994
root@Rosston220:~#


Re: Allison Ducking

Adam KC1KCC
 

Looks like we missed ducking for local rx.  It’s currently only ducking for remote.  I’ll submit a pull request later on this evening.

Adam KC1KCC


Allison Ducking

Steve N4IRS
 
Edited

Just a quick note for now.
Adam KC1KCC and Mike N4IRR have ported the Allison ducking code from Steve W9SH to the DVSwitch fork of ASL. We are still testing but we know that you can now reduce or increase the level of Allison sent to a connected radio, USRP (Analog_Bridge) or DVSM. We are still testing the actual reduction of Allison level if there is a inbound signal. This should be considered a work in progress.
Add these settings to the node stanza of rpt.conf:

telemnomdb = -10
telemduckdb = -10
 
;down = -30
;up = 10
;normal = 0
 


Steve N4IRS


Text messaging support added to chan_usrp

Steve N4IRS
 

Mike has added text messaging support to chan_usrp and app_rpt. The text messages are used by DVSM and it's also nice to be able to send a pop up message to the client.
I have checked in the change to the DVSwitch Asterisk repo.


Re: DAHDI timing and ASL

G7RPG - Peter Kendall
 

My Bad,
Thanks Bryan, really appropriated.

Just to add a bit more to this.

Hamvoip on RPi4

--- Results after 210 passes ---
Best: 100.000% -- Worst: 99.940% -- Average: 99.993608%

Hamvoip on RPi2

--- Results after 152 passes ---
Best: 99.992% -- Worst: 99.969% -- Average: 99.982241%
Cummulative Accuracy (not per pass): 99.982


Peter

 


Re: DAHDI timing and ASL

Steve N4IRS
 

Peter,
Thanks for the result output. Looks great. As I said in my post, Bryan W9CR is the person that discovered what needed to be added.

73, Steve N4IRS

On 11/6/19 4:16 AM, G7RPG - Peter Kendall wrote:

Hi Steve,

Brilliant work. Just rolled it out across 6 VPS hubs.

 

Sample results:

Before (KVM based VPS)

Opened pseudo dahdi interface, measuring accuracy...
100.000% 99.993% 99.999% 99.997% 99.994% 99.998% 99.997% 99.999%
99.996% 99.993% 99.993% 99.999% 99.993% 99.996% 99.997% 99.982%
99.987% 99.981% 100.000% 99.993% 99.987% 99.985% 99.997% 99.981%
99.991% 99.622% 99.997% 99.991% 99.985% 99.980% 99.984% 99.990%
99.988% 99.989% 99.984% 99.999% 99.996% 99.990% 99.997% 99.997%
99.994% 99.997% 99.999% 99.997% 99.976% 99.998% 99.997% 99.995%
99.993% 99.995% 99.996% 99.990% 99.992% 99.996% 99.992% 100.000%
99.995% 99.995% 99.998% 99.983% 99.984% 99.979% 99.993% 99.996%
99.998% 99.993% 99.996% 99.994% 99.978% 99.997% 99.999% 99.997%
99.610% 99.983% 99.205% 99.225% 99.993% 100.000% 99.238% 99.234%
99.992% 99.995% 99.993% 99.211% 99.210% 99.219% 99.211% 99.997%
99.991% 99.992% 99.992% 99.994% 99.980% 99.999% 99.212% 99.222%
99.991% 100.000%
--- Results after 98 passes ---
Best: 100.000% -- Worst: 99.205% -- Average: 99.906028%
Cumulative Accuracy (not per pass): 99.998

After (KVM based VPS)

Opened pseudo dahdi interface, measuring accuracy...
99.990% 99.993% 99.998% 99.998% 99.999% 99.998% 99.999% 99.993%
99.998% 100.000% 99.996% 99.997% 99.998% 99.997% 99.999% 99.997%
99.998% 99.999% 99.997% 99.998% 99.998% 99.998% 99.998% 99.999%
99.999% 99.996% 99.998% 99.997% 99.999% 99.998% 99.997% 99.998%
99.998% 99.996% 99.997% 99.998% 99.996% 99.999% 99.997% 99.998%
99.999% 99.998% 99.998% 99.999% 99.996% 100.000% 99.995% 99.998%
99.998% 99.998% 99.998% 100.000% 99.998% 99.997% 99.999% 99.996%
99.998% 99.998% 99.997% 100.000% 99.995% 99.999% 99.996% 99.998%
99.997% 99.998% 99.998% 99.997% 99.998% 99.999% 99.997% 99.997%
100.000% 99.998% 99.996% 99.998% 99.997% 99.998% 99.998% 99.998%
99.999% 99.997% 99.998% 99.998% 99.998% 100.000% 99.996% 99.998%
99.994% 99.998% 99.998% 99.997% 99.997% 99.998% 99.999% 99.997%
99.998% 99.998%
--- Results after 98 passes ---
Best: 100.000% -- Worst: 99.990% -- Average: 99.997611%
Cumulative Accuracy (not per pass): 99.998


Best 73

Peter

G7RPG



Re: DAHDI timing and ASL

G7RPG - Peter Kendall
 

Hi Steve,

Brilliant work. Just rolled it out across 6 VPS hubs.

 

Sample results:

Before (KVM based VPS)

Opened pseudo dahdi interface, measuring accuracy...
100.000% 99.993% 99.999% 99.997% 99.994% 99.998% 99.997% 99.999%
99.996% 99.993% 99.993% 99.999% 99.993% 99.996% 99.997% 99.982%
99.987% 99.981% 100.000% 99.993% 99.987% 99.985% 99.997% 99.981%
99.991% 99.622% 99.997% 99.991% 99.985% 99.980% 99.984% 99.990%
99.988% 99.989% 99.984% 99.999% 99.996% 99.990% 99.997% 99.997%
99.994% 99.997% 99.999% 99.997% 99.976% 99.998% 99.997% 99.995%
99.993% 99.995% 99.996% 99.990% 99.992% 99.996% 99.992% 100.000%
99.995% 99.995% 99.998% 99.983% 99.984% 99.979% 99.993% 99.996%
99.998% 99.993% 99.996% 99.994% 99.978% 99.997% 99.999% 99.997%
99.610% 99.983% 99.205% 99.225% 99.993% 100.000% 99.238% 99.234%
99.992% 99.995% 99.993% 99.211% 99.210% 99.219% 99.211% 99.997%
99.991% 99.992% 99.992% 99.994% 99.980% 99.999% 99.212% 99.222%
99.991% 100.000%
--- Results after 98 passes ---
Best: 100.000% -- Worst: 99.205% -- Average: 99.906028%
Cumulative Accuracy (not per pass): 99.998

After (KVM based VPS)

Opened pseudo dahdi interface, measuring accuracy...
99.990% 99.993% 99.998% 99.998% 99.999% 99.998% 99.999% 99.993%
99.998% 100.000% 99.996% 99.997% 99.998% 99.997% 99.999% 99.997%
99.998% 99.999% 99.997% 99.998% 99.998% 99.998% 99.998% 99.999%
99.999% 99.996% 99.998% 99.997% 99.999% 99.998% 99.997% 99.998%
99.998% 99.996% 99.997% 99.998% 99.996% 99.999% 99.997% 99.998%
99.999% 99.998% 99.998% 99.999% 99.996% 100.000% 99.995% 99.998%
99.998% 99.998% 99.998% 100.000% 99.998% 99.997% 99.999% 99.996%
99.998% 99.998% 99.997% 100.000% 99.995% 99.999% 99.996% 99.998%
99.997% 99.998% 99.998% 99.997% 99.998% 99.999% 99.997% 99.997%
100.000% 99.998% 99.996% 99.998% 99.997% 99.998% 99.998% 99.998%
99.999% 99.997% 99.998% 99.998% 99.998% 100.000% 99.996% 99.998%
99.994% 99.998% 99.998% 99.997% 99.997% 99.998% 99.999% 99.997%
99.998% 99.998%
--- Results after 98 passes ---
Best: 100.000% -- Worst: 99.990% -- Average: 99.997611%
Cumulative Accuracy (not per pass): 99.998


Best 73

Peter

G7RPG


Re: DAHDI timing and ASL

Steve N4IRS
 

This is on an Atom

root@omv:/usr/src/asl-dahdi-linux-2.11.1# lsmod | grep dahdi
dahdi                 212992  0
crc_ccitt              16384  1 dahdi

root@omv:/usr/src/asl-dahdi-linux-2.11.1# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.996% 99.992% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996%
99.996% 99.992% 99.996% 99.997% 99.996% 99.996% 99.996% 99.996%
99.996% 99.993% 99.996% 99.996% 99.223% 99.215% 99.223% 99.215%
99.996% 99.993% 99.996% 99.996% 99.222% 99.996% 99.997% 99.215%
99.222% 99.212% 99.996% 99.997% 99.223% 99.215% 99.996% 99.613%
99.996% 99.995% 99.996% 99.996% 99.996% 99.997% 99.996% 99.997%
99.996% 99.995% 99.996% 99.614% 99.215% 99.996% 99.996% 99.223%
99.996% 99.214% 99.223% 99.215% 99.996% 99.996% 99.222% 99.215%
99.222% 99.212% 99.996% 99.223% 99.215% 99.996% 99.222% 99.996%
99.215% 99.224% 99.215% 99.996% 99.222% 99.215% 99.996% 99.222%
99.996% 99.212% 99.222% 99.996% 99.215% 99.996% 99.223% 99.996%
99.996% 99.212% 99.996% 99.996% 99.996% 99.996% 99.222% 99.215%
99.996% 99.225%
--- Results after 98 passes ---
Best: 99.997% -- Worst: 99.212% -- Average: 99.702537%
Cumulative Accuracy (not per pass): 99.996
root@omv:/usr/src/asl-dahdi-linux-2.11.1#
root@omv:/usr/src/asl-dahdi-linux-2.11.1# modprobe dahdi_dummy

root@omv:/usr/src/asl-dahdi-linux-2.11.1# lsmod | grep dahdi
dahdi_dummy            16384  0
dahdi                 212992  1 dahdi_dummy
crc_ccitt              16384  1 dahdi

root@omv:/usr/src/asl-dahdi-linux-2.11.1# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.995% 99.992% 99.996% 99.997% 99.996% 99.996% 99.996% 99.996%
99.996% 99.994% 99.996% 99.996% 99.996% 99.996% 99.996% 99.996%
99.996% 99.995% 99.996% 99.996% 99.997% 99.995% 99.997% 99.996%
99.996% 99.994% 99.996% 99.996% 99.997% 99.996% 99.996% 99.997%
99.996% 99.993% 99.997% 99.996% 99.996% 99.996% 99.997% 99.995%
99.996% 99.994% 99.996% 99.996% 99.996% 99.996% 99.997% 99.996%
99.996% 99.994% 99.997% 99.996% 99.996% 99.996% 99.996% 99.996%
99.997% 99.994% 99.997% 99.996% 99.996% 99.997% 99.995% 99.997%
99.996% 99.995% 99.995% 99.997% 99.996% 99.996% 99.997% 99.996%
99.996% 99.995% 99.995% 99.996% 99.996% 99.996% 99.996% 99.997%
99.996% 99.995% 99.996% 99.997% 99.996% 99.997% 99.996% 99.996%
99.996% 99.995% 99.996% 99.997% 99.997% 99.995% 99.996% 99.996%
99.996% 99.996%
--- Results after 98 passes ---
Best: 99.997% -- Worst: 99.992% -- Average: 99.995937%
Cumulative Accuracy (not per pass): 99.996

root@omv:/usr/src/asl-dahdi-linux-2.11.1# dmidecode | more
# dmidecode 3.0
Handle 0x0004, DMI type 4, 42 bytes
Processor Information
    Socket Designation: CPU 1
    Type: Central Processor
    Family: Atom
    Manufacturer: Intel            
    ID: CA 06 01 00 FF FB EB BF
    Signature: Type 0, Family 6, Model 28, Stepping 10
    Version: Intel(R) Atom(TM) CPU D510   @ 1.66GHz              
    Voltage: 1.1 V
    External Clock: 167 MHz
    Max Speed: 1666 MHz
    Current Speed: 1666 MHz
    Status: Populated, Enabled
    Upgrade: Socket LGA775
    L1 Cache Handle: 0x0005


Re: DAHDI timing and ASL

Steve N4IRS
 

This is the result on dvswitch.org. It is a VM on VMware.

root@dvswitch:/var/log/asterisk# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.997% 99.994% 99.998% 99.999% 99.994% 99.991% 99.996% 99.998%
99.999% 99.994% 99.999% 99.996% 99.998% 99.990% 99.998% 99.999%
99.995% 99.998% 99.998% 99.995% 99.998% 99.997% 99.998% 99.997%
99.997% 99.999% 99.999% 99.991% 99.998% 99.998% 99.996% 99.999%
99.998% 99.997% 99.998% 99.995% 99.998% 99.997% 99.997% 99.997%
99.998% 99.998% 99.998% 99.997% 99.997% 99.999% 99.996% 99.999%
99.992% 99.997% 99.999% 99.993% 99.988% 99.997% 99.999% 99.997%
99.998% 99.994% 99.995% 99.999% 99.996% 99.999% 99.996% 99.994%
99.998% 99.997% 99.999% 100.000% 99.991% 99.998% 99.998% 99.997%
99.995% 99.998% 99.997% 99.998% 99.997% 99.994% 99.991% 99.987%
99.996% 99.999% 99.999% 100.000% 99.992% 100.000% 99.996% 99.997%
99.995% 99.990% 99.996% 99.999% 99.995% 99.998% 99.997% 99.998%
99.998% 99.996%
--- Results after 98 passes ---
Best: 100.000% -- Worst: 99.987% -- Average: 99.996541%
Cumulative Accuracy (not per pass): 99.997
 


DAHDI timing and ASL

Steve N4IRS
 
Edited

Along with making ASL more "DVSwitch friendly, We are going to tackle some of the issues that have been bugging (no pun intended) us. First on the list is DAHDI timing. ASL is built with Asterisk 1.4.23 and DAHDI 2.11. I quick Google search will turn up quite a few messages detailing on how important DAHDI timing is to proper Asterisk conference operation. Some of you know that the HAMVIOP fork of the ASL source pushes this as an important difference between ASL and HAMVIOP. I can't really say that I have seen issues in either real hardware or hosted VM based ASL nodes but if timing is important, it's to our advantage to make it the best we can. ASL gets it's timing from DAHDI. DAHDI prefers a hardware source for the clock but if none is available, DAHDI can generate the clock from the host itself. For DAHDI to use the High Resolution Timer in the host, a second DAHDI kernel module is needed. That module is dahdi_dummy. The version of DAHDI shipped with ASL does not include building and installing dahdi_dummy. Since I was the one that packaged DAHDI, all I can say is oops. Below is a timing test I ran on a HP DL360 G5. This is a actual server running Stretch but you will see improvement on a VM or a SBC like the Pi. First we will run without dahdi_dummy.

root@demo:/home/szingman# lsmod | grep dahdi
dahdi                 229376  0
crc_ccitt              16384  1 dahdi

root@demo:/home/szingman# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.608% 99.996% 99.999% 99.218% 99.997% 99.999% 99.999% 99.999%
99.606% 99.998% 99.999% 99.999% 99.610% 99.999% 99.999% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.999% 99.999% 99.220% 99.220% 99.218% 99.222% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.218%
99.222% 99.219% 99.999% 99.222% 99.999% 99.997% 99.999% 99.999%
99.999% 99.999% 99.999% 99.220% 99.222% 99.999% 99.999% 99.999%
99.999% 99.996% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.220% 99.220% 99.997% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.220% 99.223% 99.220% 99.222% 99.999% 99.999% 99.997% 99.999%
99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 100.000%
--- Results after 98 passes ---
Best: 100.000% -- Worst: 99.218% -- Average: 99.851760%
Cumulative Accuracy (not per pass): 99.997

root@demo:/usr/src/asl-dahdi-linux-2.11.1# dahdi_scan
NO OUTPUT at all

Now we will run after adding dahdi_dummy

root@demo:/home/szingman# lsmod | grep dahdi
dahdi_dummy            16384  0
dahdi                 229376  1 dahdi_dummy
crc_ccitt              16384  1 dahdi

root@demo:/home/szingman# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.998% 99.996% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.994% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998% 99.999% 99.999% 99.999% 99.999% 99.999% 99.999%
99.999% 99.998%
--- Results after 98 passes ---
Best: 99.999% -- Worst: 99.994% -- Average: 99.998769%
Cumulative Accuracy (not per pass): 99.999

root@demo:/home/szingman# dahdi_scan
[1]
active=yes
alarms=UNCONFIGURED
description=DAHDI_DUMMY/1 (source: HRtimer) 1
name=DAHDI_DUMMY/1
manufacturer=
devicetype=DAHDI Dummy Timing
location=
basechan=1
totchans=0
irq=0

As you can see there is a improvement. Not a big improvement in this case but there is a difference. We have tested on a few different platforms and all exhibit a improvement. It's actually easy to build and install the dahdi_dummy module.

As root:
edit /usr/src/asl-dahdi-linux-2.11.1/linux/drivers/dahdi/Kbuild
change:
#obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_DUMMY)             += dahdi_dummy.o     
to:
obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_DUMMY)             += dahdi_dummy.o
save your work.

cd to /usr/src/asl-dahdi-linux-2.11.1
run:
make install
Once make completes, test your work:
modprobe dahdi_dummy
You should see:
root@demo:/home/szingman# lsmod | grep dahdi
dahdi_dummy            16384  0
dahdi                 229376  1 dahdi_dummy
crc_ccitt              16384  1 dahdi

If you do, the module is built and can be installed.
Now we will load it at boot.
edit /etc/modules
add dahdi_dummy above dahdi
save your work
reboot

This was discovered by Bryan W9CR. He compared the binary for dahdi_dummy with what HAMVOIP calls dahdi_hrtimer. A comparison using strings turns up some glaring similarities and differences. I'll leave this to the community to decide.
Here are some other tests and results. Note: some eagle eyed users will notice some of these tests were not run on the HP DL360 G5. I do not have ASL installed on that machine yet, only DAHDI:

Before:
root@repeater:/home/szingman# lsmod | grep dahdi
dahdi                 229376  0
crc_ccitt              16384  1 dahdi

root@repeater:/home/repeater# asterisk -r

AllStarLink Asterisk Version 1.01 2/13/2018 GIT Version adaec47
=========================================================================
Connected to Asterisk GIT Version adaec47 currently running on repeater (pid = 353)
repeater*CLI> dahdi show status
Description                              Alarms     IRQ        bpviol     CRC4
repeater*CLI> exit

After:
root@repeater:/home/repeater# modprobe dahdi_dummy
root@repeater:/home/repeater# lsmod | grep dahdi
dahdi_dummy             3538  0
dahdi                 233213  27 dahdi_dummy
crc_ccitt               1835  1 dahdi


root@repeater:/home/repeater# asterisk -r

AllStarLink Asterisk Version 1.01 2/13/2018 GIT Version adaec47
=========================================================================
Connected to Asterisk GIT Version adaec47 currently running on repeater (pid = 353)
repeater*CLI> dahdi show status
Description                              Alarms     IRQ        bpviol     CRC4
DAHDI_DUMMY/1 (source: HRtimer) 1        UNCONFIGUR 0          0          0
repeater*CLI>

<

https://elinux.org/High_Resolution_Timers#How_to_detect_if_your_timer_system_supports_high_resolution>

Here are some things to check:

1. Check the resolution reported for your clocks. If your clock supports high resolution, it will have a .resolution value of 1 nsecs. If it does not, then it will have a .resolution value that equals the number of nanoseconds in a jiffy (usually 10000 nsecs, on embedded platforms).

2. Check the event_handler for the Tick Device. If the event handlers is 'hrtimer_interrupt' then the clock is set up for high resolution handling. If the event handler is 'tick_handle_periodic', then the device is set up for regular tick-based handling.

3. Check the list of timers, and see if the attribute .hres_active has a value of 1. If so, then the high resolution timer feature is active.


root@repeater:/home/repeater# cat /proc/timer_list
Timer List Version: v0.8
HRTIMER_MAX_CLOCK_BASES: 4
now at 927502067184 nsecs

cpu: 0
 clock 0:
  .base:       df91dd80
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: zaptimer, dahdi_dummy_hr_int, S:01, init_module, systemd-modules/189
 # expires at 927506314625-927506314625 nsecs [in 4247441 to 4247441 nsecs]
 #1: <df91e020>, tick_sched_timer, S:01, tick_nohz_restart, swapper/0/0
 # expires at 927508000000-927508000000 nsecs [in 5932816 to 5932816 nsecs]
 #2: <dacffa30>, hrtimer_wakeup, S:01, schedule_hrtimeout_range_clock, asterisk/458
 # expires at 927520910752-927520960752 nsecs [in 18843568 to 18893568 nsecs]
 #3: <dabeda30>, hrtimer_wakeup, S:01, schedule_hrtimeout_range_clock, asterisk/419
 # expires at 927728645724-927729645716 nsecs [in 226578540 to 227578532 nsecs]
 #4: <dc665a30>, hrtimer_wakeup, S:01, schedule_hrtimeout_range_clock, asterisk/372
 # expires at 927948646756-927953646748 nsecs [in 446579572 to 451579564 nsecs]
 #5: <df91e138>, watchdog_timer_fn, S:01, watchdog_enable, watchdog/0/11
 # expires at 928092000000-928092000000 nsecs [in 589932816 to 589932816 nsecs]
 #6: <dad8fee8>, hrtimer_wakeup, S:01, do_nanosleep.constprop.5, asterisk/418
 # expires at 928413787609-928413837609 nsecs [in 911720425 to 911770425 nsecs]
 #7: <dc3b6800>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd-udevd/230
 # expires at 940154557000-940154557000 nsecs [in 12652489816 to 12652489816 nsecs]
 #8: <dc3b6a00>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd-journal/184
 # expires at 940154557000-940154557000 nsecs [in 12652489816 to 12652489816 nsecs]
 #9: <dc3b6000>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd/1
 # expires at 940154557000-940154557000 nsecs [in 12652489816 to 12652489816 nsecs]
 #10: <dc6cdee8>, hrtimer_wakeup, S:01, do_nanosleep.constprop.5, cron/381
 # expires at 949573630626-949573680626 nsecs [in 22071563442 to 22071613442 nsecs]
 #11: <dc413ee8>, hrtimer_wakeup, S:01, do_nanosleep.constprop.5, sleep/654
 # expires at 953799741074-953799791074 nsecs [in 26297673890 to 26297723890 nsecs]
 #12: sched_clock_timer, sched_clock_poll, S:01, sched_clock_postinit, swapper/0/0
 # expires at 984263334681-984263334681 nsecs [in 56761267497 to 56761267497 nsecs]
 #13: <daadd500>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd-logind/377
 # expires at 1000154557000-1000154557000 nsecs [in 72652489816 to 72652489816 nsecs]
 #14: <daacf600>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd-timesyn/334
 # expires at 1000154557000-1000154557000 nsecs [in 72652489816 to 72652489816 nsecs]
 #15: <db1b5a30>, hrtimer_wakeup, S:01, schedule_hrtimeout_range_clock, rsyslogd/353
 # expires at 1211996410283-1212096410283 nsecs [in 284494343099 to 284594343099 nsecs]
 #16: <dace3ee8>, hrtimer_wakeup, S:01, do_nanosleep.constprop.5, asterisk/371
 # expires at 1217714212774-1217714262774 nsecs [in 290212145590 to 290212195590 nsecs]
 #17: <dc6a1a30>, hrtimer_wakeup, S:01, schedule_hrtimeout_range_clock, dhclient/474
 # expires at 36579226391252-36579326391252 nsecs [in 35651724324068 to 35651824324068 nsecs]
 clock 1:
  .base:       df91ddc0
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     1570714932000715417 nsecs
active timers:
 #0: <daadd200>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd/1
 # expires at 1570716580154557000-1570716580154557000 nsecs [in 720651774399 to 720651774399 nsecs]
 #1: <da930800>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd/1
 # expires at 2147483647000000000-2147483647000000000 nsecs [in 576767787497217399 to 576767787497217399 nsecs]
 #2: <daadde00>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd-timesyn/334
 # expires at 2147483647000000000-2147483647000000000 nsecs [in 576767787497217399 to 576767787497217399 nsecs]
 #3: <dc645b00>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd/570
 # expires at 2147483647000000000-2147483647000000000 nsecs [in 576767787497217399 to 576767787497217399 nsecs]
 clock 2:
  .base:       df91de00
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
 #0: <dc6db500>, timerfd_tmrproc, S:01, SyS_timerfd_settime, systemd-timesyn/334
 # expires at 1045654557000-1045654557000 nsecs [in 118152489816 to 118152489816 nsecs]
 clock 3:
  .base:       df91de40
  .index:      3
  .resolution: 1 nsecs
  .get_time:   ktime_get_clocktai
  .offset:     1570714932000715417 nsecs
active timers:
  .expires_next   : 927506314625 nsecs
  .hres_active    : 1
  .nr_events      : 942016
  .nr_retries     : 42
  .nr_hangs       : 0
  .max_hang_time  : 0
  .nohz_mode      : 2
  .last_tick      : 927488000000 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 156871
  .idle_calls     : 912199
  .idle_sleeps    : 879117
  .idle_entrytime : 927492366427 nsecs
  .idle_waketime  : 927492366427 nsecs
  .idle_exittime  : 927492554513 nsecs
  .idle_sleeptime : 697520844910 nsecs
  .iowait_sleeptime: 6054951872 nsecs
  .last_jiffies   : 156872
  .next_timer     : 927520000000
  .idle_expires   : 927520000000 nsecs
jiffies: 156876

Tick Device: mode:     1
Broadcast device
Clock Event Device: <NULL>
tick_broadcast_mask: 0
tick_broadcast_oneshot_mask: 0

Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: timer2
 max_delta_ns:   178956969070
 min_delta_ns:   1000
 mult:           51539608
 shift:          31
 mode:           3
 next_event:     927506314625 nsecs
 set_next_event: omap2_gp_timer_set_next_event
 shutdown: omap2_gp_timer_shutdown
 periodic: omap2_gp_timer_set_periodic
 oneshot:  omap2_gp_timer_shutdown
 resume:   omap2_gp_timer_shutdown
 event_handler:  hrtimer_interrupt
 retries:        104

73, Steve N4IRS

101 - 114 of 114