[Freeswitch-users] Choppy sound with PCMU

Fri Dec 4 14:41:12 PST 2009

A little more data from one of my (our) boxes:

starbox_352 ~ # uname -a
Linux starbox_352 2.6.26.8-astlinux #1 PREEMPT Tue Nov 24 16:20:52 EST
2009 i586 unknown
starbox_352 ~ #

starbox_352 ~ # cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 5
model		: 10
model name	: Geode(TM) Integrated Processor by AMD PCS
stepping	: 2
cpu MHz		: 498.053
cache size	: 128 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow
bogomips	: 997.21
clflush size	: 32
power management:

starbox_352 ~ # cat /etc/astlinux-release
astlinux-s2s-3491
starbox_352 ~ #

  I'll find one that has been in production for a while with some
active calls...

On Thu, Dec 3, 2009 at 6:49 PM, Anthony Minessale
<anthony.minessale at gmail.com> wrote:
> Sigh,
>
> You just took it up a notch in terms of disdain and sarcasm.
> Why do people always only apologize sarcastically?
>
> I asked you to try the -hp and turn off the monotonic clock just to gather
> the results to help you.  You completely missed it and just went on about
> the threads.   Please save the "ok fine the code is perfect, blah blah" if
> you would have just read the email and answered the question I might have
> cared more about the status of your problem.
>
> I told you both of those threads need to be on their toes because they try
> to balance between a certian number of sql stmts or 500ms whatever comes
> first.  When there are thousands of events per second being turned into SQL
> statements which are in turn compiled into large sql transactions.
>
> If you want to come up with a way that they can sleep longer until there is
> a sign of activity and stay busy for a few seconds then slow down again,
> that's probably possible but the process is already idle at 0% cpu so maybe
> you can appreciate why we are not rushing to work on it.  Maybe I'll give it
> a go just to show you it has nothing to do with your problem.
>
> Please don't mock our comment about several years.  You have no idea how
> hard this code was to develop and it's truly insulting.  Its clear to see
> you are locked into assuming that the busy threads that are not all that
> busy because they are constantly yielding to the scheduler is breaking the
> timing code.  I begged you to understand me when i told you that the err is
> not normal, most boxes do not see it doing nothing and there has to be a
> specific problem on your box or configuration.  So instead of working with
> us you want to escalate to snotty comments.  That's pretty normal on the
> internet I guess.....  If you want to have a constructive conversation about
> our core, install FS on a normal box, use it for a few weeks, figure out
> everything about how it works then try.... There was pure speculation and
> conjecture in your original emails and I never said a word about it until
> you kept pushing.
>
> Kristian mentioned he never sees that on that same hardware did you even
> consider following up on why that is?
>
> I don't have your device, but I assume if you get it working well it will
> certainly help you more than it helps me so you could at least have the
> decency to believe what we are trying to tell you.
>
>
>
>
>
>
>
> On Thu, Dec 3, 2009 at 3:44 PM, eaf <erandr-junk at usa.net> wrote:
>>
>> Oh, you mean giving FS higher priority? Yeah, as a last resort I'll do
>> that.
>> At the moment, I hope it won't be necessary as I can make those "hyper"
>> threads behave, and will see how that goes first. I see where your
>> implementation could be coming from. There is a queue of SQL queries in
>> sofia.c processed by the worker thread. There are only two pop functions
>> available in APR: queue_pop() and queue_trypop(), so alas no option with a
>> timeout here. You don't want to block the thread in pop() indefinitely
>> because you chose that same worker needs to do ireg and gw processing once
>> in a while (separated by tens or hundreds of seconds, btw). You also want
>> to
>> be able to detect shutdown condition so that the worker doesn't hold up
>> profile thread. So you chose to poll for events every millisecond instead
>> of
>> just creating an apr_thread_cond_t for resource friendly signalling.
>>
>> I agree that the timer thread philosophy is great and was the right choice
>> for scaling, but I just don't comprehend responses to things like these
>> other SQL or sofia worker threads. Did somebody even remotely acknowledge
>> that busy loops at least in those areas that I showed may probably be a
>> bad
>> idea and could've been eliminated? I've heard suggestions to bump up
>> priority, I've heard that the code was perfect already, that it's the
>> result
>> of 4-year effort, that I am arrogant, don't listen and don't understand
>> squat.
>>
>> I'm sorry if I gave you impression that I was looking for the bad parts in
>> the software. I apologized for that already. All I wanted was to have
>> constructive conversation, perhaps I'm not too good at it. Code is already
>> perfect according to you? Fine with me.
>>
>>
>> Anthony Minessale-2 wrote:
>> >
>> > 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........
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26633739.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
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 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
>
>

-- 
Kristian Kielhofner
http://www.astlinux.org
http://blog.krisk.org
http://www.star2star.com
http://www.submityoursip.com
http://www.voalte.com