Confbridge For 80 Devices

Home » Asterisk Users » Confbridge For 80 Devices
Asterisk Users 9 Comments

Bringing 80 devices into a conf bridge with CPU: AMD Phenom(tm) II X6 1045T
Processor at 2.7G and audio is reported as staticy or not the best audio quality.

Network is r8169 0000:02:00.0 eth0: RTL8168e/8111
Link is 1G.

Asterisk 18.14.0

I would think this should be able to handle 80 calls (one way audio).

How can I tell if asterisk is an able to handle this – or how can I find the bottle neck?

Thanks

Jerry

9 thoughts on - Confbridge For 80 Devices

  • So I did the “timing test” got timing test Attempting to test a timer with 50 ticks per second. Using the ‘timerfd’ timing module for this test.

    in modules I added
    [modules]
    autoload=yes preload => res_timing_dahdi.so preload => res_timing_pthread.so

    Re-ran the timing test got the same thing. Notice it says specifically timerfd – not timing_dahdi or timing_pthread. System is CentOS 7.

    lsmod | grep dahdi lsmod | grep dahdi dahdi_transcode 14291 1 wctc4xxp dahdi_voicebus 59241 1 wctdm24xxp dahdi 228002 9
    wctdm24xxp,wcaxx,dahdi_transcode,oct612x,dahdi_voicebus,wcb4xxp,wct4xxp,wcte43x,wcte13xp crc_ccitt 12707 2 wctdm24xxp,dahdi

    Is my timing OK – or not ?

    Note /var/log/asterisk/messages says “nothing” about timing even though the resourse were loaded.

    Thoughts ?

    Jerry

  • What is the trick to get “preload => res_timing_dahdi” working ?

    I have tried to add to both a CentOS 7 (metal box) and Ubuntu 20.04 (VMware guest) system restart asterisk and neither print anything about res_timing_dahdi in the
    /var/log/asterisk/messages file.

    Both are having issues with around 80 Confbridge items.

    timing test on BOTH return the same… Attempting to test a timer with 50 ticks per second. Using the ‘timerfd’ timing module for this test. It has been 1000 milliseconds, and we got 50 timer ticks

    I dont think either system is “correctly” using the dahdi timer.

    Thoughts ?

    jerry

  • T24gMTAvMjAvMjAyMiA1OjE3IFBNLCBKZXJyeSBHZWlzIHdyb3RlOgoKPiBXaGF0IGlzIHRoZSB0
    cmljayB0byBnZXQgInByZWxvYWQgPT4gcmVzX3RpbWluZ19kYWhkaSIgd29ya2luZyA/CgpbbW9k dWxlc10KYXV0b2xvYWQgPSB5ZXMKbm9sb2FkID0gcmVzX3RpbWluZ19wdGhyZWFkCm5vbG9hZCA9
    IHJlc190aW1pbmdfdGltZXJmZAoKSG93ZXZlciwgaXQncyB1bmxpa2VseSB0byBiZSBhIHRpbWlu ZyBwcm9ibGVtLiBDYW4geW91IHNoYXJlIHlvdXIgQ29uZkJyaWRnZSBjb25maWd1cmF0aW9uPwoK
    S2luZCByZWdhcmRzLApTZWFu

  • Hi,

    Dahdi timing is for dahdi hardware. See here: https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces <https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces>

    You could check your asterisk modules using “module show” on asterisk cli.

    Sounds like you might be doing transcoding, which might be the cause of your problems. Are you using the same codec for all calls? If so – which one? I’m not 100% sure about this, but asterisk might be using slin internally for the conf bridge, which means it might have to do some expensive transcoding on the receiving and then again on the sending end. You could check your transcoding times with “core show translation recalc”.

    Regards, Stoyan

  • [modules]
    autoload = yes noload = res_timing_pthread noload = res_timing_timerfd

    SO I “dont” want to load res_timing_anything ???

    I have preload on res_timing_dahdi, then res_timing_pthread and not res_timing_timerfd at all.

    confbridge.conf is below

    [general]
    ; The general section of this config
    ; is not currently used, but reserved
    ; for future use.

    ;
    ; — Default Information –

  • This is on the bare metal machine

    Recalculating Codec Translation (number of sample seconds: 1)

    Translation times between formats (in microseconds) for one second of data
    Source Format (Rows) Destination Format (Columns)

    ulaw alaw gsm g726 g726aal2 adpcm slin8 slin12 slin16 slin24
    slin32 slin44 slin48 slin96 slin192 lpc10 speex8 speex16 speex32 ilbc g722 testlaw
    ulaw – 9150 15000 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 15000
    alaw 9150 – 15000 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 15000
    gsm 15000 15000 – 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 15000
    g726 15000 15000 15000 – 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 15000
    g726aal2 15000 15000 15000 15000 – 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 15000
    adpcm 15000 15000 15000 15000 15000 – 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 15000
    slin8 6000 6000 6000 6000 6000 6000 – 8000 8000 8000
    8000 8000 8000 8000 8000 6000 6000 14000 14000 6000
    8250 6000
    slin12 14500 14500 14500 14500 14500 14500 8500 – 8000 8000
    8000 8000 8000 8000 8000 14500 14500 14000 14000 14500
    14000 14500
    slin16 14500 14500 14500 14500 14500 14500 8500 8500 – 8000
    8000 8000 8000 8000 8000 14500 14500 6000 14000 14500
    6000 14500
    slin24 14500 14500 14500 14500 14500 14500 8500 8500 8500 –
    8000 8000 8000 8000 8000 14500 14500 14500 14000 14500
    14500 14500
    slin32 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500
    – 8000 8000 8000 8000 14500 14500 14500 6000 14500
    14500 14500
    slin44 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500
    8500 – 8000 8000 8000 14500 14500 14500 14500 14500
    14500 14500
    slin48 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500
    8500 8500 – 8000 8000 14500 14500 14500 14500 14500
    14500 14500
    slin96 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500
    8500 8500 8500 – 8000 14500 14500 14500 14500 14500
    14500 14500
    slin192 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500
    8500 8500 8500 8500 – 14500 14500 14500 14500 14500
    14500 14500
    lpc10 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 – 15000 23000 23000 15000
    17250 15000
    speex8 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 – 23000 23000 15000
    17250 15000
    speex16 23500 23500 23500 23500 23500 23500 17500 17500 9000 17000
    17000 17000 17000 17000 17000 23500 23500 – 23000 23500
    15000 23500
    speex32 23500 23500 23500 23500 23500 23500 17500 17500 17500 17500
    9000 17000 17000 17000 17000 23500 23500 23500 – 23500
    23500 23500
    ilbc 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 –
    17250 15000
    g722 15600 15600 15600 15600 15600 15600 9600 17500 9000 17000
    17000 17000 17000 17000 17000 15600 15600 15000 23000 15600
    – 15600
    testlaw 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000
    17000 17000 17000 17000 17000 15000 15000 23000 23000 15000
    17250 –

  • Thanks – so based on this wiki – seems like “The only functionality that requires internal timing is IAX2 trunking” – which I am not using . Just ConfBridge… And getting crappy audio with about 80 devices and a 1 –
    way conf.

    other thoughts on what is happening ?

    Jerry

  • I would try adding this to all of your user profiles (type = user) and see if that improves things.

    Kind regards, Sean

    —