What does 'NDDS Alarm: Unable to serialize fired message' mean?

Note: Applies to RTI NDDS 3.x.

Error message: NDDS Alarm: Unable to serialize fired message 
NDDS Alarm: Alarm event: 129 period: 0.249996781 next time: 190.643200517 task 1512

This message most likely indicates that NDDS was unable to use the stack to send a local UDP message. It is usually caused by the stack running out of "data pool" buffers. Are you noticing any slow down in data transmission? For best-effort communication, this would cause extra data loss. For reliable communication, the packet loss would cause more resends, further aggravating the symptoms. Thus, NDDS will not easily recover from this error unless the application sends less data until the buffer can be cleared. 

Depending on the operating system, changing the number of buffers and their sizes requires changing the kernel configuration parameters. This is different from non real-time OS's (Windows, UNIX) where the buffers can be allocated as needed from main memory. 

When using NDDS on VxWorks, it is sometimes necessary to modify the buffer allocation parameters to achieve optimal performance or to avoid running out of buffers. In certain cases, running out of buffers is a fatal event, which can stop the stack from sending or receiving further data until the target is rebooted. 

On VxWorks systems, you can monitor the state of the data buffer usage inside the stack with the netStackDataPoolShow or mbufShow functions. (Both commands provide the same information.) If the stack has been running out of clusters, these commands will show as an increasing "number of times failed to find space". If the command indicates that the stack sometimes runs out of buffers, you should either reduce the socket receive queues (which will result in dropped packets), or better yet, increase the number of clusters available to the stack. 

If you are building your kernel using the project facility, here's how to increase the number of clusters (for more information, consult your VxWorks manuals): 

The parameters below normally control the number of buffers of each size within the data pool. They are located under the properties for "network components" -> "basic network initialization" -> "network buffer initialization" in your kernel configuration. (Choose the "VxWorks" tab of your Workspace window, expand the tree to the above entry, right-click and select "Properties", then select the "Params" tab.) The parameters are:

  • NUM_64 -- number of 64 byte clusters in the data pool (default: 100)
  • NUM_128 -- number of 128 byte clusters in the data pool (default: 100)
  • NUM_256 -- number of 256 byte clusters in the data pool (default: 40)
  • NUM_512 -- number of 512 byte clusters in the data pool (default: 40)
  • NUM_1024 -- number of 1 Kbyte clusters in the data pool (default: 25)
  • NUM_2048 -- number of 2 Kbyte clusters in the data pool (default: 25) 

Increasing the values will increase the number of data clusters available to the stack. 

After making the changes, rebuild the kernel and reboot. 

You can confirm the changes by running mbufShow from a WindShell or the target-resident shell. The numbers of clusters shown in the "CLUSTER POOL TABLE" section should match the parameters that you specified.