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

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

And just to show that, generally, low system load doesn't correlate to poor dahdi_test results with TE122:

{noformat}
# dahdi_scan | grep -e ^devicetype
devicetype=Wildcard TE122 (VPMADT032)
# uptime
 21:52:23 up 11:19,  1 user,  load average: 0.29, 0.27, 0.11
# dahdi_test -c 10
Opened pseudo dahdi interface, measuring accuracy...
99.983% 99.979% 99.984% 99.984% 99.984% 99.984% 99.984% 99.984%
99.984% 99.983%
--- Results after 10 passes ---
Best: 99.984% -- Worst: 99.979% -- Average: 99.983085%
Cummulative Accuracy (not per pass): 99.983
# uptime
 21:52:51 up 11:20,  1 user,  load average: 0.19, 0.25, 0.10
{noformat}
                
> 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