On Thursday 23 March 2006 02:29, Reza - Asterisk Enthusiast wrote: > My question is quite simple: What is the real purpose of a "timing device" > for Asterisk, and in this * case, what really is a "timer". Is it just a > traditional "timing" device keeping track of time etc... or something > more?
As Jim mentioned, the telephone network requires a "metronome" to ensure that all points are in sync with each other. That's the purpose of this timing device. It's a periodic tap on the shoulder saying "you need to do something now," except when it comes to telephony it's not just your wife tapping you on the shoulder every five minutes hoping that this time you'll put the computer down and do what needs to be done; it's an 80-year old German nun with a Swiss time institute-calibrated stopwatch and a big bruise-inducing wooden spoon tapping you on the shoulder at PRECISE and CAREFULLY MEASURED intervals. When she taps, you must accept an audio frame from her (well 8, see below) and you must also give her an 8 audio frames. If you don't, she is going to beat you with that spoon. That's kind of what it's like with telephony. When the clock says it's time to move, you must move. You must exchange a full frame of information (I'm simplifying here, but I can get obscenely technical if you like) or you will have a condition known as a frame slip -- either you will drop information from them, or they will get partial information from you. Either way it's bad. Your conversations start to get little buzzes and chirps in them, or you can get a fragment of someone else's conversation in your own, etc. You don't want to do that, you want to work in lock-step with whoever you're connected to. The timing devices provide the mechanism or drumbeat to make sure you work this way. > We all take it for granted that it provides some sort of timing > feature/mechanism that is needed for Asterisk to function properly, if we > wish to have the MeetMe function or the Music On Hold function... to > supposedly improve the sound quality of the music when MoH is activated. It's the nun I mentioned above. It's the mechanism that Asterisk uses to ensure that the voice traffic is handled in lock-step with the rest of the system. > The exact same answers I have continued to receive is, "You need the timing > device for the MoH & MeetMe function... if you want * to work well... you > need it... you have no choice... ztdummy isn't good enough so it's best > that you have a zaptel hardware to provide accurate timing capability". > -- and of course my question comes back to "what is this timing capability" > and then there is no answer. Telephony works on a 125us period. That's 8000 "exchanges of information" a second. Zaptel processes 8 of these at a time to try and get the interrupt rate down to a more reasonable level, which is why you get 1000 interrupts a second with Zaptel. Computers are powers-of-two systems. As such, almost everything revolves around some 2^n number. RTC and USB clock sources are no exception. You can get a 1024Hz interrupt out of the RTC or USB, but you can't get 1000Hz. If it sounds like it's "close enough" it isn't. You are pressing to exchange information (in this case 8 audio frames) faster than that data is actually available. Over the course of a second, you want to process 24*8 more frames than anyone else you're connected to. They either return a "bugger off" return code to you or they fake the information. Either way it sounds bad. The newer ztdummy code does try to smooth this out by dropping interrupts to try and maintain an overall 1000Hz interrupt rate, but it's still not perfect. There is some mention of a software phase-locked-loop implementation for ztdummy that should help quite a bit, but I haven't seen any code for it yet. Ultimately you want 1000 interrupts a second and if you don't have EXACTLY 1000 interrupts per second, you will eventually slip frames and your voice quality will go down. The more often you slip, the worse it will sound. Remember that MeetMe (for example) is mixing an arbitrary number of audio sources. Everyone has to agree on how much data per interval they are going to send. If everyone sends 20ms of data at a time everything is great and it sounds good. However if you have some SIP phones sending enough data for 20ms and Asterisk is taking that and mixing it together just slightly faster than 20ms (in the case of ztdummy), or if you have some phones sending 20ms of data at a time and another Asterisk system sending 20ms of data every 18ms (duplicating or fudging data to make it fit) and the box running MeetMe is mixing everything every 977us instead of every 1000us... well you can see how this becomes a nasty little problem. It's like trying to put a puzzle together after your kids have taken every puzzle in the house and mixed it into one box. (not that this has ever happened with my kids, nooooo.) It'll almost work, but it just won't be as pretty as it could be if you just had pieces of all the same size, and from only one puzzle. > So... here are my questions again in brief: > 1.. What really is a Timing Device in Asterisk? > 2.. Why do we need this for the MoH & MeetMe function? Answered above. > 3.. Is ztdummy good enough in a 100% VOIP setting (100% of traffic is > through your NIC)? 4.. Does ztdummy have any limitations when compared to > timing devices in ZAPTEL interfaces? 5.. Does ztdummy utilize a lot of CPU > process? Ztdummy isn't required for 100% VOIP systems unless MeetMe or MOH is used, for the reasons outlined above. Until (very) recently, Asterisk relied on the far-end to send packets at exact intervals, because Asterisk used the packets themselves as the timing source. For anything on the LAN this is okay, but as soon as you introduce lag or jitter or dropped packets, things fall apart fast. The SIP and IAX2 jitter buffers are "self-timed" meaning they use an internal timer to schedule when audio must be squirted out, which is the proper way to do this. If there is no audio to send when it's time (i.e. when that nun taps you on the shoulder and you don't have something to give her) what do you do? You can't give her nothing so you either fake it and give her an approximation of what you think the finished product should be (this is called Packet Loss Concealment, very cool), or you give her a copy of the last bit of information and hope she doesn't notice, or you might give her an empty shell, but you give her something. Thankfully the nun doesn't care what you give her, but she will take that to someone else and give it to them, and if it doesn't have what was expected, they'll start doing things like asking "Pardon? I didn't make out that last word. What did you say?" and eventually "Your phone system sucks. I'm going to call Jim and ask him for a Norstar system, because VOIP just sucks." > 6.. Technically the ztdummy under Linux 2.4 utilizes the UHCI-USB which > is the hardware minus the FXO/FXS - so why would ztdummy not be good > enough? This is incorrect. UHCI is the host-side. Certain USB host controllers have a timer on them which ztdummy can use. It's like the RTC driver though -- powers of two are in vogue, not powers of ten. So 1024Hz is what you get, not 1000Hz. > 7.. In Linux 2.6, according to " > http://www.voip-info.org/wiki/view/Asterisk+timer ", ztdummy uses high > resolution kernel timer. Is this "high res. kernel timer", 100% software > driven, or takes advantage of the internal hardware clock on the > motherboard or takes advantage of the UHCI/OHCI USB controller? I guess > people who work with or write device drivers will truly appreciate my > questions. Would love to hear thoughts & inputs on these theoritical > questions, my soul is seeking for, up until it finds other things to ponder > about :) Basically the kernel has the resources to provide a good 1000Hz software interrupt. I believe that the original decision to tie MeetMe/MOH to zaptel was to try and lock people into Digium hardware. Software timers are good enough for most applications. Anytime you are tying to the PSTN through digital means (PRI, T1/E1), you want to use their clock source, though. The SIP and IAX2 PLC jitter buffers both use software timers for the 20ms interrupt, and they work reasonably well. My personal opinion is that unless your system's hideously overtaxed you will have no trouble with a pure software timer, provided that the kernel can deliver exactly 1000 interrupts per second (which it can). If you're connecting to Real Telco Hardware, you want to let them lead, so to speak. Hopefully this addresses your questions. -A.
