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

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

Cool! 

Also, I see that you are using t1xxp which is probably why you might be having more issues with this since the newer cards don't *need* to always be serviced at 1ms intervals but the older ones do.


Just taking a note here: I do think there is still an opportunity for improvement here. I believe the drivers should register their power management quality of service requirements to prevent users from needing to make the same changes you did.

The kernel documentation for this interface is:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/pm_qos_interface.txt
                
> 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