That is one of the benefits of sangoma hardware.<br>They have an mtu value in the driver you can set to 80 (10ms) which despite the interval the channel is using<br>it will operate at 10ms interrupts. Digium's zaptel, umm i mean dahdi uses the aforementioned masturbation technique and any hardware that interfaces to it must comply. Since most of use do not want to be forced to masturbate with dahdi we are seeking an alternative, hence OpenZAP<br>
<br>OpenZAP so far is only a user land interface with plug-ins for i/o and signaling.<br>Eventually the goal is to make a cross-platform kernel layer interface as well that can abstract TDM and RTP hardware alike and allow the creation of handles that can be cross-connected inside the kernel as well as in and out of userland depending on the needs.<br>
<br><br><br><br><div class="gmail_quote">On Fri, Jan 30, 2009 at 10:03 AM, Jan Berger <span dir="ltr"><<a href="mailto:janvb@live.com">janvb@live.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
It's an old hand-rule, nothing more.<br>
<br>
The ideal situation would be 1 byte - 0.125 ms latency in switching, but this means a computer masturbating at 8000 interrupt a second - and can you imagine what this will do with your CPU?<br>
<br>
Write a small test application that perform memcpy operations and calculate the transer rate.<br>
<br>
When test on 1 byte, 5 bytes, 10 bytes 25 bytes 50 bytes<br>
<br>
What you will see is that the transfer rate increase with the size of the packet - 50 byte is ca 50 byte faster than 1 byte in x-fer.<br>
<br>
Now test with 100 bytes 250 bytes 500 bytes 1000 bytes etc<br>
<br>
And you will see that little has changed from ca 50 bytes in xfer rate.<br>
<br>
48 byte basicaly is a good trade between latency and cpu usage. The test might vary dependent on processor , but....<br>
<br>
---<br>
<br>
10 ms is however more or less the same, and might be a better number today. It goes for 711, 729 and 723 ...<br>
<br>
Jan<br><br><br>
<hr>
<br>
From: <a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</a><div class="Ih2E3d"><br>To: <a href="mailto:freeswitch-dev@lists.freeswitch.org" target="_blank">freeswitch-dev@lists.freeswitch.org</a><br>
</div>Date: Fri, 30 Jan 2009 09:35:44 -0600<br>Subject: Re: [Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters - status<div><div></div><div class="Wj3C7c"><br><br>Can you elaborate on this G.711 at 6ms? I have never seen this odd number.<br>
<div><br></div>
<div>/b</div>
<div><br>
<div>
<div>On Jan 30, 2009, at 9:30 AM, Jan Berger wrote:</div><br>
<blockquote><span style="word-spacing: 0px; font-family: Verdana; font-style: normal; font-variant: normal; font-weight: normal; font-size: 13px; line-height: normal; font-size-adjust: none; font-stretch: normal; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate;">hi Hans,<br>
<br>The standard for a PABX on G.711 is 6ms packaging of data - this is 48 byte per channel. If you go higher than this you start getting to much latency, if you go lower than this you start using to much CPU.<br> <br>400 byte is 50ms, meaning we have spent a lot of the latency budget already here, but this shoud be run-time configurable per channel as per need.<br>
<br>- G.711 6 ms<br>- IVR is 250 ms<br>- 729 10 ms<br>- 723 30 ms<br> <br>etc.<br> <br>You need to take into consideration that you are on a system with 8, 16 or 32 E1's of whick some is running IVR, others SIP, others swicthing back out on a different E1 etc.<br>
<br>Jan<br> </span></blockquote></div><br></div><br></div></div><div class="Ih2E3d"><hr>Get news, entertainment and everything you care about at Live.com. <a href="http://www.live.com/getstarted.aspx" target="_blank">Check it out!</a></div>
</div>
<br>_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>