[asterisk-bugs] [JIRA] (DAHLIN-333) dahdi scratchy varying with system load

[Thomas B. Clark (JIRA)]

    [ https://issues.asterisk.org/jira/browse/DAHLIN-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214196#comment-214196 ] 

Thomas B. Clark commented on DAHLIN-333:
----------------------------------------

After adding the following to the dahdi startup script:

#assign all interrupts from t1xxp to cpu7, and disable idle
IRQ=`grep t1xxp /proc/interrupts|awk '{ print $1 }'|sed 's/://'`
echo t1xxp is running on IRQ $IRQ
echo assigning IRQ $IRQ to cpu7
echo 80 > /proc/irq/$IRQ/smp_affinity
echo disabling idle on cpu7
/usr/bin/cpupower -c 7 idle-set -d 5
/usr/bin/cpupower -c 7 idle-set -d 4
/usr/bin/cpupower -c 7 idle-set -d 3

My dahdi_test output now shows:

8192 samples in 8192.056 system clock sample intervals (99.999%)
8192 samples in 8191.559 system clock sample intervals (99.995%)
8192 samples in 8191.992 system clock sample intervals (100.000%)
8192 samples in 8191.873 system clock sample intervals (99.998%)
8192 samples in 8191.840 system clock sample intervals (99.998%)
8192 samples in 8191.720 system clock sample intervals (99.997%)
8192 samples in 8191.864 system clock sample intervals (99.998%)^C
--- Results after 7 passes ---
Best: 100.000% -- Worst: 99.995% -- Average: 99.997893%
Cummulative Accuracy (not per pass): 99.998

Problem solved.  Thanks Shaun!!
                
> dahdi scratchy varying with system load
> ---------------------------------------
>
>                 Key: DAHLIN-333
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-333
>             Project: DAHDI-Linux
>          Issue Type: Information Request
>      Security Level: None
>          Components: dahdi (the module)
>    Affects Versions: 2.8.0.1
>         Environment: Fedora 20, kernel 3.12.6, Intel Xeon CPU E3-1275, 32 GB RAM,
> Digium single span T1 PCI (not PCIx) card
>            Reporter: Thomas B. Clark
>            Assignee: Russ Meyerriecks
>
> At low system low, call quality is so scratchy that it is almost impossible to hear the dial tone.  dahdi_test confirms:
> 8192 samples in 8640.936 system clock sample intervals (94.520%)
> 8192 samples in 8637.144 system clock sample intervals (94.566%)
> 8192 samples in 8591.728 system clock sample intervals (95.121%)
> 8192 samples in 8596.584 system clock sample intervals (95.061%)
> 8192 samples in 8665.929 system clock sample intervals (94.215%)
> --- Results after 7 passes ---
> Best: 95.121% -- Worst: 94.215% -- Average: 94.661537%
> Cummulative Accuracy (not per pass): 94.662
> However, I remembered with my last server (built with commodity components, including an i5 processor), the same thing would happen before starting mister house, which is a home automation program that runs continuously. I never did figure out why, but today wondered if it might be system load.  So, repeating dahdi_test after starting up boinc-client, and bringing the load up to about 50%:
> 8192 samples in 8232.911 system clock sample intervals (99.501%)
> 8192 samples in 8518.016 system clock sample intervals (96.020%)
> 8192 samples in 8202.080 system clock sample intervals (99.877%)
> 8192 samples in 8539.712 system clock sample intervals (95.755%)
> 8192 samples in 8191.784 system clock sample intervals (99.997%)
> 8192 samples in 8558.552 system clock sample intervals (95.525%)
> 8192 samples in 8213.704 system clock sample intervals (99.735%)
> 8192 samples in 8443.520 system clock sample intervals (96.930%)^C
> --- Results after 8 passes ---
> Best: 99.997% -- Worst: 95.525% -- Average: 97.917618%
> Cummulative Accuracy (not per pass): 97.918
> It’s still not usable, but much better.  Now I can hear dial tone, but with intermittent scratchiness that corresponds to the obvious cycling of the quality of dahdi_test.  By varying the load on the system, I can change the cumulative accuracy, but it doesn’t ever go above about 98%.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira