I summarized some experience gained in a customer project, hopefully it will be useful: https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/ @Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful: https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
clock_nanosleep(). On Jun 4, 2015 10:08 PM, "Michael Jerris" <mike@jerris.com> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful:
https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Michael, as far as I understand it, it works as follows: timerfd is a kernel's means of providing the system clock to the userland process (freeswitch daemon in our case). The kernel takes the clock from one of available sources, and these sources are either physical or software clocks: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc So, TSC was giving stable results, while HPET, although expected to be more precise, was generating errors while the CPU was busy with other jobs. On Thu, Jun 4, 2015 at 9:05 PM, Michael Jerris <mike@jerris.com> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful: https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
To be completely honest on non vm setups I haven't seen anyone with problems like this on reasonably recent kernels. Are you using a distro with an older kernel? On Thursday, June 4, 2015, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Michael, as far as I understand it, it works as follows:
timerfd is a kernel's means of providing the system clock to the userland process (freeswitch daemon in our case).
The kernel takes the clock from one of available sources, and these sources are either physical or software clocks:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc
So, TSC was giving stable results, while HPET, although expected to be more precise, was generating errors while the CPU was busy with other jobs.
On Thu, Jun 4, 2015 at 9:05 PM, Michael Jerris <mike@jerris.com <javascript:;>> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com <javascript:;>> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful:
https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
it's standard latest Debian 7 on a 8-core Xeon. Did you explicitly use HPET clock before? On Fri, Jun 5, 2015 at 12:36 AM, Michael Jerris <mike@jerris.com> wrote:
To be completely honest on non vm setups I haven't seen anyone with problems like this on reasonably recent kernels. Are you using a distro with an older kernel?
On Thursday, June 4, 2015, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Michael, as far as I understand it, it works as follows:
timerfd is a kernel's means of providing the system clock to the userland process (freeswitch daemon in our case).
The kernel takes the clock from one of available sources, and these sources are either physical or software clocks:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc
So, TSC was giving stable results, while HPET, although expected to be more precise, was generating errors while the CPU was busy with other jobs.
On Thu, Jun 4, 2015 at 9:05 PM, Michael Jerris <mike@jerris.com> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful:
https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Debian we don't explicitly set it On Thursday, June 4, 2015, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
it's standard latest Debian 7 on a 8-core Xeon.
Did you explicitly use HPET clock before?
On Fri, Jun 5, 2015 at 12:36 AM, Michael Jerris <mike@jerris.com <javascript:;>> wrote:
To be completely honest on non vm setups I haven't seen anyone with problems like this on reasonably recent kernels. Are you using a distro with an older kernel?
On Thursday, June 4, 2015, Stanislav Sinyagin <ssinyagin@gmail.com <javascript:;>> wrote:
Michael, as far as I understand it, it works as follows:
timerfd is a kernel's means of providing the system clock to the userland process (freeswitch daemon in our case).
The kernel takes the clock from one of available sources, and these sources are either physical or software clocks:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc
So, TSC was giving stable results, while HPET, although expected to be more precise, was generating errors while the CPU was busy with other jobs.
On Thu, Jun 4, 2015 at 9:05 PM, Michael Jerris <mike@jerris.com
<javascript:;>> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com <javascript:;>> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful:
https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but
it
appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Does Debian 7 allow for mmap of the HPET? I have seen this option in the kernels for some time, and I could speculate that whether or not you can mmap it could affect its responsiveness. The kernel config parameter is CONFIG_HPET_MMAP=y -Yossi On 06/04/2015 05:41 PM, Stanislav Sinyagin wrote:
it's standard latest Debian 7 on a 8-core Xeon.
Did you explicitly use HPET clock before?
On Fri, Jun 5, 2015 at 12:36 AM, Michael Jerris <mike@jerris.com> wrote:
To be completely honest on non vm setups I haven't seen anyone with problems like this on reasonably recent kernels. Are you using a distro with an older kernel?
On Thursday, June 4, 2015, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Michael, as far as I understand it, it works as follows:
timerfd is a kernel's means of providing the system clock to the userland process (freeswitch daemon in our case).
The kernel takes the clock from one of available sources, and these sources are either physical or software clocks:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc
So, TSC was giving stable results, while HPET, although expected to be more precise, was generating errors while the CPU was busy with other jobs.
On Thu, Jun 4, 2015 at 9:05 PM, Michael Jerris <mike@jerris.com> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful:
https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
latest debian 7 (same on the machine where I tested): root@vx04:~# grep HPET /boot/config-3.2.0-4-amd64 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET=y CONFIG_HPET_MMAP=y On Thu, Jun 11, 2015 at 7:42 PM, I put the Who? in Mishehu <mishehu@freeswitch.org> wrote:
Does Debian 7 allow for mmap of the HPET? I have seen this option in the kernels for some time, and I could speculate that whether or not you can mmap it could affect its responsiveness. The kernel config parameter is CONFIG_HPET_MMAP=y
-Yossi
On 06/04/2015 05:41 PM, Stanislav Sinyagin wrote:
it's standard latest Debian 7 on a 8-core Xeon.
Did you explicitly use HPET clock before?
On Fri, Jun 5, 2015 at 12:36 AM, Michael Jerris <mike@jerris.com> wrote:
To be completely honest on non vm setups I haven't seen anyone with problems like this on reasonably recent kernels. Are you using a distro with an older kernel?
On Thursday, June 4, 2015, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
Michael, as far as I understand it, it works as follows:
timerfd is a kernel's means of providing the system clock to the userland process (freeswitch daemon in our case).
The kernel takes the clock from one of available sources, and these sources are either physical or software clocks:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc
So, TSC was giving stable results, while HPET, although expected to be more precise, was generating errors while the CPU was busy with other jobs.
On Thu, Jun 4, 2015 at 9:05 PM, Michael Jerris <mike@jerris.com> wrote:
timerfd would be the preferred timing source on any remotely modern linux kernel
On Jun 4, 2015, at 6:47 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I summarized some experience gained in a customer project, hopefully it will be useful:
https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/
@Anthony, you suggested to use HPET timer for better precision, but it appears that it is affected by the CPU load: while the debian package build script was running, the quality of recorded calls has degraded -- even that the recording was done onto a TMPFS partition. With the default TSC timer, this was not the case.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Dmitry Lysenko
-
I put the Who? in Mishehu
-
Michael Jerris
-
Stanislav Sinyagin