CPU usage of IOC too high occupied by tNet and CAS-event task

[王林 <wanglin@ihep.ac.cn>]

Hello,

Our LLRF control system works at 25Hz repetition, every 40ms, 8 FPGA I/O cards respectively acquire 8 RF cavities' runtime data, generate interrupt to CPU and transfer them to EPICS database, data finally displayed by EPICS OPI. For each card, runtime data consists of 8 2048-element waveforms of one cavity, and transfered to CPU memory buffer via cPCI DMA, then to 8 EPICS waveform records, finally displayed by EDM or CSS BOY.

Currently, we are debugging with single card (and single cavity), and data displayed by OPI is correct, but the CPU usage is as high as 56%, monitored by vxStats1-2 module. Each I/O card have the same set of PVs, due to 56% CPU usage of one card  , I am afraid 8 cards can hardly work together.

vxWorks spy() displays the information as follows (task with 0% usage removed),

->spy
NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
--------     --------      -----  ---   ---------------  ---------------
tNetTask     netTask    3be4f0d0   50    11% (      56)   11% (      56)
CAS-event               3bb998b0  180    31% (     157)   31% (     157)
KERNEL                                    1% (       7)    1% (       7)
INTERRUPT                                 3% (      18)    3% (      18)
IDLE                                     52% (     262)   52% (     262)
TOTAL                                    98% (     500)   98% (     500)

 

NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
--------     --------      -----  ---   ---------------  ---------------
tNetTask     netTask    3be4f0d0   50    11% (     142)   11% (      86)
CAS-event               3bb998b0  180    27% (     342)   24% (     185)
KERNEL                                    1% (      23)    2% (      16)
INTERRUPT                                 3% (      50)    4% (      32)
IDLE                                     55% (     696)   57% (     434)
TOTAL                                    97% (    1257)   98% (     757)

 

NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
--------     --------      -----  ---   ---------------  ---------------
tNetTask     netTask    3be4f0d0   50    11% (     240)   12% (      98)
CAS-event               3bb998b0  180    27% (     563)   29% (     221)
cpuUsageTask            3bc5e4a0  255    12% (     242)   32% (     242)
KERNEL                                    2% (      49)    3% (      26)
INTERRUPT                                 4% (      85)    4% (      35)
IDLE                                     40% (     825)   17% (     129)
TOTAL                                    96% (    2013)   97% (     756)

NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
--------     --------      -----  ---   ---------------  ---------------
tNetTask     netTask    3be4f0d0   50    11% (     317)   10% (      77)
CAS-event               3bb998b0   50    28% (     792)   30% (     229)
cpuUsageTask            3bc5e4a0  255     8% (     242)    0% (       0)
KERNEL                                    2% (      78)    3% (      29)
INTERRUPT                                 4% (     120)    4% (      35)
IDLE                                     43% (    1208)   50% (     383)
TOTAL                                    96% (    2768)   97% (     755)

NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
--------     --------      -----  ---   ---------------  ---------------
tNetTask     netTask    3be4f0d0   50    11% (     414)   12% (      97)
CAS-event               3bb998b0  180    29% (    1023)   30% (     231)
cpuUsageTask            3bc5e4a0  255     9% (     337)   12% (      95)
KERNEL                                    2% (      97)    2% (      19)
INTERRUPT                                 4% (     152)    4% (      32)
IDLE                                     42% (    1485)   36% (     277)
TOTAL                                    97% (    3524)   96% (     756)

 

Actually, the problem is caused by 8 waveform records, each of which has 2048 float elements and "I/O Intr" SCAN field, that is, each waveform record is also processed at 25Hz. If I remove 7 of the waveform records and remain only 1, the CPU usage will drop down to 28%, and if remove all, it will drop down to 3%.

 

The platform is vxWorks5.5.1/EPICS3.14.12.1/MPC7410(500M), and these network related macros are redefined in my configAll.h,

 

#define NUM_64   250 /* no. 64 byte clusters */
#define NUM_128   400 
#define NUM_256   50 /* no. 256 byte clusters */
#define NUM_512   50 /* no. 512 byte clusters */
#define NUM_1024  25 /* no. 1024 byte clusters */
#define NUM_2048  25 /* no. 2048 byte clusters */
#define NUM_CL_BLKS  800

 

#define NUM_SYS_64  1024 /*  64 byte system clusters */
#define NUM_SYS_128  1024 /* 128 byte system clusters */
#define NUM_SYS_256  512 /* 256 byte system clusters */
#define NUM_SYS_512  512 /* 512 byte system clusters */
#define NUM_SYS_CL_BLKS  3072
#define NUM_SYS_MBLKS  3072

With the appearance above, what do you think the problem is? Wavefrom record should not be processed so frequently, network problem, or other configurations (of EPICS or vxWorks) should be made?

 

 

Thanks,

Lin Wang