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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> 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:[email protected] > GTALK/JABBER/PAYPAL:[email protected] > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] > iax:[email protected]/888 > googletalk:[email protected] > pstn:213-799-1400 > > _______________________________________________ > FreeSWITCH-users mailing list > [email protected] > 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 _______________________________________________ FreeSWITCH-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
