I have a CS1000M. release 7.6. I am seeing some CRMN001 errors on the TTY. The system is configured for 20000 call registers ( should be plenty ). When I look in PDT and do a sl1qShow it shows the " Print " Q as using 17500 of them. The customer does use a call accounting set up with a buffer box but no other printers or traffic configured. So my question is why is that print q so high and what else will use the CR's under that q?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
CS1000M High call register warning 2
- Thread starter MikeRizz
- Start date
-
1
- #2
Firebird Scrambler
Systems Engineer
I've found two reports that might be a clue for you below.
The first one is from an older software version.
Meridian Option 81C rls 4.50W
Unexplained high call register usage warning messages:
CRMN001 HIGH Call Reg Usage, Pcnt Used= 80, Num Used= 8002, NumCR= 10000
Although NCR was set to 10000, only 1800 were displayed by sl1qShow:
>pdt> sl1qShow
SL1 queues of size > 0
Cadence (queue 2 at 0x8c911e8) size : 1
128LowP (queue 3 at 0x8c911fc) size : 1
2Sec (queue 4 at 0x8c91210) size : 34
Dial (queue 6 at 0x8c91238) size : 1
RingAgain (queue 8 at 0x8c91260) size : 2
Idle (queue 12 at 0x8c912b0) size : 1760
total size of above queues: 1799
value = 0 = 0x0
pdt>
Cause: unknown
Solution:
Run a software audit (LD 44, R 1)
Masses of AUD575s were output and all the locked-up Call Registers were then released
pdt> sl1qShow
SL1 queues of size > 0
128LowP (queue 3 at 0x8c911fc) size : 1
2Sec (queue 4 at 0x8c91210) size : 39
Dial (queue 6 at 0x8c91238) size : 3
RingAgain (queue 8 at 0x8c91260) size : 4
Idle (queue 12 at 0x8c912b0) size : 9669
RGAT (queue 18 at 0x8c91328) size : 2
total size of above queues: 9718
value = 0 = 0x0
pdt>
#################################################
Problem
CRMN001 HIGH Call Reg Usage, Pcnt Used= 99, Num Used= 34993, NumCR= 35000
Solution
pdt> sl1crShow
MAINPM NCR
------ ---
IDLE 11
READY 14
DIALING 11
BUSY 1
RINGING 65
ESTABLISHED 400
SPECIAL 1153
CDR 32463
ACD_PM 870
MUSIC_PM 10
Total CR Count = 34998
sl1qShow (sl1crShow) told us that it was the CDR data that was using the call registers. The system at the time had many more calls coming in than normal. Answer time was becoming really long.
All channels to Call Pilot were constantly busy playing messages and other call pilot'y things. Callers listened to ring tone for a long while BEFORE contact centre could find a Call Pilot agent to give first announcements.
Real agents were all busy with calls, sometimes for 2hrs. (Hence the backlog)
Speed to Call Logging ports set at 9600 (Very slow)
It is thought that a combination of the above, was causing the QREC (time to answer an ACD call) to output more than normal to the CDR TTY. The CDR TTY buffers were getting filled up and using all the call registers. Also, suspect the system has to use call registers to measure the time it was taking to answer calls.
First we removed QREC from the CDR data on the Route Data Blocks. This reduces the amount of data being sent to the CDR device. (Removing CDR from the route would probably have the same effect)
This allowed the CDR TTY's to try and catch up (The total number of CR being used dropped by approx 20 every 5 seconds)
System was left overnight, and in the morning there was nothing stuck in the CDR Queue.
Engineer was advised to speed up the CDR TTY to the max speed it will run (To allow the buffer to empty quicker)
He was then going to put QREC back on the route and monitor.
Hopefully by getting the CDR info out the system quicker will stop the Call Registers filling up.
At this time it is not known if this worked. (I will amend this record when I know, or if it works for you, then get record amended)
If removing QREC for a while does not allow the CR to go back to normal, then system may require an INI.
DO NOT REMOVE OR CHANGE ANY CDR TTY SETTINGS WHILE SYSTEM IS IN THIS STATE. OR DELIBERATLY DIS A TTY. THIS MAY RESULT IN THE SYSTEM HOLDING ONTO THE CDR DATA, AND NEVER BE ABLE TO OUTPUT IT. AND AN INI WILL BE REQUIRED TO CLEAR.
Firebird Scrambler
Nortel and Avaya Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Very advance high level knowledge on Linux BCM with keycode support
The first one is from an older software version.
Meridian Option 81C rls 4.50W
Unexplained high call register usage warning messages:
CRMN001 HIGH Call Reg Usage, Pcnt Used= 80, Num Used= 8002, NumCR= 10000
Although NCR was set to 10000, only 1800 were displayed by sl1qShow:
>pdt> sl1qShow
SL1 queues of size > 0
Cadence (queue 2 at 0x8c911e8) size : 1
128LowP (queue 3 at 0x8c911fc) size : 1
2Sec (queue 4 at 0x8c91210) size : 34
Dial (queue 6 at 0x8c91238) size : 1
RingAgain (queue 8 at 0x8c91260) size : 2
Idle (queue 12 at 0x8c912b0) size : 1760
total size of above queues: 1799
value = 0 = 0x0
pdt>
Cause: unknown
Solution:
Run a software audit (LD 44, R 1)
Masses of AUD575s were output and all the locked-up Call Registers were then released
pdt> sl1qShow
SL1 queues of size > 0
128LowP (queue 3 at 0x8c911fc) size : 1
2Sec (queue 4 at 0x8c91210) size : 39
Dial (queue 6 at 0x8c91238) size : 3
RingAgain (queue 8 at 0x8c91260) size : 4
Idle (queue 12 at 0x8c912b0) size : 9669
RGAT (queue 18 at 0x8c91328) size : 2
total size of above queues: 9718
value = 0 = 0x0
pdt>
#################################################
Problem
CRMN001 HIGH Call Reg Usage, Pcnt Used= 99, Num Used= 34993, NumCR= 35000
Solution
pdt> sl1crShow
MAINPM NCR
------ ---
IDLE 11
READY 14
DIALING 11
BUSY 1
RINGING 65
ESTABLISHED 400
SPECIAL 1153
CDR 32463
ACD_PM 870
MUSIC_PM 10
Total CR Count = 34998
sl1qShow (sl1crShow) told us that it was the CDR data that was using the call registers. The system at the time had many more calls coming in than normal. Answer time was becoming really long.
All channels to Call Pilot were constantly busy playing messages and other call pilot'y things. Callers listened to ring tone for a long while BEFORE contact centre could find a Call Pilot agent to give first announcements.
Real agents were all busy with calls, sometimes for 2hrs. (Hence the backlog)
Speed to Call Logging ports set at 9600 (Very slow)
It is thought that a combination of the above, was causing the QREC (time to answer an ACD call) to output more than normal to the CDR TTY. The CDR TTY buffers were getting filled up and using all the call registers. Also, suspect the system has to use call registers to measure the time it was taking to answer calls.
First we removed QREC from the CDR data on the Route Data Blocks. This reduces the amount of data being sent to the CDR device. (Removing CDR from the route would probably have the same effect)
This allowed the CDR TTY's to try and catch up (The total number of CR being used dropped by approx 20 every 5 seconds)
System was left overnight, and in the morning there was nothing stuck in the CDR Queue.
Engineer was advised to speed up the CDR TTY to the max speed it will run (To allow the buffer to empty quicker)
He was then going to put QREC back on the route and monitor.
Hopefully by getting the CDR info out the system quicker will stop the Call Registers filling up.
At this time it is not known if this worked. (I will amend this record when I know, or if it works for you, then get record amended)
If removing QREC for a while does not allow the CR to go back to normal, then system may require an INI.
DO NOT REMOVE OR CHANGE ANY CDR TTY SETTINGS WHILE SYSTEM IS IN THIS STATE. OR DELIBERATLY DIS A TTY. THIS MAY RESULT IN THE SYSTEM HOLDING ONTO THE CDR DATA, AND NEVER BE ABLE TO OUTPUT IT. AND AN INI WILL BE REQUIRED TO CLEAR.
Firebird Scrambler
Nortel and Avaya Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Very advance high level knowledge on Linux BCM with keycode support
-
1
- #3
I found basically the same Solution
Cause
The baud rate on one QSDI port is configured as 1200 and the baud rate on QSDI port one is configured as 9600. The baud rate on TTY port for CDR is too slow to handle the CDR's traffic.
Solution
Increase the baud rate on both QSDI ports to 19200 for CDR interface.
Cause
The baud rate on one QSDI port is configured as 1200 and the baud rate on QSDI port one is configured as 9600. The baud rate on TTY port for CDR is too slow to handle the CDR's traffic.
Solution
Increase the baud rate on both QSDI ports to 19200 for CDR interface.
- Thread starter
- #4
Thanks guys. The call accounting system has been in and working for years and I have never had this issue. I did try and re-boot the CA server and buffer box just to try something and it did not have any affect. I think I will schedule an INI.
It is close enough it may end up doing it anyway.
On a CS1000M can I go up to 25000 CR's? I know this isn't the issue however. Looking in the NTP's it says max of 65000 but it also suggests a formula to determine that amount. The formula you need to be a algebra major to quantify it.
It is close enough it may end up doing it anyway.
On a CS1000M can I go up to 25000 CR's? I know this isn't the issue however. Looking in the NTP's it says max of 65000 but it also suggests a formula to determine that amount. The formula you need to be a algebra major to quantify it.
- Thread starter
- #6
No it did not. The only that has changed recently is the two network switches that connect most of the IP network ( Sig servers, Elan, System Manager, ect... ) were upgraded by the I.T. group. We have looked at those and cannot find any issues. I started getting complaints of calls not going through during peak time. After a lot of trouble shooting I found this and today happened to catch the insufficient bandwith ( QOS038 ) and then followed by the CRMN001 message come across the TTY. So I looked in PDT and saw the Print Q ( which is still climbing, 18077 now
- Thread starter
- #7
Firebird Scrambler
Systems Engineer
That's the fun of Nortel these days!. The main thing is that all is well now.
Firebird Scrambler
Nortel and Avaya Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Very advance high level knowledge on Linux BCM with keycode support
Firebird Scrambler
Nortel and Avaya Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Very advance high level knowledge on Linux BCM with keycode support
- Status
Similar threads
- Locked
- Question