As I see it, switch_cond_next() currently is just a do_sleep(1000). Yes, it could be mapped to a 1ms timer, but "#define DISABLE_1MS_COND" overrides that.
Yeah, there is a global timestamp... It's easy to workaround that for RTP who calls switch_micro_time_now()... But if somebody accesses runtime.timestamp directly, it's gonna be tough to grep for that. If only this was C++... I'll play around. Never liked polling too much. Never could've guessed that polling could be so useful for scalability ;) My naive implementation would've pulled timestamp via system calls and would've done sleeping by passing exact interval to select() instead of syncing with a pacing thread. Which would be dead-quiet at idle time, but, of course, would stop scaling at some point due to excessive number of system calls. Thanks. Michael Jerris wrote: > > In short. No, you can not for many reasons. The milisecond tic is > used throughout the code even when there is not any calls up. You can > grep for switch_cond_next if you would like to see where but it is > required to keep our global timestamp and for pacing the scheduler > among other services that run all the time. > > Mike > > On Dec 2, 2009, at 7:31 PM, eaf <erandr-j...@usa.net> wrote: > >> >> Can I reduce resolution of that timer thread 10 times? I mean, I >> glanced >> through the code, and see that among others (are there others?) RTP >> and IVR >> set up their timers that are subsequently managed by this thread. >> RTP timers >> should be eliminated by that setting you've suggested. IVR timers >> are set at >> 20ms... So, if the thread is set to wake up every 10ms instead of >> 1ms it >> should be able to wake up those IVR timers just fine. Right? >> >> That's a cool design to have one dedicated thread that maintains >> accurate >> timing and then broadcasts via condition variables to hundreds of >> other >> threads events that they can register for. I'm sure it's one of the >> reasons >> why FS scales so much better than Asterisk. But for poor low-end >> setups that >> sit in the closet, eat only 6W of power and hardly ever run more >> than two >> calls at the same time, can I hack it somehow to be more UNIX- >> friendly? I.e. >> make it stuck in select() or recv() when there is nothing to do, call >> clock_gettime() right from the thread that wants and when it wants >> to know >> current time? >> >> Say, what if that thread is made to suspend on a condition variable >> in case >> if there are no timers registered in TIMER_MATRIX? Then, if some other >> thread comes up and adds its timer into the matrix, it could wake up >> the >> timer thread and enjoy accurate timing as needed, on demand? And in- >> between >> the calls, when there is no RTP or IVR, it will all go silent? I mean, >> sitting on a wait queue in the kernel is way better than go back and >> forth >> incrementing counters that nobody even needs at the moment? >> >> >> Anthony Minessale-2 wrote: >>> >>> idle is a 4 letter word to a realtime application. >>> >>> The core keeps a single high-priority thread to keep 1ms timing and >>> expands >>> that broadcasting >>> to hundreds or thousand of threads who need accurate timing. >>> >>> Your choppy audio is caused by linksys lying about the packet len >>> that >>> it's >>> using and we set our timer >>> to the wrong speed. >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26619085.html >> Sent from the Freeswitch-users mailing list archive at Nabble.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 > > _______________________________________________ > 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 > > -- View this message in context: http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26621005.html Sent from the Freeswitch-users mailing list archive at Nabble.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