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

[Shaun Ruffell (JIRA)]

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

Shaun Ruffell commented on DAHLIN-333:
--------------------------------------

Interesting, so on this system, increasing system load improves the performance. This sounds like some sort of cstate / powersave feature.  I.e., when the CPU thinks the system is under light loads it allows the processor to go into a powersave mode, from which it can't wake up quickly enough.

I image dmseg is also indicating that there are "hard underruns" from the wcte12xp driver?

Are there any BIOS settings related to performance / power or cstates which you can disable that changes the result?
                
> 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