Hi,

 

Any update on this issue?

 

Thanks

-vivek

 

From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Monday, May 14, 2012 11:10 AM
To: 'oprofile-list@lists.sourceforge.net'
Cc: Mattsson, Teemu (NSN - FI/Espoo); Venetjoki, Tero (NSN - FI/Espoo); Ryhanen, Sani (NSN - FI/Espoo)
Subject: RE: Need info on “oprofile” tool in mcRNC

 

Hi,

 

I am finding below error with the cmd. Can you plz check and let me know if command is correct?

 

 

ssh eipu-0

opcontrol --setup --vmlinux=/usr/lib/debug/boot/vmlinux-2.6.21.7-hrt1-NSN46-WR2.0NSN79.fp_octwnd_56xx_standard.debug

opcontrol --separate=kernel

opcontrol --start

top -b -n 1 > Eipu_opreport.txt

opreport >> Eipu_opreport.txt

opreport -l /opt/nokiasiemens/SS_ILCoSiting/bin/Irpoff >> Eipu_opreport.txt

# opreport -l /opt/nokiasiemens/SS_ILCoSiting/bin/Irpoff >> Eipu_opreport.txt

warning: /cavium_ethernet could not be found.

warning: /dmxmsg_core could not be found.

warning: /dmxmsg_devif could not be found.

warning: /dmxmsg_po could not be found.

warning: /fptun could not be found.

warning: /ipmi_serial could not be found.

warning: /rfpvi could not be found.

warning: /sunrpc could not be found.

warning: /vnb could not be found.

opreport error: profile_t::samples_range(): start > end something wrong with kernel or module layout ?

please report problem to oprofile-list@lists.sourceforge.net

 

 

thanks

-vivek

 

From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, May 10, 2012 12:41 PM
To: Gv, Vivek (NSN - IN/Bangalore); Ryhanen, Sani (NSN - FI/Espoo)
Cc: Mattsson, Teemu (NSN - FI/Espoo)
Subject: RE: Need info on “oprofile” tool in mcRNC

 

Hi

 

instead of:

 

#´opcontrol --separate=library

 

execute this:

 

#´opcontrol --separate=kernel

 

 

 

You can collect just the top-level info at first:

 

// printing out opreport

 

top -b -n 1 > uspu_opreport.txt
opreport >> uspu_opreport.txt

 

 

..and IRPOFF CPU usage information. Execute the below command with full filename of irpoff binary.

 

 

// Taking more info about most CPU using processes

 

opreport -l /opt/nokiasiemens/pac_rrc_qx_e1/bin/rrcprb >> uspu_opreport.txt

 

 

-Tero

 

 

 

From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, May 10, 2012 10:00 AM
To: Venetjoki, Tero (NSN - FI/Espoo); Ryhanen, Sani (NSN - FI/Espoo)
Cc: Mattsson, Teemu (NSN - FI/Espoo)
Subject: RE: Need info on “oprofile” tool in mcRNC

 

Hi Tero,

 

I guess, below commands are USPU, need to monitor PRBs in EIPU. Can you plz let me know the PRBs that you are interested in ?

 

 

>>I would suggest using --separate=kernel below because that will also show CPU time used in kernel in addition to "normal" libraries.

Can you plz edit this in below. I am not able to understand this

 

Thanks

-Vivek

 

 

From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Friday, May 04, 2012 5:01 PM
To: Ryhanen, Sani (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore)
Subject: RE: Need info on “oprofile” tool in mcRNC

 

Hi

 

I would suggest using --separate=kernel below because that will also show CPU time used in kernel in addition to "normal" libraries.

 

-Tero

 

 

 

// use separate libraries

 

#´opcontrol --separate=library

 

 

From: Ryhanen, Sani (NSN - FI/Espoo)
Sent: Friday, May 04, 2012 2:29 PM
To: Gv, Vivek (NSN - IN/Bangalore)
Cc: Venetjoki, Tero (NSN - FI/Espoo)
Subject: RE: Need info on “oprofile” tool in mcRNC

 

Hi Vivek,

 

something like this:

 

// Connect to mcRNC and there to USPU-0 and get running kernel

 

ssh uspu-0

 

// check what is the running kernel

 

# uname -a
Linux USPU-0 2.6.21.7-hrt1-
NSN45-WR2.0NSN84.fp_octeon_56xx_standard #1 SMP PREEMPT Wed Mar 28 19:40:34 EEST 2012 mips64 mips64 mips64 GNU/Linux
[root@USPU-0(RNC-15) /root]

# ll /usr/lib/debug/boot/
total 134920
-rwxr-xr-x 1 root root 43348053 Mar 28 19:55 vmlinux-2.6.21.7-hrt1-NSN26-WR2.0NSN84.fp_octeon_56xx_filb_standard.debug
-rwxr-xr-x 1 root root 44655958 Mar 28 19:41
vmlinux-2.6.21.7-hrt1-NSN45-WR2.0NSN84.fp_octeon_56xx_standard.debug
-rwxr-xr-x 1 root root 49992902 Mar 28 19:28 vmlinux-2.6.21.7-hrt1-NSN50-WR2.0NSN84.fp_octeon_5650_standard.debug
[root@USPU-0(RNC-15) /root]
#


b.) setup the oprofiling environment
opcontrol --setup --vmlinux=/usr/lib/debug/boot/
vmlinux-2.6.21.7-hrt1-NSN45-WR2.0NSN84.fp_octeon_56xx_standard.debug

// start the oprofiling environment, take top before starting to see what families are the most cpu consuming

 

# top
top - 14:22:49 up  2:43,  3 users,  load average: 1.76, 1.62, 1.58
Tasks: 150 total,   2 running, 148 sleeping,   0 stopped,   0 zombie
Cpu(s): 22.7%us,  5.5%sy,  0.0%ni, 70.9%id,  0.0%wa,  0.9%hi,  0.1%si,  0.0%st
Mem:   4134128k total,  3792252k used,   341876k free,        0k buffers
Swap:        0k total,        0k used,        0k free,   692444k cached

 

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
29844 root      25   0 27352  24m 1176 R   99  0.6   0:43.93 objdump
 5525 root      25   0  3352 1684 1224 S    4  0.0   4:34.53 dmxmsg_info_col
32185 root      15   0  6756 2784 1928 R    1  0.1   0:00.08 top
    8 root      RT   0     0    0    0 S    0  0.0   0:00.43 migration/2
 6413 root      22   0  178m  10m 4252 S    0  0.3  13:11.99 lrmprb
 7000 root      16   0 1272m 1.0g  11m S    0 26.1  11:02.51 rrcprb

 

// use separate libraries

 

#´opcontrol --separate=library

// start oprofiling

 

tx("opcontrol --start");

 

// Wait for 2 minutes before taking oprofile data out

 

// printing out opreport

 

top -b -n 1 > uspu_opreport.txt
opreport >> uspu_opreport.txt

 

// Taking more info about most CPU using processes

 

opreport -l /opt/nokiasiemens/pac_rrc_qx_e1/bin/rrcprb >> uspu_opreport.txt

 

// If you trying to get reports for a kernel module, make sure to use the -p option, and specify the module name with the .ko extension.

 

opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_rrc_qx_e1/bin/rrcprb >> uspu_opreport.txt

opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_QNL2MTOR/bin/l2mtor >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_ILCallMgmt/bin/lrmprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_QNRMDPRB/bin/rmdprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_uerprb_e1/bin/uerprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_nrr_qx_e1/bin/nrrprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_nrm_qx_e1/bin/nrmprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_ccm_qx_e1/bin/l3ccmp >> uspu_opreport.txt

opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_ILCallMgmt/bin/lemana >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_ha3_qd_e1/bin/ha3prb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_ILCallMgmt/bin/rm2prb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_iuv_qx_e1/bin/iuvprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_ILCallMgmt/bin/rfrprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_rc3_qx_e1/bin/rc3prb >> uspu_opreport.txt

opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/pac_tiiprb_e1/bin/tiiprb >> uspu_opreport.txt
opreport -p /lib/modules/`uname -r` /drivers/net/dmxmsg/ --merge all -l dmxmsg_ /opt/nokiasiemens/SS_ILSigss7/bin/sorpro >> uspu_opreport.txt

 

// Taking assembly logs from each binary

 

opcontrol --image=/opt/nokiasiemens/pac_rrc_qx_e1/bin/rrcprb
opannotate --source --assembly /opt/nokiasiemens/pac_rrc_qx_e1/bin/rrcprb >> rrc_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/SS_QNL2MTOR/bin/l2mtor
opannotate --source --assembly /opt/nokiasiemens/SS_QNL2MTOR/bin/l2mtor >> l2mtor_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/SS_ILCallMgmt/bin/lrmprb
opannotate --source --assembly /opt/nokiasiemens/SS_ILCallMgmt/bin/lrmprb >> lrm_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/SS_QNRMDPRB/bin/rmdprb
opannotate --source --assembly /opt/nokiasiemens/SS_QNRMDPRB/bin/rmdprb >> rmd_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/pac_uerprb_e1/bin/uerprb
opannotate --source --assembly /opt/nokiasiemens/pac_uerprb_e1/bin/uerprb >> uer_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/pac_nrr_qx_e1/bin/nrrprb
opannotate --source --assembly /opt/nokiasiemens/pac_nrr_qx_e1/bin/nrrprb >> nrr_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/pac_nrm_qx_e1/bin/nrmprb
opannotate --source --assembly /opt/nokiasiemens/pac_nrm_qx_e1/bin/nrmprb >> nrm_assembly_log.txt
opcontrol --image=/opt/nokiasiemens/pac_ccm_qx_e1/bin/l3ccmp
opannotate --source --assembly /opt/nokiasiemens/pac_ccm_qx_e1/bin/l3ccmp >> l3ccmp_assembly_log.txt

 

// stop oprofiling

 

opcontrol --shutdown

 

Br, Sani

 


From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Friday, May 04, 2012 7:39 AM
To: Ryhanen, Sani (NSN - FI/Espoo)
Cc: Venetjoki, Tero (NSN - FI/Espoo)
Subject: Need info on “oprofile” tool in mcRNC

Hi Sani,

 

I have come to know that you have been using “oprofile” tool

Can you please provide cmd for “oprofile” tool and where it is located?

 

Thanks

-Vivek

 

From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, May 03, 2012 7:07 PM
To: Gv, Vivek (NSN - IN/Bangalore); 'ext Nishu Aggarwal'; Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore); 'Ankur Gargi'; 'Vineeta Batra'
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

 

Hi

 

oprofile is a tool included in Flexiplatform that tells which binaries and functions use most CPU time.

 

You can ask more info about its usage from PET testing area, contact e.g. Sani Ryhanen or Juhana Sillanpää.

There are probably some scripts/macros that can be used to activate profiling and to extract data.

 

-Tero

 

 

 

From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, May 03, 2012 2:09 PM
To: ext Nishu Aggarwal; Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore); Ankur Gargi; Vineeta Batra
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

 

Hi Nishu,Tero,

 

Result is much better with this IT. we are able to establish double number of calls (650), early we face this problem at around 370 calls.

 

>> Can you collect oprofile data for irpoff to see where the time goes?

 

What is “oprofile”? plz let us know how to collect this data?

 

 

Thanks

-Vivek

 

From: ext Nishu Aggarwal [mailto:Nishu.Aggarwal@aricent.com]
Sent: Thursday, May 03, 2012 3:52 PM
To: Gv, Vivek (NSN - IN/Bangalore); Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore); Ankur Gargi; Vineeta Batra
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

 

Hi,

 

Please find NBAP test image attached where we have removed the  sctp_data_ind_s ( containing dedicated meas report ) message sending to HA3.

 

NBA_QXQX.PAC 15.5-1 T1 12/04/24 RNXENVQX.PAC 12.13-0

 

Thanks and Regards

Nishu

 

From: Gv, Vivek (NSN - IN/Bangalore) [mailto:vivek.gv@nsn.com]
Sent: Thursday, May 03, 2012 2:41 PM
To: Nishu Aggarwal; Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore); Ankur Gargi; Vineeta Batra
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

 

mcRNC Build : R_QNCB.12.13.0_4.WR.mips.bv

cRNC Build: QX121300_cor2

 

Thanks

-vivek

 

 

From: ext Nishu Aggarwal [mailto:Nishu.Aggarwal@aricent.com]
Sent: Thursday, May 03, 2012 2:24 PM
To: Gv, Vivek (NSN - IN/Bangalore); Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore); Ankur Gargi; Vineeta Batra
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

 

Hi,

 

Please let me know the exact build on which the test image is needed !

 

Thanks and Regards

Nishu

 

From: Gv, Vivek (NSN - IN/Bangalore) [mailto:vivek.gv@nsn.com]
Sent: Thursday, May 03, 2012 1:16 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo); Nishu Aggarwal
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

 

Hi Tero,

>> I think this RNC-cl load reporting is not the solution to your current problem. Especially if you are doing testing so that all calls are forced to mcRNC via test message.

This was done as testrun, so that we will focus only on issues related to “RNC-ci” interface. Our stability case we will not force calls into mcRNC.

Nishu@

Can you plz provide TI with required changes, mentioned by Tero?

Thanks

-Vivek

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, May 03, 2012 1:01 PM
To: Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

I think this RNC-cl load reporting is not the solution to your current problem. Especially if you are doing testing so that all calls are forced to mcRNC via test message.

If you now have one ICSU and one USPU and one SCTP association for inter-RNC messaging and the messaging gets limited by IRPOFF processing capacity in EIPU, then that's not good. It means that EIPU CPU capacity will be the bottleneck, unless the number of EIPUs is bigger than number of USPUs, which is not generally possible.

Also, based on ICSU monitoring, there were already almost 1 second round-trip delays even though inter-RNC messaging rate was less than 1 Mbit/s.

Some real optimizations seem to be necessary to reduce the CPU cost of inter-RNC messaging in EIPU. Can you collect oprofile data for irpoff to see where the time goes? And also the NBAPRB change to eliminate unnecessary sctp_data_ind_s messages from CRNC to mcRNC should be done.

-Tero

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, May 03, 2012 10:14 AM
To: Ilonen, Sami (NSN - FI/Espoo); Venetjoki, Tero (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou); Kumar, Ajay B. (NSN - IN/Bangalore)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Teemu,

This (RNC-cl load reporting) is critical for stability testing. Without this we will observe lot of call drop/failure. 

Can you plz let us know when this will be implemented?

Thanks

-Vivek

_____________________________________________
From: Ilonen, Sami (NSN - FI/Espoo)
Sent: Wednesday, May 02, 2012 3:37 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Li, Leilei (NSN - CN/Hangzhou); Mattsson, Teemu (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

RNC-cl load reporting is being implemented in this sprint by Teemu Matsson to RC3PRB.

Regards,

        -Sami

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Wednesday, May 02, 2012 12:50 PM
To: Gv, Vivek (NSN - IN/Bangalore); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

if platform SW reports that inter-cluster connect is overloaded or congested, then RRBPRB would start reducing the percentage of calls assigned to mcRNC.

But in this case the inter-connection load was reported as normal (ie. the 'load_level' field in rc3_unit_load_ind_s coming from RC3 was always 0 = cl_load_level_t_normal_c). I don't know if that part load reporting is fully implemented yet, though.

-Tero

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Wednesday, May 02, 2012 12:21 PM
To: Gv, Vivek (NSN - IN/Bangalore); Venetjoki, Tero (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Tero,

Calls should have got established on cRNC rather than getting rejected because of RNC-CI msg delay. May be it is acceptable under this situation because calls re forced on to mcRNC. But in normal situation does RRB prb consider RNC-CI msg delay before re-directing calls on mcRNC under normal condition?

Thanks

-Vivek

 

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Wednesday, May 02, 2012 2:25 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Yonq,

We have only one working ICSU. Can we add two SCTP association on this?

Thanks

-Vivek

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Wednesday, May 02, 2012 1:52 PM
To: Han, Yong (NSN - CN/Hangzhou); Gv, Vivek (NSN - IN/Bangalore); Wu, Yongkang (NSN - CN/Hangzhou); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

if the below POH results were achieved with a message test that uses 200/100 window, ie. max. 200 messages in flight and messages are sent 100 messages at a time, it may give too optimistic results compared to what can be achieved with application message traffic.

Application SW does not usually generate that big message bursts, so I would like to see results also from test which sends stream of individual messages (replace "200/100" with e.g. "40".)

Also, the payload part of application messages gets converted from mcRNC format to CRNC format and back, which causes extra CPU load in mcRNC compared to the POHEXT test message which does not have conversion function so only message header needs to be converted.

-Tero

_____________________________________________
From: Han, Yong (NSN - CN/Hangzhou)
Sent: Wednesday, May 02, 2012 11:03 AM
To: Gv, Vivek (NSN - IN/Bangalore); Wu, Yongkang (NSN - CN/Hangzhou); Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Sorry for late due to Labor Holiday.

From output of POH, RNC-cl message throughput is reasonable from platform view.

Test stopped. Sent 100000 and received 100000 messages.

Elapsed time = 9.63 seconds

Average message arrival rate = 10384 msg/s

Average incoming data rate = 11.879 Mbit/s

Round trip times: min=778.7, max=27796.5, avg=14169.1 microseconds

So next, who can help to calculate RNC-cl message load each second according to call setup procedure? If it reaches the below result, Vivek, you have to add one more SCTP association on another working ICSU@IPA-RNC and EIPU@mcRNC.

 << OLE Object: Picture (Device Independent Bitmap) >>

 

Best Regards,

Han Yong

+86 13868139207 (669207)

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Friday, April 27, 2012 6:56 PM
To: Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Yonq,

I have already shared output below.

Thanks

-Vivek

_____________________________________________
From: Han, Yong (NSN - CN/Hangzhou)
Sent: Friday, April 27, 2012 3:07 PM
To: Gv, Vivek (NSN - IN/Bangalore); Wu, Yongkang (NSN - CN/Hangzhou); Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Did you run the POH command with call ongoing or not?

Best Regards,

Han Yong

+86 13868139207 (669207)

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Friday, April 27, 2012 12:34 PM
To: Han, Yong (NSN - CN/Hangzhou); Wu, Yongkang (NSN - CN/Hangzhou); Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Han/Yonqkanq,

Below are the test-step.

1)      Configured 800 R99 calls which perform the state-transfer on PeT tester (simulator)

2)      Start calls on the PeT tester, with intra delay of 375 ms between each call.

3)      We can find call drop due to “RRC connect reject” and other errors on the pet-tester when around 370~ 400 calls are started on mcRNC.

4)      Pet tester keeps on trying to re-establish the call and finally we are able to achieve around 700 calls on mcRNC

So please consider 400 calls for calculation not 700 calls because error start from around 370~400 calls.

Below is the cmd output.

MAIN LEVEL COMMAND <___>

< ZDDS:ICSU;

 

LOADING PROGRAM VERSION 7.66-0

WELCOME TO SERVICE TERMINAL DIALOGUE

000C-MAN>ZLP:P,POH

/*** COMMAND CHARACTER ALREADY IN USE

000C-MAN>ZPFS:0,1,4FD

Test msg id=0000, group=0000, attrs=01, target fam=04FD, target proc=0000

 RNG seed=<clock>, message<-->blockdata gap=FFFFFFFF

Measured CPU clock frequency: 1597 MHz

000C-POH>ZPFVRO:119,,200/100,:5E03:100000

SENDING MESSAGES: LENGTH=119; ACK_TIMEOUT=200, WINDOW=200, BURST SIZE=100

TEST MESSAGE NUMBER=0000  RECEIVER FAMILY=04FD

   10 messages sent. (09:51:35.50)

   20 messages sent. (09:51:35.50)

   30 messages sent. (09:51:35.51)

   40 messages sent. (09:51:35.51)

   50 messages sent. (09:51:35.51)

   60 messages sent. (09:51:35.51)

   70 messages sent. (09:51:35.51)

   80 messages sent. (09:51:35.51)

   90 messages sent. (09:51:35.51)

  100 messages sent. (09:51:35.51)

(09:51:35.50) 000C ICSU-0   receiving (WO-EX; ack=1/64)

  200 messages sent. (09:51:35.52)

  300 messages sent. (09:51:35.53)

  400 messages sent. (09:51:35.54)

  500 messages sent. (09:51:35.55)

  600 messages sent. (09:51:35.56)

  700 messages sent. (09:51:35.57)

  800 messages sent. (09:51:35.58)

  900 messages sent. (09:51:35.59)

 1000 messages sent. (09:51:35.60)

 1500 messages sent. (09:51:35.65)   Rtrip min/max/avg=8804/ 17602/13416 us

 2000 messages sent. (09:51:35.69)   Rtrip min/max/avg=8794/ 22960/15313 us

 2500 messages sent. (09:51:35.74)   Rtrip min/max/avg=8891/ 16585/12715 us

 3000 messages sent. (09:51:35.79)   Rtrip min/max/avg=9142/ 22477/16735 us

 3500 messages sent. (09:51:35.83)   Rtrip min/max/avg=8736/ 17406/12926 us

 4000 messages sent. (09:51:35.89)   Rtrip min/max/avg=10884/ 23403/15899 us

 4500 messages sent. (09:51:35.93)   Rtrip min/max/avg=8756/ 16201/12467 us

 5000 messages sent. (09:51:35.98)   Rtrip min/max/avg=8917/ 23006/15047 us

 5500 messages sent. (09:51:36.03)   Rtrip min/max/avg=8784/ 16865/12766 us

 6000 messages sent. (09:51:36.08)   Rtrip min/max/avg=9969/ 19127/13839 us

 6500 messages sent. (09:51:36.13)   Rtrip min/max/avg=9100/ 17910/13696 us

 7000 messages sent. (09:51:36.18)   Rtrip min/max/avg=9205/ 17098/13012 us

 7500 messages sent. (09:51:36.22)   Rtrip min/max/avg=9207/ 17061/13481 us

 8000 messages sent. (09:51:36.27)   Rtrip min/max/avg=8870/ 16921/12792 us

 8500 messages sent. (09:51:36.31)   Rtrip min/max/avg=8412/ 16708/12897 us

 9000 messages sent. (09:51:36.36)   Rtrip min/max/avg=8838/ 18670/13567 us

 9500 messages sent. (09:51:36.41)   Rtrip min/max/avg=8830/ 22508/13998 us

10000 messages sent. (09:51:36.45)   Rtrip min/max/avg=8848/ 17017/13034 us

11000 messages sent. (09:51:36.55)   Rtrip min/max/avg=8855/ 23379/14333 us

12000 messages sent. (09:51:36.64)   Rtrip min/max/avg=8575/ 23314/14605 us

13000 messages sent. (09:51:36.74)   Rtrip min/max/avg=8884/ 23773/14670 us

14000 messages sent. (09:51:36.84)   Rtrip min/max/avg=8998/ 21127/14085 us

15000 messages sent. (09:51:36.93)   Rtrip min/max/avg=8896/ 24046/14470 us

16000 messages sent. (09:51:37.03)   Rtrip min/max/avg=8855/ 21629/14504 us

17000 messages sent. (09:51:37.12)   Rtrip min/max/avg=8708/ 22960/13970 us

18000 messages sent. (09:51:37.22)   Rtrip min/max/avg=8882/ 25051/14902 us

19000 messages sent. (09:51:37.32)   Rtrip min/max/avg=8784/ 23085/14911 us

20000 messages sent. (09:51:37.42)   Rtrip min/max/avg=7891/ 22953/14129 us

21000 messages sent. (09:51:37.52)   Rtrip min/max/avg=8753/ 22536/14462 us

22000 messages sent. (09:51:37.62)   Rtrip min/max/avg=9010/ 23017/15133 us

23000 messages sent. (09:51:37.73)   Rtrip min/max/avg=8600/ 23527/15577 us

24000 messages sent. (09:51:37.83)   Rtrip min/max/avg=8853/ 21232/15204 us

25000 messages sent. (09:51:37.93)   Rtrip min/max/avg=8819/ 24364/14457 us

26000 messages sent. (09:51:38.02)   Rtrip min/max/avg=8798/ 22067/13757 us

27000 messages sent. (09:51:38.11)   Rtrip min/max/avg=8818/ 23952/14088 us

28000 messages sent. (09:51:38.21)   Rtrip min/max/avg=8866/ 22453/14166 us

29000 messages sent. (09:51:38.30)   Rtrip min/max/avg=8644/ 20973/14926 us

30000 messages sent. (09:51:38.40)   Rtrip min/max/avg=8940/ 23040/14502 us

31000 messages sent. (09:51:38.50)   Rtrip min/max/avg=8810/ 20382/14328 us

32000 messages sent. (09:51:38.59)   Rtrip min/max/avg=9090/ 22141/14343 us

33000 messages sent. (09:51:38.69)   Rtrip min/max/avg=9119/ 21197/14787 us

34000 messages sent. (09:51:38.78)   Rtrip min/max/avg=8802/ 21702/14065 us

35000 messages sent. (09:51:38.88)   Rtrip min/max/avg=8355/ 17838/13218 us

36000 messages sent. (09:51:38.97)   Rtrip min/max/avg=8950/ 18617/13425 us

37000 messages sent. (09:51:39.07)   Rtrip min/max/avg=8693/ 19626/13945 us

38000 messages sent. (09:51:39.16)   Rtrip min/max/avg=8817/ 17877/13460 us

39000 messages sent. (09:51:39.26)   Rtrip min/max/avg=8499/ 18720/13358 us

40000 messages sent. (09:51:39.35)   Rtrip min/max/avg=9114/ 22120/13465 us

41000 messages sent. (09:51:39.45)   Rtrip min/max/avg=8847/ 22898/14003 us

42000 messages sent. (09:51:39.54)   Rtrip min/max/avg=8750/ 22084/13929 us

43000 messages sent. (09:51:39.63)   Rtrip min/max/avg=8897/ 22945/14349 us

44000 messages sent. (09:51:39.73)   Rtrip min/max/avg=9231/ 23233/14250 us

45000 messages sent. (09:51:39.83)   Rtrip min/max/avg=9388/ 21562/14784 us

46000 messages sent. (09:51:39.92)   Rtrip min/max/avg=8835/ 22857/14161 us

47000 messages sent. (09:51:40.02)   Rtrip min/max/avg=8880/ 22451/14531 us

48000 messages sent. (09:51:40.11)   Rtrip min/max/avg=8887/ 24736/14682 us

49000 messages sent. (09:51:40.21)   Rtrip min/max/avg=8973/ 22868/14370 us

50000 messages sent. (09:51:40.30)   Rtrip min/max/avg=8828/ 23096/14073 us

51000 messages sent. (09:51:40.39)   Rtrip min/max/avg=8804/ 22364/13776 us

52000 messages sent. (09:51:40.49)   Rtrip min/max/avg=8905/ 23447/13884 us

53000 messages sent. (09:51:40.58)   Rtrip min/max/avg=8775/ 22497/13576 us

54000 messages sent. (09:51:40.68)   Rtrip min/max/avg=9039/ 18240/13376 us

55000 messages sent. (09:51:40.77)   Rtrip min/max/avg=8791/ 19271/13527 us

56000 messages sent. (09:51:40.86)   Rtrip min/max/avg=8524/ 17881/13209 us

57000 messages sent. (09:51:40.95)   Rtrip min/max/avg=8878/ 22935/13767 us

58000 messages sent. (09:51:41.05)   Rtrip min/max/avg=8850/ 22571/13897 us

59000 messages sent. (09:51:41.15)   Rtrip min/max/avg=9099/ 23707/15330 us

60000 messages sent. (09:51:41.24)   Rtrip min/max/avg=9268/ 20780/13881 us

61000 messages sent. (09:51:41.33)   Rtrip min/max/avg=8869/ 22898/14430 us

62000 messages sent. (09:51:41.43)   Rtrip min/max/avg=8864/ 22540/14131 us

63000 messages sent. (09:51:41.52)   Rtrip min/max/avg=8810/ 22811/13782 us

64000 messages sent. (09:51:41.62)   Rtrip min/max/avg=9848/ 20473/14524 us

65000 messages sent. (09:51:41.72)   Rtrip min/max/avg=8256/ 23385/14686 us

66000 messages sent. (09:51:41.82)   Rtrip min/max/avg=6889/ 22530/14847 us

67000 messages sent. (09:51:41.92)   Rtrip min/max/avg=8813/ 26316/14952 us

68000 messages sent. (09:51:42.02)   Rtrip min/max/avg=8759/ 22955/14387 us

69000 messages sent. (09:51:42.12)   Rtrip min/max/avg=8886/ 24929/14534 us

70000 messages sent. (09:51:42.21)   Rtrip min/max/avg=8434/ 21681/14139 us

71000 messages sent. (09:51:42.31)   Rtrip min/max/avg=8897/ 23329/14008 us

72000 messages sent. (09:51:42.40)   Rtrip min/max/avg=8731/ 22557/14225 us

73000 messages sent. (09:51:42.49)   Rtrip min/max/avg=8818/ 22841/13930 us

74000 messages sent. (09:51:42.59)   Rtrip min/max/avg=9232/ 20599/14351 us

75000 messages sent. (09:51:42.68)   Rtrip min/max/avg=9121/ 23303/13909 us

76000 messages sent. (09:51:42.78)   Rtrip min/max/avg=8810/ 22712/14724 us

77000 messages sent. (09:51:42.88)   Rtrip min/max/avg=8628/ 18595/13552 us

(09:51:45.02) 000C ICSU-0   TIMEOUT #1 (WO-EX; prev ack=12E84)

              (last message sent 09:51:43.02)

(09:51:45.02) 000C ICSU-0   receiving again (WO-EX; ack=12F21/12F84)

                            (156 MESSAGES WERE LOST)

78000 messages sent. (09:51:45.05)   Rtrip min/max/avg=7576/115089/37549 us

79000 messages sent. (09:51:45.14)   Rtrip min/max/avg=8888/ 21537/13955 us

80000 messages sent. (09:51:45.24)   Rtrip min/max/avg=8842/ 22501/14028 us

81000 messages sent. (09:51:45.33)   Rtrip min/max/avg=9096/ 22686/14253 us

82000 messages sent. (09:51:45.43)   Rtrip min/max/avg=8919/ 22454/14156 us

83000 messages sent. (09:51:45.53)   Rtrip min/max/avg=8992/ 22570/14912 us

84000 messages sent. (09:51:45.62)   Rtrip min/max/avg=9061/ 22859/14043 us

85000 messages sent. (09:51:45.71)   Rtrip min/max/avg=8995/ 23669/14676 us

86000 messages sent. (09:51:45.81)   Rtrip min/max/avg=9149/ 22482/14291 us

87000 messages sent. (09:51:45.90)   Rtrip min/max/avg=8901/ 21949/13858 us

88000 messages sent. (09:51:46.00)   Rtrip min/max/avg=8865/ 23119/14685 us

89000 messages sent. (09:51:46.10)   Rtrip min/max/avg=8849/ 25066/14318 us

90000 messages sent. (09:51:46.19)   Rtrip min/max/avg=9108/ 22246/14359 us

91000 messages sent. (09:51:46.29)   Rtrip min/max/avg=8834/ 21167/13824 us

92000 messages sent. (09:51:46.38)   Rtrip min/max/avg=8755/ 22261/14102 us

93000 messages sent. (09:51:46.48)   Rtrip min/max/avg=8801/ 17173/12875 us

94000 messages sent. (09:51:46.57)   Rtrip min/max/avg=8821/ 17814/13175 us

95000 messages sent. (09:51:46.66)   Rtrip min/max/avg=8968/ 17492/13060 us

96000 messages sent. (09:51:46.76)   Rtrip min/max/avg=8772/ 22559/13399 us

97000 messages sent. (09:51:46.85)   Rtrip min/max/avg=8891/ 22040/13539 us

98000 messages sent. (09:51:46.94)   Rtrip min/max/avg=8792/ 22235/14231 us

99000 messages sent. (09:51:47.04)   Rtrip min/max/avg=9082/ 23701/14159 us

100000 messages sent. (09:51:47.13)   Rtrip min/max/avg=8860/ 23414/13657 us

Test stopped. Sent 100000 and received 99844 messages.

1 timeouts occurred for 1 different target computers.

1 occurrences of message(s) getting lost.

Elapsed time = 11.64 seconds

Average message arrival rate = 8577 msg/s

Assumed outgoing data rate =  9.828 Mbit/s

Average incoming data rate =  9.812 Mbit/s

Round trip times: min=5182.3, max=115089.4, avg=14349.5 microseconds

000C-POH>

            

Thanks

-Vivek

_____________________________________________
From: Han, Yong (NSN - CN/Hangzhou)
Sent: Friday, April 27, 2012 8:38 AM
To: Wu, Yongkang (NSN - CN/Hangzhou); Venetjoki, Tero (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

RNC-cl DMX message throughput from pov of platform (X=DMX message length, Y=throughput per SCTP link)

 << OLE Object: Picture (Device Independent Bitmap) >>

For delay testing, RTT must be measured, that can be working by add “R = measure round trip times”.

One example on my testbed without any call ongoing, please compare to see if any other issue existed.

If the result shows it is same, as Yongkang mentioned, we should estimate the total message according to 700 R99 call prolife, to see if already reach the current high-point.

ZLP:P,POH

ZPFS:0,1,4FD

ZPFVRO:119,,200/100,:5E03:100000

Test stopped. Sent 100000 and received 100000 messages.

Elapsed time = 10.07 seconds

Average message arrival rate = 9930 msg/s

Average incoming data rate = 11.360 Mbit/s

Round trip times: min=2546.5, max=24659.7, avg=14356.5 microseconds

Best Regards,

Han Yong

+86 13868139207 (669207)

_____________________________________________
From: Wu, Yongkang (NSN - CN/Hangzhou)
Sent: Friday, April 27, 2012 10:20 AM
To: Venetjoki, Tero (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Li, Leilei (NSN - CN/Hangzhou); Han, Yong (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Involve also Li Leilei and Han Yong.

It is a problem related with inter-RNC DMX message throughput and delay.

From the configuration sent from Vivek to me days ago,  there is only one SCTP association used.

ZOYA:INCLI:ICSU,0:COSITING:;

ZOYN:ICSU,0:IPV4:"10.10.17.10";

ZOYP:M3UA:INCLI,0:"10.10.17.10",,49225:"10.10.17.6",24,,,2905:;

Then, with average 284 bytes DMX message, the max DMX message throughput is 12.67 Mbps based on Han Yong’s test report, while RNC-cl throughput is 18 Mbps.

It seems now about 700 R99 calls with Vivek’s call profile has hit this line.

Vivek, please also share your tester setup for the call profile after the throughput test suggested by Tero.

Han Yong, please also check the used POH command with Tero proposed ones.

BRs,
WU YK

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 10:42 PM
To: Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

can you do the throughput test once more in situation where there aren't any ongoing calls?

-Tero

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, April 26, 2012 5:42 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Below is the output of the cmd.

Logs are at below path

Use NSN-intra login/passwd

 

10.135.55.8

/FS000005080/NSN/UIT-5/vivek/cositing4/

000C-POH>ZPFOR:,,,10:7E03

SENDING MESSAGES: LENGTH=24; ACK_TIMEOUT=200, WINDOW=1

TEST MESSAGE NUMBER=0000  RECEIVER FAMILY=04FD

(19:44:04.90) 000C ICSU-0   receiving (WO-EX; ack=1/1)

   10 messages sent. (19:44:05.80)   Rtrip min/max/avg= 816/  2816/ 1163 us

   20 messages sent. (19:44:06.80)   Rtrip min/max/avg= 736/   995/  859 us

   30 messages sent. (19:44:07.80)   Rtrip min/max/avg= 820/  1220/  951 us

   40 messages sent. (19:44:08.80)   Rtrip min/max/avg= 825/  1270/  997 us

   50 messages sent. (19:44:09.80)   Rtrip min/max/avg= 774/  1274/ 1044 us

   60 messages sent. (19:44:10.80)   Rtrip min/max/avg= 812/  1067/  902 us

   70 messages sent. (19:44:11.80)   Rtrip min/max/avg= 796/  1082/  949 us

   80 messages sent. (19:44:12.80)   Rtrip min/max/avg= 791/  1049/  891 us

   90 messages sent. (19:44:13.80)   Rtrip min/max/avg= 668/   996/  897 us

  100 messages sent. (19:44:14.80)   Rtrip min/max/avg= 826/  1264/  968 us

  200 messages sent. (19:44:24.80)   Rtrip min/max/avg= 669/  1435/  943 us

  300 messages sent. (19:44:34.80)   Rtrip min/max/avg= 627/  2194/  941 us

  400 messages sent. (19:44:44.80)   Rtrip min/max/avg= 622/  2434/  908 us

  500 messages sent. (19:44:54.80)   Rtrip min/max/avg= 609/  2154/  894 us

  600 messages sent. (19:45:04.82)   Rtrip min/max/avg= 614/  6965/ 1202 us

  700 messages sent. (19:45:14.83)   Rtrip min/max/avg= 610/ 14040/ 1388 us

  800 messages sent. (19:45:24.85)   Rtrip min/max/avg= 616/ 15665/ 1530 us

  900 messages sent. (19:45:34.94)   Rtrip min/max/avg= 610/ 26046/ 2547 us

 1000 messages sent. (19:45:45.11)   Rtrip min/max/avg= 627/ 37318/ 3110 us

 1100 messages sent. (19:45:55.31)   Rtrip min/max/avg= 647/ 41198/ 3530 us

 1200 messages sent. (19:46:05.70)   Rtrip min/max/avg= 624/ 65693/ 6009 us

 1300 messages sent. (19:46:16.29)   Rtrip min/max/avg= 613/ 81021/ 8166 us

 1400 messages sent. (19:46:27.16)   Rtrip min/max/avg= 664/107077/11422 us

 1500 messages sent. (19:46:39.05)   Rtrip min/max/avg= 642/149735/21854 us

 1600 messages sent. (19:46:51.75)   Rtrip min/max/avg= 779/171252/30380 us

 1700 messages sent. (19:47:05.50)   Rtrip min/max/avg= 707/219445/40962 us

 1800 messages sent. (19:47:33.54)   Rtrip min/max/avg=1233/941858/185063 us --> saw error on tester at this point of time (around 400 calls were there at this point of time)

(19:47:48.74) 000C ICSU-0   TIMEOUT #1 (WO-EX; prev ack=712)

              (last message sent 19:47:46.74)

(19:47:52.16) 000C ICSU-0   receiving again (WO-EX; ack=715/715)

                            (2 MESSAGES WERE LOST)

(19:48:03.79) 000C ICSU-0   TIMEOUT #2 (WO-EX; prev ack=71C)

              (last message sent 19:48:01.79)

(19:48:05.11) 000C ICSU-0   receiving again (WO-EX; ack=71E/71E)

                            (1 MESSAGE WAS LOST)

Test stopped. Sent 1828 and received 1824 messages.

2 timeouts occurred for 1 different target computers.

2 occurrences of message(s) getting lost.

Elapsed time = 246.78 seconds

Average message arrival rate = 7 msg/s

Average incoming data rate =  0.002 Mbit/s

Round trip times: min=609.2, max=428207074.7, avg=34003.6 microseconds

000C-POH>ZPFOQ:2000,,16/8:7E03:99999

SENDING MESSAGES: LENGTH=2000; ACK_TIMEOUT=200, WINDOW=16, BURST SIZE=8

TEST MESSAGE NUMBER=0000  RECEIVER FAMILY=04FD

(19:48:45.83) 000C ICSU-0  : 8 MESSAGES MISSED (ack=121)

(19:48:48.17) 000C ICSU-0  : 8 MESSAGES MISSED (ack=141)

(19:48:51.36) 000C ICSU-0   TIMEOUT #1 (WO-EX; prev ack=158)

              (last message sent 19:48:49.36)

(19:48:52.50) 000C ICSU-0   receiving again (WO-EX; ack=169/170)

                            (16 MESSAGES WERE LOST)

(19:48:54.51) 000C ICSU-0   TIMEOUT #2 (WO-EX; prev ack=170)

              (last message sent 19:48:52.51)

(19:48:55.75) 000C ICSU-0   receiving again (WO-EX; ack=181/188)

                            (16 MESSAGES WERE LOST)

(19:48:58.25) 000C ICSU-0  : 8 MESSAGES MISSED (ack=1A1)

(19:49:01.46) 000C ICSU-0   TIMEOUT #3 (WO-EX; prev ack=1B8)

              (last message sent 19:48:59.46)

(19:49:02.47) 000C ICSU-0   receiving again (WO-EX; ack=1C9/1D0)

                            (16 MESSAGES WERE LOST)

(19:49:04.48) 000C ICSU-0   TIMEOUT #4 (WO-EX; prev ack=1D0)

              (last message sent 19:49:02.48)

(19:49:05.50) 000C ICSU-0   receiving again (WO-EX; ack=1E1/1E8)

                            (16 MESSAGES WERE LOST)

(19:49:08.78) 000C ICSU-0  : 8 MESSAGES MISSED (ack=211)

(19:49:38.72) 000C ICSU-0  : 8 MESSAGES MISSED (ack=431)

(19:49:42.05) 000C ICSU-0  : 8 MESSAGES MISSED (ack=461)

(19:49:45.08) 000C ICSU-0   TIMEOUT #5 (WO-EX; prev ack=478)

              (last message sent 19:49:43.08)

(19:49:46.28) 000C ICSU-0   receiving again (WO-EX; ack=489/490)

                            (16 MESSAGES WERE LOST)

Test stopped. Sent 1184 and received 1040 messages.

5 timeouts occurred for 1 different target computers.

5 occurrences of message(s) getting lost.

Elapsed time = 76.19 seconds

Average message arrival rate = 13 msg/s

Assumed outgoing data rate =  0.251 Mbit/s

Average incoming data rate =  0.220 Mbit/s

Thanks

-Vivek

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 7:39 PM
To: Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

It is better to execute them one at a time, otherwise they will affect the result of each other.

(Or at least the throughput test will increase round-trip time results).

-Tero

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, April 26, 2012 5:12 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Tero,

Do you want me to execute both the cmd . each on different terminal, in parallel ?

===========terminal one=====

ZDDS:ICSU;

ZPFS:0,1,4FD

ZPFOR:,,,10:7E03

=====terminal two======

ZDDS:ICSU;

ZPFS:0,1,4FD

ZPFOQ:2000,,16/8:7E03:99999

Thanks

-vivek

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 7:32 PM
To: Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

I forgot one thing: there should be capital-o option in the F command when target is co-siting address

because otherwise POHEXT ignores replies where message header contains own physical address.

Ie. round-trip time test should be:

ZPFS:0,1,4FD

ZPFOR:,,,10:7E03

and throughput test:

ZPFOQ:2000,,16/8:7E03:99999

-Tero

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, April 26, 2012 5:02 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Tero,

For some reason “ZPFQ:2000,,16/8:7E03:99999” cmd did not work. But I have collected output from old cmd.

000C-MAN>ZPFS:0,1,4FD

Test msg id=0000, group=0000, attrs=01, target fam=04FD, target proc=0000

 RNG seed=<clock>, message<-->blockdata gap=FFFFFFFF

Measured CPU clock frequency: 1597 MHz

000C-POH>ZPFR:,,,10:7E03

SENDING MESSAGES: LENGTH=24; ACK_TIMEOUT=200, WINDOW=1

TEST MESSAGE NUMBER=0000  RECEIVER FAMILY=04FD

   10 messages sent. (18:52:03.49)

   20 messages sent. (18:52:24.49)

   30 messages sent. (18:52:45.49)

   40 messages sent. (18:53:06.49)

   50 messages sent. (18:53:27.49)

   60 messages sent. (18:53:48.49)

   70 messages sent. (18:54:09.49)

   80 messages sent. (18:54:30.49)

   90 messages sent. (18:54:51.49)

  100 messages sent. (18:55:12.49)

  200 messages sent. (18:58:42.52) --> Started call at this point of time

  300 messages sent. (19:02:12.66) --> saw error on tester at this point of time (around

  400 calls were there at this point of time)

  400 messages sent. (19:07:00.56)

/*** SESSION ABORTED ***/

/*** TIME OUT IN REMOTE DEBUGGER SESSION ***/

COMMAND EXECUTED

Logs are at below path

Use NSN-intra login/passwd

 

10.135.55.8

/FS000005080/NSN/UIT-5/vivek/cositing2/

Thanks

-Vivek

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 4:34 PM
To: Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

I can't think of any specific logs that would help to identify the reason for messaging delay.

Inter-RNC connectivity configuration details would be more useful for that.

 

Try also a different POHEXT test to measure inter-rnc messaging throughput:

ZDDS:ICSU;

ZLP:P,POH

ZPFS:0,1,4FD

ZPFQ:2000,,16/8:7E03:99999

Do this both before starting traffic, and during traffic.

-Tero

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, April 26, 2012 1:30 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi Tero,

Can you plz list logs required for this, both from cRNC & mcRNC?

I will also capture “pohext F command” output.

Thanks

-Vivek

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 3:42 PM
To: Ilonen, Sami (NSN - FI/Espoo); Wu, Yongkang (NSN - CN/Hangzhou); Gv, Vivek (NSN - IN/Bangalore); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

pohext F command can be used to monitor message transfer delay between RNCs.

ZDDS:ICSU;

ZLP:P,POH

ZPFS:0,1,4FD

ZPFR:,,,10:7E03

This sends messages at 0.1 second intervals and reports min/max/avg round-trip times.

-Tero

 

_____________________________________________
From: Ilonen, Sami (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 12:48 PM
To: Wu, Yongkang (NSN - CN/Hangzhou); Venetjoki, Tero (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Some logs on mcRNC suggests that they are not lost they are heavily delayed (1.25 seconds):

Timer for response in NRM seems to be 1 second.

Random example from mcRNC logs.:

48      D4D2    rrc_allocate_c_rnti_s           nrmprb  0483    -->     rrbprb  000E    12:32:51.546618  00:00:01.162709                156     7D03    0001    0000    80 (SendersView)        7ADB    7D03    00      35650   4       0               36040

49      9DE0    N/A             nrmprb  0483    <--     nrmprb  0483    12:32:52.554634  00:00:02.170725                16      7ADB    0001    0051            7ADB    0001    00      259     1       0       04 (Timer)      36040

50      0A74    nrr_rab_res_del_s               nrmprb  0483    -->     nrrprb  0847    12:32:52.554840  00:00:02.170931                784     7ADB    0001    0000    80 (SendersView)        7ADB    7ADB    00      39907   4       0               36040

63      ADD8    nrm_dch_res_create_ack_s        Result: msg_time_out_ec, error: no_attempt_reserve_resource_ec, error: msg_time_out_ec  rrcprb  02EF    <--     nrmprb  0483    12:32:52.556220  00:00:02.172311                2824    7ADB    0001    0000            7ADB    0001    00      39921   1       0               36040

67      D6E4    rrc_connection_setup_failure_s          rrcprb  02EF    -->     rrbprb  000E    12:32:52.556498  00:00:02.172589                320     7D03    0001    0000    80 (SendersView)        7ADB    7D03    00      39926   4       0               36040

76      D4D1    rrc_allocate_c_rnti_ack_s               nrmprb  0483    <--     rrbprb  000E    12:32:52.799454  00:00:02.415545                126     7D03    0400    0000            7ADB    0001    00      64506   1       251             36040

Regards,

 

        -Sami

_____________________________________________
From: Wu, Yongkang (NSN - CN/Hangzhou)
Sent: Thursday, April 26, 2012 12:22 PM
To: Venetjoki, Tero (NSN - FI/Espoo); Ilonen, Sami (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Laine, Harri (NSN - FI/Espoo); Li, Pengying (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Based on the monitoring from ICSU side, messages are all OK – I randomly selected several cases, and they are all OK. 

So, it is possible that  D4D1 message is lost on the way from RRB@ICSU to NRM @ USCP.

45598   D4D2    rrc_allocate_c_rnti_s                   rrbprb  00AC    <--     nrmprb  0652    12:33:31.12      00:00:07.83            133     7E03    000C    0000    20 (SendToPhys) 7D03    1FFE    00      3D4D

45604   D4D1    rrc_allocate_c_rnti_ack_s               rrbprb  00AC    -->     nrmprb  0652    12:33:31.12      00:00:07.83            120     7E03    000C    0000    80 (SendersView)744F    1FFE    00      43CC

51213   D6E4    rrc_connection_setup_failure_s          rrbprb  00AC    <--     rrcprb  0391    12:33:32.12      00:00:08.83            280     7E03    000C    0000    20 (SendToPhys) 7D03    1FFE    00      502A

 

Combined with Tero’s analysis, it seems there is overload/congestion in the RNC-cl interface.  This may be the root cause of message loss.

Vivek, how many SCTP associations are configured for RNC-cl interface ?   And, can  you take alarm history from cRNC ?

How frequent your 712 R99 calls are setup in one USUP ?

BRs,

WU YK

 

_____________________________________________
From: Venetjoki, Tero (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 5:19 PM
To: Wu, Yongkang (NSN - CN/Hangzhou); Ilonen, Sami (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Laine, Harri (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi

In RRB monitoring there is at most 0.01 second delay between C-RNTI allocation request from NRM and reply to NRM.

RRB<-->RRC rrc_load_info_req_s / rrc_load_info_s messages indicate that Inter-RNC messaging is causing big delays.

Here RRB@ICSU sends load info inquiry to RRC in its own computer, and to RRC@USPU:

50983   A22E    rrc_load_info_req_s                     rrbprb  0000    00      -->     rrcprb  0000    12:33:32.08      00:00:00.00            21      000C    000C    0000    80 (SendersView)        7000    1FFE    00      870C

50984   A22E    rrc_load_info_req_s                     rrbprb  0000    00      -->     rrcprb  0000    12:33:32.08      00:00:00.00            21      7E03    000C    0000    80 (SendersView)        04FE    7D03    00      870D

Local RRC responds immediately:

50992   A22F    rrc_load_info_s CPU load 24, msgs 1, mcc_create_count = 0               rrbprb  0000    00      <--     rrcprb  0000    12:33:32.08      00:00:00.00            94      000C    000C    0000    00 (NA) 000C    1FFE    00      8712

The response from RRC@USPU arrives 0.94 seconds later:

56534   A22F    rrc_load_info_s CPU load 17, msgs 768, mcc_create_count = 4352          rrbprb  0000    00      <--     rrcprb  0000    12:33:33.02      00:00:00.94            94      7E03    000C    0000    20 (SendToPhys) 7D03    1FFE    00      5F6B

 

The next attempt 15 seconds later shows that USPU response arrived after 0.64 seconds:

145211  A22E    rrc_load_info_req_s                     rrbprb  0000    00      -->     rrcprb  0000    12:33:47.09      00:00:00.00            21      7E03    000C    0000    80 (SendersView)        C000    1FFE    00      7FFA

148810  A22F    rrc_load_info_s CPU load 22, msgs 0, mcc_create_count = 1536            rrbprb  0000    00      <--     rrcprb  0000    12:33:47.73      00:00:00.64            94      7E03    000C    0000    20 (SendToPhys) 7D03    1FFE    00      56A9

 

-Tero

_____________________________________________
From: Wu, Yongkang (NSN - CN/Hangzhou)
Sent: Thursday, April 26, 2012 11:55 AM
To: Ilonen, Sami (NSN - FI/Espoo); Gv, Vivek (NSN - IN/Bangalore); Laine, Harri (NSN - FI/Espoo); Venetjoki, Tero (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Please get also cRNC’s message monitoring from following server.

Use NSN-intra login/passwd


10.135.55.8
/FS000005080/NSN/UIT-5/vivek/cositing/reject/

BRs,

WU YK

_____________________________________________
From: Ilonen, Sami (NSN - FI/Espoo)
Sent: Thursday, April 26, 2012 4:54 PM
To: Wu, Yongkang (NSN - CN/Hangzhou); Gv, Vivek (NSN - IN/Bangalore); Laine, Harri (NSN - FI/Espoo); Venetjoki, Tero (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Adding also Tero Venetjoki.

Regards,

        -Sami

_____________________________________________
From: Wu, Yongkang (NSN - CN/Hangzhou)
Sent: Thursday, April 26, 2012 11:45 AM
To: Gv, Vivek (NSN - IN/Bangalore); Ilonen, Sami (NSN - FI/Espoo); Laine, Harri (NSN - FI/Espoo)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

The direct cause of this failure is time out in allocating C_RNTI from cRNC’s RRB.

185970  D4D2    rrc_allocate_c_rnti_s           nrmprb  0253    -->     rrbprb  00E4    12:32:01.327750  00:00:18.728935                156     7D03    0001    0000

198683  9DE0    N/A                             nrmprb  0253    <--     nrmprb  0253    12:32:02.334251  00:00:19.735436                16      7ADB    0001    0051

We need message monitoring both from cRNC’s ICSU (RRB), RSMU (RC3), and mcRNC in order to find which process family may have the problem,

or platform may drop some messages.

Sami and Harri are involved.

BRs,

WU YK

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, April 26, 2012 1:35 PM
To: Wu, Yongkang (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Hope you can access below sever.

Use NSN-intra login/passwd


10.135.55.8
/FS000005080/NSN/UIT-5/vivek/cositing/reject/

Thanks

-vivek

_____________________________________________
From: Wu, Yongkang (NSN - CN/Hangzhou)
Sent: Thursday, April 26, 2012 10:23 AM
To: Gv, Vivek (NSN - IN/Bangalore)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Yes, let’s first analyze that first, to see if it contains the full error scenario or not.

BRs,
WU YK

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Thursday, April 26, 2012 12:57 PM
To: Wu, Yongkang (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi ,

We have uspu monitoring, is this sufficient.

Thanks

-Vivek

_____________________________________________
From: Wu, Yongkang (NSN - CN/Hangzhou)
Sent: Thursday, April 26, 2012 10:21 AM
To: Gv, Vivek (NSN - IN/Bangalore)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Subject: RE: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Have you taken message monitoring from mcRNC side ?

Without it, we can say nothing.

BRs,

WU YK

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Wednesday, April 25, 2012 4:32 PM
To: Wu, Yongkang (NSN - CN/Hangzhou); Li, Pengying (NSN - CN/Hangzhou); Zang, Guojie (NSN - CN/Hangzhou); Ren, Wei (NSN - CN/Hangzhou)
Cc: Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou)
Subject: rrc_connection_setup_failure_s with error “congestion_c”in co-siting env.

Hi,

Can there be problem in platform for rrc_connection_setup_failure_s  with error “congestion_c”in co-siting env?

NOTE: I am forcing the call to establish on mcRNC by using cmd “ZWOC:7,374,3E8;”

Thanks

-Vivek

_____________________________________________
From: Gv, Vivek (NSN - IN/Bangalore)
Sent: Wednesday, April 25, 2012 1:57 PM
To: Lahteenmaki, Kari (NSN - FI/Espoo)
Cc: Aaltonen, Janne J. (NSN - FI/Espoo); Panda, Paban (NSN - IN/Bangalore); Gc, Uday (NSN - IN/Bangalore); Chen, Xuekai (NSN - CN/Hangzhou)
Subject:
rrc_connection_setup_failure_s  with error “congestion_c”in co-siting env.

Hi Kari,

We are finding lots of rrc_connection_setup_failure_s  with error “congestion_c”in co-siting env.

mcRNC Build : R_QNCB.12.13.0_4.WR.mips.bv

cRNC Build: QX121300_cor4

Can you plz let me know what could be the reason? Also let me know PRB to be collected in emil monitoring at both cRNC & mcRNC side.

There is around 712 R99 calls (64DL/64UL) on USPU that perform state-transfer.

 << File: LOG000C.zipx >>

Thanks

-Vivek





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================