[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=214195#comment-214195 ] 

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

Thanks Shaun! Good analysis, and you may be right.  I just figured out that my fancy new Xeon processor has only two available governors: performance and powersave, and it defaults to powersave.  My next window of opportunity will be tomorrow night. I will move the card back into the new server, bind its IRQ to cpu7 and change the governor of cpu7 to performance.  Hopefully it will fix the problem, and only require one cpu to run full blast.  
                
> dahdi scratchy varying with system load
> ---------------------------------------
>
>                 Key: DAHLIN-333
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-333
>             Project: DAHDI-Linux
>          Issue Type: Bug
>      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
>            Severity: Critical
>
> 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