TBL - Dump Table Registry Data Command Can Hog CPU (GSFC DCR 23031)

[skliper]

The GSFC NICER FSW team discovered that it takes approximately 1 second to process the Dump Table Registry command when there are 250 RTS tables and that lower priority tasks generate various error events related to not getting an opportunity to run. Adding a platform configuration definition to insert task delays into the process loop will increase the time necessary for CFE_TBL to finish the command but will allow lower priority tasks to run while the command is being processed.

Also, creating some test code that puts performance markers around the file i/o calls within the command processor may identify where the bulk of the command process time is spent. It may be possible to reduce the command execution time by optimizing the command handler code if the bulk of the execution time is not being spent inside the file system.

[skliper]

Imported from trac issue 108. Created by sstrege on 2015-08-28T16:09:54, last modified: 2019-03-01T15:27:58

[skliper]

Trac comment by glimes on 2016-10-18 15:07:03:

Remove my name from many tickets (where it was applied by default), so others can tell that there are tickets that need some attention.

[skliper]

The file writing should likely be moved to a low priority child task, same for any other potentially "large" file writes: CFE_SB_SendRtgInfo, CFE_SB_SendPipeInfo, CFE_SB_SendMapInfo

[jphickey]

These all sound like great candidates for moving into the ES background job service.

Make a generic file writer job template based on the current perf data dump, then apply it for all these file dump commands.

[skliper]

Note - standby on this until #928 is implemented (for SB writes), since they are being refactored.

[skliper]

Removed dependency label, this can be resolved now.