Another useful advantage without the latency tradeoff is to read a
full span or card every 1ms (or whatever sane interval) and chop up
the bytes in userland. The latency argument dies if you are bridging
to voip, so if you can handle bridging the tdm to tdm channels in
kernel space, you could easily get away with 10ms reads to user space
as well.
Mike
On Jan 30, 2009, at 11:11 AM, Anthony Minessale wrote:
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!
_______________________________________________
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
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@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
_______________________________________________
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
