1) It is not recommended to mix TSAPI, DMCC on a common CLAN (nor is it recommended to mix Communication Manager CLAN consumers on a CLAN (e.g. AE Services Transport links, and H.323 Station Registrations). This is because the different services do not negotiate between themselves to make sure they do not overwhelm the CLAN.
2) For TSAPI/CVLAN and ASAI APIs, the traffic is transported over one or more "transport links" which are also referred to as "application enablement connections" (AECs). An AEC is a socket connection between AE Services and a Communication Manager C-LAN or procr IP interface.
A specific socket connection between AE Services and a specific C-LAN or procr has a messages per second capacity limitation. From AE Services to Communication Manager, the limit is 200 messages/second. From Communication Manager to AE Services the limit is 240 messages per second.
In aggregate across all Transport Links, no more than 720 messages can be sent from AE Services to Communication Manager per second. Similarly, although this is a different count of different messages, no more than 720 messages can be sent from Communication Manager to AE Services per second.
Further, each AE Services server can send no more than 720 messages per second to ALL the Communication Managers that it may interface to. Similarly, although this is a different count of different messages, no more than 720 messages can be sent from a specific Communication Manager to ALL of the AE Services servers that it interfaces to. This is the same 720 messages per second as the prior case, just expressed from a different perspective.
Converting the number of supported messages per second into a statement of how many device monitors/observers/domain controls, etc. that can be supported is a function of understanding the call flow and event patterns that are expected. This level of analysis is typically done by performing some test calls, and extrapolating the results and adding in a margin of error.
3) If a CLAN is saturated you will find events in Communication Manager's hardware error log indicating that high watermarks for Congestion on the CLAN were hit. See below for details of where I uncovered that information.
4) For DMCC a maximum of 400 device registrations per CLAN is supported. A 15% capacity reduction is incurred for encryption. Congestion for DMCC is usually observed as 'slowness' in receiving events or in registering.
With both DMCC and the other group of APIs, there is buffering that is occurring at both ends of the connection that will allow the systems to smooth out traffic peaks. It will take sustained rate traffic beyond the supported maximum level for the transport links for many seconds before traffic is lost. If traffic is lost, the links will be reset, which is very noticeable.
No, sorry. There is not a more granular log of traffic rates that you can access. Perhaps by using an external tool (e.g. ethereal) you can collect and display the statistical traffic rates you would like to monitor.
Some interesting SAT commands?
-- list measurements clan Ethernet
-- test number 600 is the Congestion Query Test for the CLAN, error codes 1,2 & 3 would indicate congestion.
From page 1166/1930 in 233119_5.pdf of CM 5.1 documentation CD.
CLAN-BD errors in the hardware error log:
Error Type 2817-2819: Congestion Query test (#600) failed.
-- Error Type 2817: All buffers exhausted.
-- Error Type 2819: Utilized buffers exceed threshold
1. Refer to the Congestion Query Test (#600) for repair procedures
From page 645 of document 03-300430_4.pdf of CM 5.1 documentation CD.
|