nasa / nasa/cFS

Inconsistent default values for cmd pipe depth across apps

Open
#1,122 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
1.5k
Forks
391
Avg merge
1d 11h
Merged PRs (30d)
19

Description

Checklist (Please check before submitting)

  • I reviewed the Contributing Guide.
  • I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
All apps have a setting to control the depth (and name, ideally) of their respective command input pipe.
The problem is many of these are hardcoded to an integer number that is often much larger than it really needs to be.

For example DS has its pipe depth configured to 45. This is very large.
CFE SB had its pipe depth fixed at 32 and was non-configurable, as it was in a local header file.

As most linux distros will (by default) limit POSIX message queue pipe depth to 10, the CFS defaults should also work with OS_QUEUE_MAX_DEPTH set to 10, since this would be the "proper" solution (as opposed to the debug solution of silently truncating the depth to 10 even though a larger queue was requested).

To Reproduce
Set OS_QUEUE_MAX_DEPTH osal configuration parameter to 10 so it will boot normally on an un-tweaked Linux kernel without needing root privileges.

Some apps will fail to compile with default config, other apps will fail to boot even if they do compile.

Expected behavior
All apps should compile and boot with the queue depth set to 10.

The approach should be to use the conservative (but universally supportable) value as the default. A depth of 10 is more than enough so long as there is no CPU contention (i.e. tasks wake up to service their queue in a timely fashion).

System observed on:
Linux

Additional context
The user can extend/increase the value if their needs dictate, but a need for a deep queue depth probably indicates a more fundamental architectural issue like a CPU not having enough margin to process the workloads effectively. In these scenarios where the consumer is not keeping pace with the sender and multiple items start backing up, a deeper queue usually just delays the failure, it does not fix it.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the command input pipe defaults for DS and CFE SB, then review the other apps' settings alongside the OS_QUEUE_MAX_DEPTH configuration. Build and boot the apps with OS_QUEUE_MAX_DEPTH set to 10; done means every app compiles and boots without requiring a larger queue depth.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.