I'm running asterisk as root. I've done something interesting. I have modified the chan_ss7 in order to work with zaptel HDLC. I mean dchan and hardhdlc in zaptel.conf. The modification is on mtp.c replacing the read_su where it is doing the fast_hdlc and crc test, etc. With dchan option, appears some ZT_EVENT_BADFCS and ZT_EVENT_ABORT errors after doing a "ioctl(fds[i].fd, ZT_GETEVENT, &x)" Another test I did also was changing dchan by hardhdlc in zaptel.conf, and with hardhdlc, it works without problem. Just one thing happened to me with hardhdlc and only one time, I hope it be the last. I'm running and IBM x346 with a Wildcard TE410P (3rd Gen), and at the first test with hardhdlc, my server rebooted with and error "Uhhuh. NMI received for unknown reason 35 on CPU 0." After this reboot, it doesn't appear again. I'm still testing.... On 06 Nov 2006 08:03:16 +0100, Kristian Nielsen <knielsen@xxxxxxxxx> wrote: > "Robert Kenton" <robert.kenton@xxxxxxxxx> writes: > > > I've tested with just 60 channels, and even when the 60 channels are > > not fully used, appears too much "mtp.c: MTP2 bitstream frame format > > error, entering octet counting mode..." and after that some of these > > messages, the link goes down. > > Did you start Asterisk as user root, so it can use real-time priorities? > > The chan_ss7 architecture splits the work-load in two parts, only one of which > has real-time requirements, and runs the critical part at a high real-time > priority to make sure it gets sufficient CPU. However, Linux real-time > priorities require root privileges. > > BTW, doing 60 calls within a single second, you might want to calculate > whether you have sufficient bandwidth on your signalling link. But even so, it > should not cause the MTP2 layer to drop. > > - Kristian. > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-ss7 mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-ss7 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20061106/e20916de/attachment.htm