Sunday, October 08, 2006
New ss7box blog location
The ss7box blog has moved to the wiki because some people cannot reach the blogger.com website.
Thursday, July 13, 2006
SMG High Capacity Testing
The Sangoma Signal Media Gateway continues to take a beating in the lab with five E1 continuously running at full capacity with short duration phone calls. Quite a few problems have been shaken out and the limits of the particular machines being used are showing. System engineering rules have also been developed as a result of this testing program. The test grow to support eight E1 and a third SMG in the near future.
The ss7box wiki is newly revamped with improved product plan sections. Have a look to see what's in store for SMG.
ss7mon will be called upon to examine working SS7 links as part of recent changes to our method of operation for replacing existing systems. Experience teaches that reported configuration information and actual configuration can differ. By using ss7mon we will be able to verify configuration parameters before swinging service to a new system. ss7mon will also let us measure the health of the existing system before putting a new system into service. ss7mon uses the same hardware as ss7box and uses a simple passive tap cable and couplers to access the working SS7 circuit. A brief service interruption is required to install the circuit tap.
The ss7box wiki is newly revamped with improved product plan sections. Have a look to see what's in store for SMG.
ss7mon will be called upon to examine working SS7 links as part of recent changes to our method of operation for replacing existing systems. Experience teaches that reported configuration information and actual configuration can differ. By using ss7mon we will be able to verify configuration parameters before swinging service to a new system. ss7mon will also let us measure the health of the existing system before putting a new system into service. ss7mon uses the same hardware as ss7box and uses a simple passive tap cable and couplers to access the working SS7 circuit. A brief service interruption is required to install the circuit tap.
Sunday, June 04, 2006
ss7box Wiki Finds New Home
The ss7box wiki has a new home at none other than the ss7box website. Things are still being reassembled from various repositories. We are looking forward to using the new wiki. It's time to refresh the product plan.
Friday, May 26, 2006
SMG New Release
A new revision of Sangoma SMG is being released. This new revision is the result of extensive testing in the SMG bulk call generation lab in Toronto. This lab has proven itself capable of creating a punishing load similar to a unrelentless regional crisis. The systems under test were also misconfigured intentionally to increase the chance of circuit dual seizure occuring. In order to survive in the test, some parts of the SMG had to be redesigned and optimized. This was not surprising after it was done, but figuring out where the redesigns were needed was a difficult process. The latest release of SMG is solid foundation on which to continue building this product.
New installations are keeping us busy. The installation process in much closer to being fully automated now with the release of the smginstall tool in the latest SMG release. Some of our regional representatives are using the tool to successfully install and run SMG at customer sites.
Sadly we must report a HDD failure on the host of the ss7box Wiki. Alternatives are being considered and this tool should return to service before long. Backups were made. We are just not sure how fresh they are.
Currently we are working on expanding ISUP support to the lesser used messages. We are starting to see regional differences and operator differences. We are working with multiple linkset and multiple trunk group configurations now. We have a distributed SS7 presence experiment on-going and we are working on media gateway clustering capabilities. There's a lot to do but we are making forward progress daily and the results are tangible.
New installations are keeping us busy. The installation process in much closer to being fully automated now with the release of the smginstall tool in the latest SMG release. Some of our regional representatives are using the tool to successfully install and run SMG at customer sites.
Sadly we must report a HDD failure on the host of the ss7box Wiki. Alternatives are being considered and this tool should return to service before long. Backups were made. We are just not sure how fresh they are.
Currently we are working on expanding ISUP support to the lesser used messages. We are starting to see regional differences and operator differences. We are working with multiple linkset and multiple trunk group configurations now. We have a distributed SS7 presence experiment on-going and we are working on media gateway clustering capabilities. There's a lot to do but we are making forward progress daily and the results are tangible.
Thursday, April 20, 2006
Bulk Call Testing Underway in Lab
The Sangoma SMG is undergoing bulk call generation testing in the lab. This battery of tests allows measurement of capacity, system load, endurance, accuracy, and reliability. In the past week since starting to use this test system, the problem find/fix rate has increased significantly. Also noticable is the elevated confidence felt by system designers and testers.
The bulk call tester was conceived and built in-house. It already has the ability to test Release 2 SMG systems having multiple networked call processing nodes. The system is easy to use and can be controlled remotely so that a geographically diverse development team can all control the test system as though they were in the same room with it.
Nanad Corbic, Chief Software Manager of Sangoma Technologies, Inc. says, "With the bulk call tester we expect to test SMG configurations handling 3000 or more circuits at very high levels of utilization. Already we see demand for SMG systems of this size."
The bulk call tester was conceived and built in-house. It already has the ability to test Release 2 SMG systems having multiple networked call processing nodes. The system is easy to use and can be controlled remotely so that a geographically diverse development team can all control the test system as though they were in the same room with it.
Nanad Corbic, Chief Software Manager of Sangoma Technologies, Inc. says, "With the bulk call tester we expect to test SMG configurations handling 3000 or more circuits at very high levels of utilization. Already we see demand for SMG systems of this size."
Thursday, March 16, 2006
SMP-Safe Queues Rule
Spinlocks are out, SMP-safe queues are in. All sites have been upgraded and have been running for several days without interruption.
Spinlocks, like any semaphore, should be avoided if possible - or so the conventional wisdom goes. And we understand a bit more about why it is considered conventional wisdom now.
SMP-safe queues have mutually exclusive read and write methods so that both operations can occur simultaneously. In our MTP2 implementation there is a single reader and writer for each of four queues. Three of the four queues are exposed to the potential for simultaneous reading and writing.
Spinlocks, like any semaphore, should be avoided if possible - or so the conventional wisdom goes. And we understand a bit more about why it is considered conventional wisdom now.
SMP-safe queues have mutually exclusive read and write methods so that both operations can occur simultaneously. In our MTP2 implementation there is a single reader and writer for each of four queues. Three of the four queues are exposed to the potential for simultaneous reading and writing.
Wednesday, March 08, 2006
Announcing the Sangoma Signal Media Gateway
The SS7 ISUP attachment to Linux based softswitches finally has a name: Sangoma Signal Media Gateway. We call it SMG for short. Having a product name makes conversations and documenting so much easier. Here's a link to a product description: http://sangoma.editme.com/wanpipe-linux-asterisk-ss7
Installations in Pakistan, Paraguay, Manilla, Rome, and Michigan are helping us hone the installation process and are getting efficient at finding quality issues (bugs). They are pushing us further and faster along than we would have on our own. Thanks and keep up the good work.
The kernel module MTP2 had a set of nasty bugs that were cured with restructuring the buffer management scheme and surrounding a few critical section in the code with spinlocks.
We have introduced a trouble ticket system to track bugs. We give users access to the system so they can check up on our progress and make sure we are staying focused.
We found that we'll need to support overlap signalling in the early release of the SMG. Several locations cannot mandate en bloc signalling. The specs are a little weak in specifying how overlap signalling should work. Thanks to some attentive and knowledgeable users we captured the information we needed to complete the requirements we need to implement overlap signalling.
We've been told repeatedly that serving multiple E1 installations is required immediately. We identified the key item preventing us from delivering this capability is automated testing. We didn't want to deliver a multiple E1 support until we tested hundreds of simultaneous calls on a lab system. So, we designed and, are currently building, a bulk calling lab. We are going to replicate smaller versions of this lab in several places. The main lab will be able to generate thousands of simultaneous calls, verify connections, and vary hold times.
Installations in Pakistan, Paraguay, Manilla, Rome, and Michigan are helping us hone the installation process and are getting efficient at finding quality issues (bugs). They are pushing us further and faster along than we would have on our own. Thanks and keep up the good work.
The kernel module MTP2 had a set of nasty bugs that were cured with restructuring the buffer management scheme and surrounding a few critical section in the code with spinlocks.
We have introduced a trouble ticket system to track bugs. We give users access to the system so they can check up on our progress and make sure we are staying focused.
We found that we'll need to support overlap signalling in the early release of the SMG. Several locations cannot mandate en bloc signalling. The specs are a little weak in specifying how overlap signalling should work. Thanks to some attentive and knowledgeable users we captured the information we needed to complete the requirements we need to implement overlap signalling.
We've been told repeatedly that serving multiple E1 installations is required immediately. We identified the key item preventing us from delivering this capability is automated testing. We didn't want to deliver a multiple E1 support until we tested hundreds of simultaneous calls on a lab system. So, we designed and, are currently building, a bulk calling lab. We are going to replicate smaller versions of this lab in several places. The main lab will be able to generate thousands of simultaneous calls, verify connections, and vary hold times.
Sunday, February 12, 2006
MTP2 Performance Improved
The Xyganda MTP2 has been under development (off and on for the past year) for migration from user space to kernel space to improve real-time performance. Sangoma engineering has been an intergral part of this effort by providing an efficient interface to DS0 bitstreams and incorporating MTP2 kernel module installation into the Sangoma driver installation toolset.
Recent tests in a major equipment vendor's lab revealed a kernel panic which was the result of the xmtp2km kernel module not supporting SMP environments. Redesign of local buffer allocation tools within xmtp2km eliminated some access contention situations, while other access contentions that could not easily be eliminated were streamlined and protected with spinlocks.
The improved xmtp2km has survived a 90 hour duration test under heavy and light traffic loads with 0% message loss or gain. The next step is to distribute the fix to the field and continue observation of the fix in those environments.
One benefit of fixing the xmtp2km problem is that we learned that the interface between the Sangoma driver and xmtp2km is very efficient. The Sangoma driver allocates a large pool of buffers for managing the bitstream flows between itself and xmtp2km. We have never seen more than one buffer in use at any time regardless of traffic loading on the link. We also we able to transmit and receive an +80% load on a link for over 12 hours at a time without a single occurence of link congestion onset/abatement. A relatively weak computer (a single 933 Mhz Intel CPU) was in use which adds weight to our findings. These observations indicate that the code is efficient and that real-time requirements are being met with a wide margin of safety.
ISUP and CNAM development came to a full stop while xmtp2km was being debugged. We apologize for the delays in the ISUP and CNAM projects and will resume development on these applications immediately.
Recent tests in a major equipment vendor's lab revealed a kernel panic which was the result of the xmtp2km kernel module not supporting SMP environments. Redesign of local buffer allocation tools within xmtp2km eliminated some access contention situations, while other access contentions that could not easily be eliminated were streamlined and protected with spinlocks.
The improved xmtp2km has survived a 90 hour duration test under heavy and light traffic loads with 0% message loss or gain. The next step is to distribute the fix to the field and continue observation of the fix in those environments.
One benefit of fixing the xmtp2km problem is that we learned that the interface between the Sangoma driver and xmtp2km is very efficient. The Sangoma driver allocates a large pool of buffers for managing the bitstream flows between itself and xmtp2km. We have never seen more than one buffer in use at any time regardless of traffic loading on the link. We also we able to transmit and receive an +80% load on a link for over 12 hours at a time without a single occurence of link congestion onset/abatement. A relatively weak computer (a single 933 Mhz Intel CPU) was in use which adds weight to our findings. These observations indicate that the code is efficient and that real-time requirements are being met with a wide margin of safety.
ISUP and CNAM development came to a full stop while xmtp2km was being debugged. We apologize for the delays in the ISUP and CNAM projects and will resume development on these applications immediately.
Friday, January 13, 2006
Product Plan Updated
The product plan for ss7box, ss7boost, and CNAM services has been updated on the wiki. Work on ss7boost/ISUP is centered on circuit maintenance (reseting, blocking, and unblocking). The circuit maintenance state machines take effort than those for basic call processing.
The Signal Media Gateway (SMG) product description is updated. A feature that allows multiple Asterisk platforms to be served by a simplex or duplex ss7box is described in more detail. Configurations needing more T1/E1 than can be hosting in a single Asterisk platform will be possible using this feature.
In CNAM development there has been a new configuration function developed to map global title translation types to a static function id. This involved creating a new configuration section in the ss7boost.conf file. This was necessary because there seems to be no consistent industry definition for GTT types. Testing with external databases will begin next week.
The Signal Media Gateway (SMG) product description is updated. A feature that allows multiple Asterisk platforms to be served by a simplex or duplex ss7box is described in more detail. Configurations needing more T1/E1 than can be hosting in a single Asterisk platform will be possible using this feature.
In CNAM development there has been a new configuration function developed to map global title translation types to a static function id. This involved creating a new configuration section in the ss7boost.conf file. This was necessary because there seems to be no consistent industry definition for GTT types. Testing with external databases will begin next week.
Subscribe to:
Posts (Atom)