CS performance problems .
Hello. I have a HW CS Common. Since I upgraded to R10.1 J2.501.21 am seeing performance issues on phones. Like Slow to update the display when the phone keypad frame . Takes few seconds to transfer the call to the speaker when I press the button , etc.
As relevant incident see :
5/11/13 9:15:06 000001M | 003/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
5/11/13 9:15:06 000001M | 004/03/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
5/11/13 9:15:06 000001M | 001/01/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
5/11/13 9:15:06 000001M | 001/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 8:51:52 000001M | 001/01/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 8:51:52 000001M | 003/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 8:51:52 000001M | 004/03/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 8:51:52 000001M | 001/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:02:52 000001M | 003/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:02:52 000001M | 004/03/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:02:52 000001M | 001/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:02:52 000001M | 001/01/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:17:02 000001M | 001/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:17:02 000001M | 001/01/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
6/11/13 9:17:03 000001M | 004/03/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
06/11/13 10:44:25 000001M | 001/01/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
11/07/13 10:43:00 000001M | 001/01/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
11/07/13 10:43:00 000001M | 003/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
11/07/13 10:43:00 000001M | 004/03/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
11/07/13 10:43:00 000001M | 001/00/-/--- | = 3:4401 = Ethernet broadcast reception disabled due to excessive traffic
And with the " top" I see that the CPU performance is good :
5:45pm up 13 days, 23:28, 2 users, load average: 11.16, 11.14, 11.09
275 processes: 273 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 11.3% user, 20.8% system, 0.0% nice, 67.8% idle
Mem: 255948K av, 244108K used, 11840K free, 0K shrd, 5520K buff
Swap: 1048784K av, 2452K used, 1046332K free 164920K cached
PID USER CLS PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
32059 mtcl UNIX 25 0 1156 1156 836 R.. 16.0 0.4 0:13 top
462 root UNIX 20 0 572 572 428 R.. 1.4 0.2 281:10 sysstatd
959 root FIFO 85 -12 32784 31M 32032 D.< 1.1 12.6 3:36 TEL
1063 root UNIX 36 -12 588 588 504 S.< 0.4 0.2 0:07 DPRd
962 root FIFO 85 -12 32784 31M 32032 D.< 0.1 12.6 7:11 TEL
1018 root FIFO 83 -12 1732 1732 1320 S.< 0.1 0.6 5:16 ipl_Ch2Ip
1019 root FIFO 83 -12 1732 1732 1320 S.< 0.1 0.6 14:23 ipl_Ip2Ch
1047 root FIFO 78 -12 4840 4840 4460 S.< 0.1 1.8 1:45 dis25
1332 mtcl UNIX 36 -12 2936 2936 1732 S.< 0.1 1.1 8:41 printing
1335 mtcl UNIX 36 -12 2936 2936 1732 S.< 0.1 1.1 0:49 routing
1358 mtcl UNIX 36 -12 1692 1692 1208 S.< 0.1 0.6 2:36 cstamono
1385 mtcl UNIX 36 -12 4812 4812 2980 S.< 0.1 1.8 12:54 main_afe
1388 mtcl UNIX 36 -12 4812 4812 2980 S.< 0.1 1.8 0:16 main_afe
1 root UNIX 30 0 460 460 388 S.. 0.0 0.1 0:33 init
2 root UNIX 31 0 0 0 0 SW. 0.0 0.0 0:00 keventd
3 root UNIX 30 0 0 0 0 SW. 0.0 0.0 0:00 events/0
4 root UNIX 20 19 0 0 0 SWN 0.0 0.0 0:06 ksoftirqd_CP
Do you have any idea? With a reboot could be solved this issue? This customer has a CCenter with 24hours working.
I´ve read about this issue in the forum, but i´m not sure if this is a CServer problem or LAN problem. The customer said me that he doesn´t change anything in LAN, and this issue was started when i upgrade the Pbx from R9.X to R10.X.
Same CS (With 256SDRAM), same wires, same connection.
Thanks in advanced.
Mario.
CS Performance Problems.
-
spynet
Re: CS Performance Problems.
First check, if the following can be your problem:
Have a look at - TC0543 - LIMITATIONS OF ETHERNET THRESHOLDS ON OmniPCX 4400/Enterprise CPUs BOARDS
Broadcast threshold -> GD -> 300
Then pay attention to:
OmniPCX Enterprise Release 10.x IP networks needs for VoIP Solutions
7.2.3.2. VLAN OXE Rule
Broadcasts can generate problems. The ones emitted by IP Phones concern only DHCP requests (IP Phone initialization) and ARP requests to communicate with another IP component (only if IP phone ARP table does not yet contain the information).
In order to limit broadcast issues, some engineering rules related to OXE and network infrastructure have to be followed:
1. Rules related to OXE:
The rule is to leave the handling of ARP requests to the network infrastructure equipments (Routers or Switches/Routers) and to not place IP Phones and CS into the same broadcasts domain (VLAN). This rule does not apply to IP MGW, i.e. for INTIP or GD/GA boards (all types):
• The CS must be located in a different VLAN to the IP Phones in order not to overload the CS with the handling of ARP requests.
Have a look at - TC0543 - LIMITATIONS OF ETHERNET THRESHOLDS ON OmniPCX 4400/Enterprise CPUs BOARDS
Broadcast threshold -> GD -> 300
Then pay attention to:
OmniPCX Enterprise Release 10.x IP networks needs for VoIP Solutions
7.2.3.2. VLAN OXE Rule
Broadcasts can generate problems. The ones emitted by IP Phones concern only DHCP requests (IP Phone initialization) and ARP requests to communicate with another IP component (only if IP phone ARP table does not yet contain the information).
In order to limit broadcast issues, some engineering rules related to OXE and network infrastructure have to be followed:
1. Rules related to OXE:
The rule is to leave the handling of ARP requests to the network infrastructure equipments (Routers or Switches/Routers) and to not place IP Phones and CS into the same broadcasts domain (VLAN). This rule does not apply to IP MGW, i.e. for INTIP or GD/GA boards (all types):
• The CS must be located in a different VLAN to the IP Phones in order not to overload the CS with the handling of ARP requests.
-
MMadrid
Re: CS Performance Problems.
Hi all.
The ethernet broadcast issue was disappeared but i´ve the same problem with the phones (only with UA phones).in external incoming calls, the speakerphone is activated first, last 3 seconds the audio is heard in the headset.
Any idea?
Regards.
The ethernet broadcast issue was disappeared but i´ve the same problem with the phones (only with UA phones).in external incoming calls, the speakerphone is activated first, last 3 seconds the audio is heard in the headset.
Any idea?
Regards.
-
MMadrid
Re: CS Performance Problems.
Thanks for you reply spynet. The issue only appear with UA Phones. By the way, i´ll try to restore another data base, or try to modify/delete the UA phones affected.
Thanks and greetings.
Thanks and greetings.
