[Freeswitch-users] Choppy sound with PCMU
Anthony Minessale
anthony.minessale at gmail.com
Thu Dec 3 12:40:59 PST 2009
no,
I mean the one after that that you must have completely skipped with a
command line option to try and a param to set in the config. It somewhat
annoys me for taking the time to compose it now. I wrote all of the code
you are talking about myself and I was trying to give you some
suggestions....
Well, actually, you did answer my question about the platform so you must
have seen it.....
The loops are not the cause of that migration message, something wrong with
the hardware or the kernel is.
Another guy just told you he does not see that problem on the same exact
hardware.
Even if you have a point about the sql threads, you could make a patch to
slow them down but you cant slow down too much or you will not be able to
handle 400 cps all asking to send updates to transactions in batches of
thousands of sql stmts. Every line of that code is carefully designed so I
don't know what else to tell you but to stop being so arrogant and re-read
this thread for all the advice you have totally ignored. I started out
trying to help you but I have a lot of work to do. I thoroughly explained
it to you and you are choosing to ignore me so I guess I'm done.
You can do whatever you want with your working copy, i'll see you in 3 or 4
years when you get up to speed with the rest of us........
On Thu, Dec 3, 2009 at 12:43 PM, eaf <erandr-junk at usa.net> wrote:
>
> You mean, upgrading to the trunk and disabling RTP timers? Yes, I did. I
> thought I responded back. Perhaps it didn't make through though, as I just
> emailed back to the list instead of using nabble.com...
>
> Anyway, upgrading to the trunk didn't change much, forcing SPA to 30ms went
> w/o any effect either, but disabling RTP timers did the trick. I don't have
> the original "choppy sound with PCMU" problem any more, thanks a lot for
> the
> quick turnaround on that question.
>
> But your suggestions made me look, into logs, strace, code, etc, so now I'm
> just checking on how to quiet down those busy loops a little and how to get
> rid of periodic CRIT messages about Virtual Machine Migration.
>
>
> Anthony Minessale-2 wrote:
> >
> > What about the things I spent time suggesting in my last email?
> > Did you try them because I was actually curious if they made any impact.
> >
> >
> > On Thu, Dec 3, 2009 at 11:29 AM, eaf <erandr-junk at usa.net> wrote:
> >
> >>
> >> I'm sorry if I sounded that way. Did mean to. :)
> >>
> >> Yes, it's an embedded platform. It's an ALIX board with AMD Geode LX800
> >> chip
> >> and 256MB of RAM. http://www.pcengines.ch/alix2d3.htm
> >>
> >> Line offset difference is due to some minor logging changes I made to
> see
> >> who's allocating timers and how often. This way I found MOH streaming
> and
> >> that RTP still allocates timers even when it's set to none in the
> >> profile.
> >>
> >> I feel that this platform turned out to be underpowered for FS because
> it
> >> cannot meet its scheduling expectations. I guess, some degree of kernel
> >> tweaking or setting priorities will fix that. Meanwhile I just got rid
> of
> >> the SQLDB 1ms thread via -nosql command line option, split sofia worker
> >> 1ms
> >> thread in two (one blocked and waiting for new commands in the SQL
> queue,
> >> the other one checking registrations and gateways with 1sec interval),
> >> and
> >> don't know yet what to do about the timer thread.
> >>
> >> Again, I apologize for stupid or accusing questions, I'm just trying to
> >> see
> >> how FS can be made friendlier to this board. Or the board be made
> >> friendlier
> >> to FS ;)
> >>
> >>
> >> Anthony Minessale-2 wrote:
> >> >
> >> > If you see that message then your machine/os/combo is having some
> >> problems
> >> > keeping up.
> >> > It's not the timer missing anything its the monotonic clock detecting
> a
> >> 1
> >> > second or more differential from what its next prediction for the time
> >> > should be. The best way to trigger this would be to suspend FS with
> >> > control-z or attach to it with gdb blocking the entire process, that
> >> 1ms
> >> > thread would have to miss 1000 iterations to trigger that warning.
> >> >
> >> > Btw, that error message is at line 471 not 473 so you are using
> >> modified
> >> > code.
> >> >
> >> > Its possible your box has a bad monotonic timer, you can set
> >> >
> >> >
> >> >
> >> > under <settings> in switch.conf.xml
> >> >
> >> > We are now starting to guess you are using some small embedded type
> >> > platform
> >> > perhaps?
> >> > I've run FS even on a nokia n810 and never caused that message to
> fire.
> >> >
> >> > if 1 call can interrupt the cpu enough to cause noticeable issues you
> >> > might
> >> > want to consider running the process at a
> >> > greater priority by using the -hp command line arg or at least nice it
> >> >
> >> > Why don't you tell us the whole story about what OS/platform you are
> >> using
> >> > here rather that form conjectures about what is wrong with our code
> >> that
> >> > thousands of people are happy with.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Dec 3, 2009 at 8:55 AM, eaf <erandr-junk at usa.net> wrote:
> >> >
> >> >>
> >> >> Btw, I have these popping up in my logs from time to time:
> >> >>
> >> >> 2009-12-03 09:42:06.035294 [DEBUG] switch_core_state_machine.c:314
> >> >> (sofia/external/xxxxx at 4.68.250.148) Running State Change CS_HANGUP
> >> >> 2009-12-03 09:42:06.035294 [CRIT] switch_time.c:473 Virtual Migration
> >> >> Detected! Syncing Clock
> >> >>
> >> >> In this case an incoming call rang to both FS and Asterisk, Asterisk
> >> >> picked
> >> >> up, but the surge of activity made FS timer thread miss a beat or
> two.
> >> >>
> >> >>
> >> >> eaf wrote:
> >> >> >
> >> >> > Oh, it's not just one timer thread... Why, why is sql_thread keeps
> >> on
> >> >> > checking for messages every millisecond? Couldn't there be some
> >> >> signalling
> >> >> > implemented that will make the thread suspend on condition variable
> >> or
> >> >> a
> >> >> > socket/pipe in between?
> >> >> >
> >> >> > #0 do_sleep (t=1000) at src/switch_time.c:109
> >> >> > #1 0xb7e5e215 in switch_core_sql_thread (thread=0xb7586ae8,
> >> obj=0x0)
> >> >> at
> >> >> > src/switch_core_sqldb.c:783
> >> >> >
> >> >> > Why does this sofia_profile_worker_thread keeps on looping checking
> >> for
> >> >> > the queue? Have a semaphore!
> >> >> >
> >> >> > #0 do_sleep (t=1000) at src/switch_time.c:109
> >> >> > #1 0xb73a4701 in sofia_profile_worker_thread_run
> (thread=0x80f3a30,
> >> >> > obj=0x80f2490) at sofia.c:978
> >> >> >
> >> >> > Nothing's happening on the box, but there are three threads that
> >> >> pretend
> >> >> > to be actively busy with smth. Others at least sleep for hundreds
> of
> >> >> > milliseconds, not for one.
> >> >> >
> >> >> > And there is even infrastructure present to do blocking pops: i.e.
> >> why
> >> >> > couldn't sqldb thread do queue_pop() instead of queue_trypop()
> >> >> intermixed
> >> >> > with 1ms sleeps? This looping is such a waste...
> >> >> >
> >> >> >
> >> >> > eaf wrote:
> >> >> >>
> >> >> >> 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-junk at 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 at 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 at 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-tp26594250p26627246.html
> >> >> Sent from the Freeswitch-users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> FreeSWITCH-users mailing list
> >> >> FreeSWITCH-users at 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
> >> >
> >> > FreeSWITCH http://www.freeswitch.org/
> >> > ClueCon http://www.cluecon.com/
> >> > Twitter: http://twitter.com/FreeSWITCH_wire
> >> >
> >> > AIM: anthm
> >> > MSN:anthony_minessale at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
> >> <MSN%3Aanthony_minessale at hotmail.com<MSN%253Aanthony_minessale at hotmail.com>
> ><
> >> MSN%3Aanthony_minessale at hotmail.com<MSN%253Aanthony_minessale at hotmail.com>
> <MSN%253Aanthony_minessale at hotmail.com<MSN%25253Aanthony_minessale at hotmail.com>
> >
> >> >
> >> >
> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> <PAYPAL%3Aanthony.minessale at gmail.com<PAYPAL%253Aanthony.minessale at gmail.com>
> >
> >> <PAYPAL%3Aanthony.minessale at gmail.com<PAYPAL%253Aanthony.minessale at gmail.com>
> <PAYPAL%253Aanthony.minessale at gmail.com<PAYPAL%25253Aanthony.minessale at gmail.com>
> >
> >> >
> >> > IRC: irc.freenode.net #freeswitch
> >> >
> >> > FreeSWITCH Developer Conference
> >> > sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
> >> <sip%3A888 at conference.freeswitch.org<sip%253A888 at conference.freeswitch.org>
> ><
> >> sip%3A888 at conference.freeswitch.org<sip%253A888 at conference.freeswitch.org>
> <sip%253A888 at conference.freeswitch.org<sip%25253A888 at conference.freeswitch.org>
> >
> >> >
> >> > iax:guest at conference.freeswitch.org/888
> >> >
> >> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> <googletalk%3Aconf%2B888 at conference.freeswitch.org<googletalk%253Aconf%252B888 at conference.freeswitch.org>
> >
> >> <googletalk%3Aconf%2B888 at conference.freeswitch.org<googletalk%253Aconf%252B888 at conference.freeswitch.org>
> <googletalk%253Aconf%252B888 at conference.freeswitch.org<googletalk%25253Aconf%25252B888 at conference.freeswitch.org>
> >
> >> >
> >> > pstn:213-799-1400
> >> >
> >> > _______________________________________________
> >> > FreeSWITCH-users mailing list
> >> > FreeSWITCH-users at 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-tp26594250p26629856.html
> >> Sent from the Freeswitch-users mailing list archive at Nabble.com.
> >>
> >>
> >> _______________________________________________
> >> FreeSWITCH-users mailing list
> >> FreeSWITCH-users at 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
> >
> > FreeSWITCH http://www.freeswitch.org/
> > ClueCon http://www.cluecon.com/
> > Twitter: http://twitter.com/FreeSWITCH_wire
> >
> > AIM: anthm
> > MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com><
> MSN%3Aanthony_minessale at hotmail.com<MSN%253Aanthony_minessale at hotmail.com>
> >
> > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> <PAYPAL%3Aanthony.minessale at gmail.com<PAYPAL%253Aanthony.minessale at gmail.com>
> >
> > IRC: irc.freenode.net #freeswitch
> >
> > FreeSWITCH Developer Conference
> > sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org><
> sip%3A888 at conference.freeswitch.org<sip%253A888 at conference.freeswitch.org>
> >
> > iax:guest at conference.freeswitch.org/888
> > googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> <googletalk%3Aconf%2B888 at conference.freeswitch.org<googletalk%253Aconf%252B888 at conference.freeswitch.org>
> >
> > pstn:213-799-1400
> >
> > _______________________________________________
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at 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-tp26594250p26630994.html
> Sent from the Freeswitch-users mailing list archive at Nabble.com.
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at 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
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20091203/b872350e/attachment-0002.html
More information about the FreeSWITCH-users
mailing list