SNTP Client thread has highest "tx_thread_run_count" in the system. It this appropriate?

James Merkle 6 Reputation points
2022-04-26T16:09:31.84+00:00

Using ThreadX and NetXDuo, along with SNTP Client, ver 6.1 (nxd_sntp_client.c).
I have TX_THREAD_ENABLE_PERFORMANCE_INFO defined for my ThreadX build, such that each thread maintains counters
When examining the system / ThreadX threads, specifically the thread->tx_thread_run_count fields for each thread, and then sorting the information, the SNTP service thread jumps to the top of the list due to its rapid 10ms polling.

>top

resumptions 536943240, suspensions 0, solicited_preemptions 0, interrupt_preemptions 0
priority_inversions 0, time_slices 0, relinquishes 536770476, timeouts 536946192
wait_aborts 18895, non_idle_returns 3, idle_returns 24031

      Thread Name          pri   counts  percent  stack_size   unused
              idle_thread   9     60225    47.3      1024        924
         NetX SNTP Client   2     54676    42.9      2048       1676
        g_ip0 IP Instance   3     11505     9.0      3072       1960
         NetX DHCP Client   3       561     0.4      2048       1700
           USB CDC Thread   2       270     0.2      3072       1732
               tx0_thread   2        49     0.0      3072       2076
              mqtt_thread   5        39     0.0      4096       2540
 Network Interface thread   3        20     0.0      3072       1784
               rx1_thread   2        14     0.0      2048       1192
               rx2_thread   2        14     0.0      2048       1192
               rx0_thread   2        13     0.0      2048       1192
            mqtt_client_0   2        11     0.0      4096       3852
network_processing_thread   4         2     0.0      4096       3432
   firmware_update_thread   3         1     0.0      4096       3796
>

It appears this SNTP thread is sucking 43% of the CPU resources!

>network

Network parameters from storage:
MAC from storage 8C:1F:64:C5:00:07
Static IP from storage 0.0.0.0
Netmask from storage 0.0.0.0
Gateway from storage 0.0.0.0

Using DHCP. Static IP, Netmask, and Gateway parameters not used

g_packet_pool0 info:
total packets: 40, free_packets: 32
empty_pool_requests: 0, empty_pool_suspensions: 0, invalid_packet_releases: 0

IP statistics
ip_packets_sent: 219, ip_bytes_sent: 16504, ip_packets_received: 10475, ip_bytes_received: 992720
ip_invalid_packets: 0, ip_rx_packets_dropped: 1360, ip_rx_checksum_errors: 0
ip_tx_packets_dropped: 0, ip_total_fragments_sent: 0, ip_total_fragments_received: 0

TCP statistics
tcp_packets_sent: 37, tcp_bytes_sent: 4501, tcp_packets_received: 5, tcp_bytes_received: 29
tcp_invalid_packets: 0, tcp_receive_packets_dropped: 10, tcp_checksum_errors: 0, tcp_connections: 1
tcp_disconnections: 0, tcp_connections_dropped: 8, tcp_retransmit_packets: 0

UDP statistics
udp_packets_sent: 125, udp_bytes_sent: 9367, udp_packets_received: 7312, udp_bytes_received: 3327
udp_invalid_packets: 0, udp_receive_packets_dropped: 7187, udp_checksum_errors: 0

Current network parameters
Interface: "PRI", mtu_size: 1500, MAC: 8C1F64C50007
address 10.0.0.206
netmask 255.255.255.0
gateway 10.0.0.254

Except for a couple UDP packets, the UDP packets displayed above are from a proprietary discovery service, not SNTP.
It appears the main loop within nxd_sntp_client.c, _nx_sntp_client_thread_entry() is looping WAY TOO OFTEN and isn't event driven.
The default value for NX_SNTP_CLIENT_SLEEP_INTERVAL, is 1, creating a 10ms polling function.

Although I can define a longer polling time, say 1 second, the main loop within this service should be event driven vs polled.

Am I missing anything?

Azure IoT
Azure IoT
A category of Azure services for internet of things devices.
391 questions
Azure RTOS
Azure RTOS
An Azure embedded development suite including a small but powerful operating system for resource-constrained devices.
329 questions
{count} votes

1 answer

Sort by: Most helpful
  1. António Sérgio Azevedo 7,666 Reputation points Microsoft Employee
    2022-04-28T10:56:53.253+00:00

    Hello @James Merkle ,

    I have received confirmation from Product Team that (like you well observed) SNTP service thread should be event driven vs polled. We will improve the logic in next release. Can you please add a watch Release in netxduo github repo to be notified when the next release is out:

    197361-release.gif

    As for the other concern you added in the comments:

    The first time I get the SNTP time, this works great, but after waiting five seconds and then trying again, it returns the same time as before, not advanced by five seconds.

    In this sample, we use SNTP to sync the time https://github.com/azure-rtos/netxduo/blob/master/addons/azure_iot/samples/main.c#L525-L537 , then calculate with tx_time_get() and record it , then get the current time here https://github.com/azure-rtos/netxduo/blob/master/addons/azure_iot/samples/main.c#L634-L640 . Can you try this sample and implement it that way in your solution?

    Thanks!

    Remember:

    • Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
    • Want a reminder to come back and check responses? Here is how to subscribe to a notification.
    0 comments No comments