Hi,
I have digiums licenses, Just downloaded 64-bit g729 codec and the glibc2.3.5 register utility for my "AMD ATHLON 64 3500+ SOCKET AM2,
2.2GHZ L1"
found a documentation from the “asterisk announce” update that the new 64 bit versions of g729 were complied using gcc 4.0.1. I have gcc 3.4.4.
Does this matter? Also that the digium dowload site had only Opteron and I have AMD Athlon. Will the opteron g729 codec be fine for my above HW?
any thoughts will be appreciated.
thanks[/b]
the compiled using gcc4 does not matter. It just means that the gcc 4.x tool was used to compile the code. it does not matter if you use gcc 3.x on your system.
For ‘opteron’ means that it is compiled for the AMD64 (x86-64) instruction set. It will run on your CPU, as the athlon 64 also uses X86-64.
Keep in mind that you must of course be running a 64bit distro, 64bit kernel, etc etc.
Thank you for you kind suggestions. It helped.
my experience running asterisk in a x86_64 environment did not meet with success. While on the surface everything seemed to function ok I was experiencing a loss of service that would happen at irregular intevals.
Basically asterisk would experience a race condition causing the asterisk process to use 99.9% cpu but at the same time chan_iax would go tits up and stop communicating with all of its peers. If you could get on the machine within 5 minutes a ‘restart now’ would correct the problem. A longer delay would force a ‘kill -9’ on the asterisk process in order to recover. Sometimes this happened every couple of days, some days 3 or 4 times a day. Because it was a race condition and never resulted in a crash or dump there was no core file to submit.
After weeks, perhaps even a couple months, of trying to find anyone having this problem (not to mention upgrading asterisk on every release hoping that the changelog remarks about race condition fixes addressed my problem) I started to question the viability of using x86_64. The change back to an i386 OS completely resolved my issues. My conclusion was that there just weren’t enough people running or using x86_64 to address critical bugs like this. I decided to hold off on x86_64 until 50% or more of the development community was running on it before I put it into a production environment.
Im running asterisk on a quad core opteron system using Mandriva 2006 x86_64 SMP. And it was quite rocky to begin with, mainly getting the zaptel modules to install in the right place. But I must say its been stable as a rock except for one time with IAX2. It was like you said IAX2 would refuse to comunicate to any peer and complain of a timout when actually the connection is fine. I just did a reload on the server and the peer and it was fine.
Best thing is a load average of 0.02 - 0.06 with 12 simultaneous zap to sip calls with mixmonitor and moh running too! 