That is one of the benefits of sangoma hardware.
They have an mtu value in the driver you can set to 80 (10ms) which despite
the interval the channel is using
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

OpenZAP so far is only a user land interface with plug-ins for i/o and
signaling.
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.




On Fri, Jan 30, 2009 at 10:03 AM, Jan Berger <ja...@live.com> wrote:

>  It's an old hand-rule, nothing more.
>
> 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?
>
> Write a small test application that perform memcpy operations and calculate
> the transer rate.
>
> When test on 1 byte, 5 bytes, 10 bytes 25 bytes 50 bytes
>
> 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.
>
> Now test with 100 bytes 250 bytes 500 bytes 1000 bytes etc
>
> And you will see that little has changed from ca 50 bytes in xfer rate.
>
> 48 byte basicaly is a good trade between latency and cpu usage. The test
> might vary dependent on processor , but....
>
> ---
>
> 10 ms is however more or less the same, and might be a better number today.
> It goes for 711, 729 and 723 ...
>
> Jan
>
>
> ------------------------------
>
> From: br...@freeswitch.org
> To: freeswitch-dev@lists.freeswitch.org
> Date: Fri, 30 Jan 2009 09:35:44 -0600
> Subject: Re: [Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters -
> status
>
>
> Can you elaborate on this G.711 at 6ms?  I have never seen this odd number.
>
> /b
>
>  On Jan 30, 2009, at 9:30 AM, Jan Berger wrote:
>
> hi Hans,
>
> 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.
>
> 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.
>
> - G.711 6 ms
> - IVR is 250 ms
> - 729 10 ms
> - 723 30 ms
>
> etc.
>
> 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.
>
> Jan
>
>
>
>
> ------------------------------
> Get news, entertainment and everything you care about at Live.com. Check
> it out! <http://www.live.com/getstarted.aspx>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org>
pstn:213-799-1400
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

Reply via email to