Same mail as last time but now in plain text. Sorry :( Gesendet: Mittwoch, 28. Oktober 2015 um 16:59 Uhr Von: "Stefan Kohlhauser" <stefan.li...@gmx.net> An: mico...@gmail.com, sr-users@lists.sip-router.org Betreff: Re: [SR-Users] 100% CPU usage after NTP date update
Hello Daniel! We have managed to track the problem down. What causes our troubles lies in the file timer.c in the function timer_handler. Or to be more exact in the for-loop: for (prev_ticks=prev_ticks+1; prev_ticks!=saved_ticks; prev_ticks++) timer_run(prev_ticks); In our case, after the NTP time change, this tries to bring the prev_ticks (representing the year 1970) up to the saved_ticks (our current time provided by NTP) tick by tick. This is quite some calculating for 45 years. Especially on an embedded device. As a workaround we have added an additional if-clause in the adjust_ticks function that simply ignores if the 'delta' between system time and ticks gets too high. We have run a first test where this workaround seems to be ok but we'll run some further tests. Do you think this workaround might cause some problems? I.e. might there be a problem if the system time jumps ahead too far but we do not adjust the ticks? (We hope not because a time-leap backwards is ignored too :) ) Apart from our workaround: Do you think there might be a way to handle this problem less CPU consuming (or to bring the ticks up to date in a bigger bulk)? Best regards, Stefan Gesendet: Donnerstag, 22. Oktober 2015 um 09:50 Uhr Von: "Daniel-Constantin Mierla" <mico...@gmail.com> An: "Kamailio (SER) - Users Mailing List" <sr-users@lists.sip-router.org> Betreff: Re: [SR-Users] 100% CPU usage after NTP date update Hello, can you do 'top' and see what is the pid of the process using a lot of cpu, then get the backtrace with gdb? gdb /path/to/kamailio PID bt full It will help to see what kamailio is trying to do. Cheers, Daniel On 22/10/15 10:45, Stefan Kohlhauser wrote: > Hello everyone! > > Setup: > I am currently using a Kamailio 4.2.3 on an embedded device (low CPU and > RAM). The device is not able to store the current date, so after a reboot its > 1. Jan 1970 until NTP updates the date. > > Problem: > If the date is updated after the Kamailio has started (a leap of 45 years) > the Kamailio uses up all the CPU and renders the device useless for a very > long time. > > Notes: > There are no incomming requests at the time. (But the Kamailio is not > responsive during that time anyway.) > Adjusting the internal Kamailio-time seems to take longer when the date > update leap is bigger. > > My questions: > 1) Can I prevent the Kamailio from using up the entire CPU after a date > update? Or maybe do the internal ticks-update more gracefully? > 2) For my better understanding: What happens within the Kamailio after > adjust_ticks has updated the internal date? > > Thanks in advance for your help! > > Best regards, > Stefan > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda[http://twitter.com/#!/miconda] - http://www.linkedin.com/in/miconda[http://www.linkedin.com/in/miconda] Book: SIP Routing With Kamailio - http://www.asipto.com[http://www.asipto.com] _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users[http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users]_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users[http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users] _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users