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

Question

question

JamesMerkle-5529 asked Apr 26, '22 asergaz answered Apr 28, '22

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

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-rtos

· 3

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

asergaz · Apr 27 at 03:12 PM

Hi @JamesMerkle-5529 ,
To help understand better your environment, are you getting these results while using the sample?
https://github.com/azure-rtos/netxduo/blob/master/samples/demo_netxduo_sntp_client.c

We are tracking new issues\bugs directly in the netxduo repo, please can you file a new issue there as well? https://github.com/azure-rtos/netxduo/issues

Thank you!

0 ·

JamesMerkle-5529 asergaz · Apr 27 at 03:54 PM

The sample code creates a system from scratch to demonstrate the sntp client. Since I already have a system with USB-CDC serial, command-line interface, network and thread analysis tools, the sample code would be hacked severely to create something I could use. Even if I used the sample code, the sntp client has it's own thread, it's own initialization code, and it's own 10ms polling loop, as previously documented, independent of any other interface code.
Defining NX_SNTP_CLIENT_SLEEP_INTERVAL=100 within the project properties decreases the polling rate from every 10ms to once per second, and drops the CPU utilization down to 1% of its earlier value. This is a "quick fix" for the rapid polling problem, but the ability to request network time repeatedly appears to be a problem. The first time I get the NTP 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.

1 ·

asergaz JamesMerkle-5529 · Apr 28 at 09:53 AM

@JamesMerkle-5529 thanks for the clarification! I am syncing with Product Team to have feedback on specially your observation:

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

Thank you so much for your time so far.

0 ·

Answer 1 · 2022-04-28T10:56:53.253Z

asergaz answered Apr 28, '22

Hello @JamesMerkle-5529 ,

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:

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.

release.gif (306.0 KiB)

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

question