Have you tried using high definition video streams with 5ms sample payloads? It will kill a vm box very quickly. You need serious real resource to scale and not a time sharing virtual environment for such application.
On Jan 30, 2011, at 4:28 PM, Stefan Sayer wrote: > o Adrian Georgescu on 01/28/2011 10:50 PM: >> Think about what happens under load when you must act at every 5 or 10ms >> intervals for each single stream. A virtual environment will lose its >> real-time properties under load. You can send emails and serve web pages >> without noticeable impact but real time media like audio and video does not >> tolerate same conditions without losing quality. >> It does not work properly for any software Asterisk or not, is a wrong >> question to ask in the first place. There is a reason Asterisk needs >> accurate timing, what you do with your virtual box you take things to the >> opposite extreme and provide the most inaccurate timing and wonder what is >> wrong with Asterisk. Nothing is wrong, you are using it wrongly and complain >> for the wrong reasons. > honestly I don't understand what everyone has with this 'i need an accurate > timing source'. if you are not interfacing to TDM directly this is totally > bogus and not required. packet based voip is elastic within limits, and those > limits are usually much less stringent, compared to accuracy of usleep(3) > virtualized or not, and the added jitter due to scheduling on the VM host. > e.g., if you use 20ms packet length, those limits are never less than 10ms, > and a timing source more accurate than that is not needed. usually, due to > jitter buffers' minimal size, you don't even need 10ms accuracy. > > regarding clock skew - which may or may not be worse in VM environment - both > your media server/conference bridge and your UA should have some adaptive > jitter buffer which alleviates that anyway, either in a clever way (e.g. time > stretching) or in some not so clever way. > > of course you will run into problems if you overload your physical machine, > or if your VM scheduler starves your guest of CPU for more than, say, two > times a packet length. but both usually ocures more frequently in relation to > disk IO, network or hardware issues, and its the same whether virtualized or > not. > > Stefan > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
