Impact of changing ThreadX timebase to 1ms

[Zainulabedeen]

I have changed the ThreadX system timebase on an STM32H7 from 10 ms to 1 ms (i.e., the RTOS tick is now 1 ms). The application is quite large and makes extensive use of ThreadX services such as thread delays, semaphores, mutexes, event flags, and timeouts in various system calls, all of which are specified in ticks. With this change, the real-time duration of existing delays and timeouts is effectively reduced (for example, a delay that was previously 1 second now becomes 100 ms), so I would like to understand whether these values need to be scaled accordingly or refactored using time-based conversion macros to preserve behavior. In addition, the system uses NetX Duo, which runs on top of ThreadX, and I would like to confirm whether NetX Duo fully depends on the same ThreadX tick and whether changing the tick period to 1 ms has implications for network timing, such as TCP timeouts, retransmissions, or protocol timers. Finally, I am interested in best practices and potential risks, such as increased CPU load, timing jitter, or stability issues, when moving to a 1 ms tick on STM32H7, and how to adjust the system safely so the application continues to run reliably without crashes.

[Khaled_DHIF · Accepted solution]

Hello @Zainulabedeen ,

You’re right to question this change: moving the ThreadX tick from 10 ms to 1 ms changes the meaning of every timeout and delay expressed in ticks, in both ThreadX and NetX Duo.

•  Do we need to fix existing timeouts?

Yes, if you want to keep the original behavior.

- Either scaled by 10, or (better)
- Converted to use time‑based macros so the code becomes independent of the tick rate.

Example of what you can add in a common header:

#define TX_TIMER_TICKS_PER_SECOND 1000u /* 1 ms tick */

#define MS_TO_TICKS(ms) ((ULONG)(((ms) * TX_TIMER_TICKS_PER_SECOND) / 1000u))
#define SEC_TO_TICKS(s) ((ULONG)((s) * TX_TIMER_TICKS_PER_SECOND))

•  What about NetX Duo?

NetX Duo uses the same ThreadX tick for all its protocol timers:

- TCP retransmits and timeouts
- ARP cache aging
- DHCP timers, etc.

If you just change the tick to 1 ms and leave everything else as is, all of these become 10× shorter. That can make the network stack behave more aggressively (more frequent retries, faster timeouts).

So, it’s important to:

- Review the timing-related settings in nx_user.h (and any NetX code using wait_option),
- Express them using the same MS_TO_TICKS / SEC_TO_TICKS macros, so real‑time behavior stays the same.

• Practical impact and risks

- CPU load: the tick interrupt and timer handling now run 10× more often. On STM32H7 this is usually OK, but it’s worth measuring. (use SEGGER SystemView or similar to profile the exact behavior)
- Behavior changes: if timeouts get too short, you might see early timeouts, more retries, or unstable behavior under load. 

Kind regards,

DHIF Khaled

[Zainulabedeen]

Thanks @Khaled_DHIF.