Hi all, I'm trying to find a solution for an "RT throttling" issue under relatively high load (20cps) on linux 3.10 and CPU Xeon E5-1650v2 (6cores). A similar jira ticket FS-8620 has a recommendation to set the clocksource to "hpet": echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource I read somewhere that the default clocksource (TSC) is lighter in CPU usage because it only requires reading a register that is synchronized across all cores... Considering FreeSWITCH needs: -> Is HPET recommended over the default "TSC" clock? -> Does a change in clocksource have immediate effects or does it require an FS restart/reboot? -> Also, is it recommended to disable RT-throttling to resolve these types of issues? echo -1 >/proc/sys/kernel/sched_rt_runtime_us echo -1 >/proc/sys/kernel/sched_rt_period_us Thanks, François.
These things mainly come up when someone is trying to overload a system or drag more out of it. If its already working, there is no need to mess with the clock source. HPET is for sure more accurate and can come in handy when doing heavy load because, yes, it uses the cpu but it does so from the kernel which has priority, You want timing to always have priority. If you are triggering real time throttling issues, you are probably pushing the box pretty hard. This is considered very advanced tuning and we don't really endorse it for community level support. Consider contacting consulting@freeswitch.org for advanced support. On Fri, Jan 22, 2016 at 6:22 AM, François <fdelawarde@wirelessmundi.com> wrote:
Hi all,
I'm trying to find a solution for an "RT throttling" issue under relatively high load (20cps) on linux 3.10 and CPU Xeon E5-1650v2 (6cores). A similar jira ticket FS-8620 has a recommendation to set the clocksource to "hpet":
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
I read somewhere that the default clocksource (TSC) is lighter in CPU usage because it only requires reading a register that is synchronized across all cores...
Considering FreeSWITCH needs:
-> Is HPET recommended over the default "TSC" clock?
-> Does a change in clocksource have immediate effects or does it require an FS restart/reboot?
-> Also, is it recommended to disable RT-throttling to resolve these types of issues?
echo -1 >/proc/sys/kernel/sched_rt_runtime_us echo -1 >/proc/sys/kernel/sched_rt_period_us
Thanks, François.
_________________________________________________________________________ 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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
Thanks for the info, i guess i'd better not change any of the defaults if it's working most of the times (except maybe HPET)! I thought things like that could help. A couple of times a day during a minute or so, new channels hang between ROUTING to EXECUTE state (the rest works perfectly), and I can see this "RT Throttle" issue in dmesg. Strange thing is that the average load is pretty low (<10% cpu_usage, and <3 cpu_load on avg). I'd better try to find and fix the cause of this than mess with kernel settings! François. On 2016-01-22 17:55, Anthony Minessale wrote:
These things mainly come up when someone is trying to overload a system or drag more out of it. If its already working, there is no need to mess with the clock source. HPET is for sure more accurate and can come in handy when doing heavy load because, yes, it uses the cpu but it does so from the kernel which has priority, You want timing to always have priority. If you are triggering real time throttling issues, you are probably pushing the box pretty hard. This is considered very advanced tuning and we don't really endorse it for community level support.
Consider contacting consulting@freeswitch.org <mailto:consulting@freeswitch.org> for advanced support.
On Fri, Jan 22, 2016 at 6:22 AM, François <fdelawarde@wirelessmundi.com <mailto:fdelawarde@wirelessmundi.com>> wrote:
Hi all,
I'm trying to find a solution for an "RT throttling" issue under relatively high load (20cps) on linux 3.10 and CPU Xeon E5-1650v2 (6cores). A similar jira ticket FS-8620 has a recommendation to set the clocksource to "hpet":
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
I read somewhere that the default clocksource (TSC) is lighter in CPU usage because it only requires reading a register that is synchronized across all cores...
Considering FreeSWITCH needs:
-> Is HPET recommended over the default "TSC" clock?
-> Does a change in clocksource have immediate effects or does it require an FS restart/reboot?
-> Also, is it recommended to disable RT-throttling to resolve these types of issues?
echo -1 >/proc/sys/kernel/sched_rt_runtime_us echo -1 >/proc/sys/kernel/sched_rt_period_us
Thanks, François.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net <http://irc.freenode.net> #freeswitch ☞ _http://freeswitch.org/g+_
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ 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 (2)
-
Anthony Minessale
-
François