Your description makes perfect sense. My system is still getting HDLC
overruns, which are certainly a consequence of frame slips because the
second card is not getting clocked from the external source.
I come back to my basic question:
How do you configure an asterisk system so that a
Your description makes perfect sense. My system is still getting HDLC
overruns, which are
certainly a consequence of frame
slips because the second card is not getting clocked from the external source.
I come back to my basic question:
How do you configure an asterisk system so that a
Yes. I've tried:
- ztcfg
- rmmod the wct4xxp module and zaptel and modprob'ing again
- rebooting the server.
No matter what I do, the second card is always "internally clocked".
The E1 I have plugged into that board is good. It can clock the first
card just fine.
This is my complete
Guess at this point I'd call digium support and open a ticket.
Yes. I've tried:
- ztcfg
- rmmod the wct4xxp module and zaptel and modprob'ing again
- rebooting the server.
No matter what I do, the second card is always internally clocked. The E1 I
have plugged
[SNIP]
What if you have a single port T1/E1 card from digium? No decision to
be made really; you're going to sync from the other end if it goes
higher in the hierarchical chain. If the port goes to a box consider
lower in the chain, then the distant box should be configured to
accept
inline...
I've read the early posts relating to this and there still seems to be
a misunderstanding on this clock sync issue. This stuff has been around
for a long time in the telephony business, but it seems like not
many people understand it on this list.
IT is true it is a
On Sat, 27 Nov 2004, Rich Adamson wrote:
True. However, you want to distribute the clocking to _all_ your
downstream peripherials to avoid the equivalent of frame-slips. If your
cards are not clocked the same exactly you will need to invent/drop a
freme efery now and then. That is why
True. However, you want to distribute the clocking to _all_ your
downstream peripherials to avoid the equivalent of frame-slips. If your
cards are not clocked the same exactly you will need to invent/drop a
freme efery now and then. That is why most people want to lock a second
On Sat, 27 Nov 2004, Rich Adamson wrote:
There is a
buffer but the buffering can only handle jitter, not compensate for
frequency difference.
No, you're assuming a one-byte (or very small) buffer, and that's not
what's going on in asterisk.
You misunderstand me. I know that the
There is a
buffer but the buffering can only handle jitter, not compensate for
frequency difference.
No, you're assuming a one-byte (or very small) buffer, and that's not
what's going on in asterisk.
You misunderstand me. I know that the buffers are larger. However, even if
On Sat, 27 Nov 2004, Rich Adamson wrote:
You misunderstand me. I know that the buffers are larger. However, even if
they are 1 second deep they will eventually empty / overrun. There is no
way about this except to either allow data to be invented/dropped or to
keep the source and sink
Fernando,
I experienced some problems like you reports now, and I solved making an
upgrade to the OS. Redhat 8.0 has an old kernel and there are some
issues about disk access that can cause that problem. There is no enough
kernel upgrades on RH8 to fix it, so try to move to Fedora Core 1 and
You were right. It was a PCI latency issue. I played with this thing
for hours until I realized that I got no IRQ misses on the second card
until my agents logged into the system using IAX. As soon as the first
one logged in, IRQ misses started.
I played with the latency on the Digium cards,
On Fri, 2004-11-26 at 09:17 -0600, Dr. Fernando Macas Garza wrote:
[snip]
* Why the second card will always say it is internally clocked,
although it has a telco line connected to it and span 1 in that card
is configured as a sync source.
[snip]
Doesn't sync source mean that the card is
On November 26, 2004 11:06 am, Patrick wrote:
Doesn't sync source mean that the card is generating its own clocking?
If your telco provides the clocking, the card should not.
No.
0 = don't use the remote clock for sync (use internal clock)
1 = use remote clock as card's primary clock source
2
On Fri, 2004-11-26 at 11:36 -0500, Andrew Kohlsmith wrote:
[snip]
No.
0 = don't use the remote clock for sync (use internal clock)
1 = use remote clock as card's primary clock source
2 = use remote clock as card's secondary clock source
3 = ...
The doc says this: To not use this span as a
On Fri, 26 Nov 2004, Andrew Kohlsmith wrote:
On November 26, 2004 11:06 am, Patrick wrote:
Doesn't sync source mean that the card is generating its own clocking?
If your telco provides the clocking, the card should not.
0 = don't use the remote clock for sync (use internal clock)
1 = use
On Fri, 26 Nov 2004, Patrick wrote:
On Fri, 2004-11-26 at 11:36 -0500, Andrew Kohlsmith wrote:
[snip]
No.
0 = don't use the remote clock for sync (use internal clock)
1 = use remote clock as card's primary clock source
2 = use remote clock as card's secondary clock source
3 = ...
On Fri, 2004-11-26 at 18:05 +0100, Patrick wrote:
On Fri, 2004-11-26 at 11:36 -0500, Andrew Kohlsmith wrote:
[snip]
No.
0 = don't use the remote clock for sync (use internal clock)
1 = use remote clock as card's primary clock source
2 = use remote clock as card's secondary clock
On Fri, 26 Nov 2004, [ISO-8859-1] Dr. Fernando Macías Garza wrote:
Configuration for first span on card 1 is:
span=5,1,0,ccs,hdb3
bchan=118-132
dchan=133
bchan=134-148
However, zttool reports card as Internally Clocked. No matter how I've
tried, I cannot get card 1 to clock from the
On November 26, 2004 12:05 pm, Patrick wrote:
0 = don't use the remote clock for sync (use internal clock)
1 = use remote clock as card's primary clock source
2 = use remote clock as card's secondary clock source
3 = ...
The doc says this: To not use this span as a sync source, use '0'.
On November 26, 2004 12:27 pm, Steven Critchfield wrote:
Another logic step to help strengthen this bit of knowlege would be that
on 1 TE4XX card, I can connect one port to a Telco provider and one port
to a channel bank. The telco port is the one we would need to derive our
sync from as it is
On Fri, 26 Nov 2004, Andrew Kohlsmith wrote:
There can be only one clock and you must engineer your system such that
everything is synchronized properly. For simple systems like what we are
describing it's not difficult but when you have multiple spans coming from
multiple providers it
On November 26, 2004 01:47 pm, Peter Svensson wrote:
I think it would be nice if the zaptel card could be used as a high
precision frequency source for ntpd. It is probably no that hard even.
Hmmm...
-A.
___
Asterisk-Users mailing list
[EMAIL
Peter Svensson wrote:
On Fri, 26 Nov 2004, Andrew Kohlsmith wrote:
There can be only one clock and you must engineer your system such that
everything is synchronized properly. For simple systems like what we are
describing it's not difficult but when you have multiple spans coming from
It seems to me that if not all cards are clocked from the same source,
then each one should be able to get its own external clock. However,
card 0 has an external clock, but card 1 does not. Look at this:
#cd /proc/zaptel/
# grep ClockSource *
1:Span 1: TE4/0/1 "TE410P (PCI) Card 0 Span 1"
On Sat, 27 Nov 2004, Steve Underwood wrote:
Peter Svensson wrote:
Most providers should be synchronized to a traceable time source derived
from UTC. I.e. they should all tick exactly the same even if they are not
directly interconnected.
Uh? UTC? I think you mean derived from a
On Fri, 26 Nov 2004, Dr. Fernando Macías Garza wrote:
It seems to me that if not all cards are clocked from the same source,
then each one should be able to get its own external clock. However,
card 0 has an external clock, but card 1 does not. Look at this:
[snip]
I am sure the line
I have an open ticket for this item. If it leads anywhere, I'll post it
in the mailing list.
Fernando
On Nov 26, 2004, at 2:26 PM, Peter Svensson wrote:
On Fri, 26 Nov 2004, Dr. Fernando Macías Garza wrote:
It seems to me that if not all cards are clocked from the same source,
then each one
It seems to me that if not all cards are clocked from the same source,
then each one should be able to get its own external clock. However,
card 0 has an external clock, but card 1 does not.
I've read the early posts relating to this and there still seems to be
a misunderstanding on this
On Fri, 26 Nov 2004, Rich Adamson wrote:
[SNIP]
What if you have a single port T1/E1 card from digium? No decision to
be made really; you're going to sync from the other end if it goes
higher in the hierarchical chain. If the port goes to a box consider
lower in the chain, then the distant
On Fri, 26 Nov 2004, Rich Adamson wrote:
I've read the early posts relating to this and there still seems to be
a misunderstanding on this clock sync issue. This stuff has been around
for a long time in the telephony business, but it seems like not
many people understand it on this list.
I've been running Asterisk for months with no problems. I have grown to
the point where I need an aditional TE cards. After many attempts I was
able to add the second card without affecting the performance of the
first. However, the second card is not working properly.
Setup
=
- Running on
Problems
- Choppy voice on calls between channels of card 1.
- Even worse on calls between card 0 and card 1.
- Card 0 behaves well.
- IRQ misses for card 1. Have tried different interrupts. Same thing.
- HDLC overrun messages on console for card 1.
Almost sounds like the
On Thu, 25 Nov 2004, Rich Adamson wrote:
However, zttool reports card as Internally Clocked. No matter how I've
tried, I cannot get card 1 to clock from the external source:
Sync Source:Internally clocked
First span on card 0 is configured just the same:
35 matches
Mail list logo
