Skip to content

Feature request: To allow runtime config SNTP sync interval (IDFGH-2298) #4437

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
AxelLin opened this issue Dec 4, 2019 · 9 comments
Closed

Feature request: To allow runtime config SNTP sync interval (IDFGH-2298) #4437

AxelLin opened this issue Dec 4, 2019 · 9 comments
Assignees
@KonstantinKondrashov

Comments

@AxelLin
Copy link
Contributor

AxelLin commented Dec 4, 2019

In current ESP-IDF, the SNTP sync interval is determinate by CONFIG_LWIP_SNTP_UPDATE_DELAY at compile time.
The compile time determinate setting cannot meet various use cases.
Suggest to provide API for setting SNTP sync interval at run-time so this setting can be user configurable.
@github-actions github-actions bot changed the title Feature request: To allow runtime config SNTP sync interval Feature request: To allow runtime config SNTP sync interval (IDFGH-2298) Dec 4, 2019
@Alvin1Zhang
Copy link
Collaborator

@AxelLin Thanks for reporting.

@KonstantinKondrashov
Copy link
Collaborator

Hi @AxelLin!
Yes, right now the SNTP sync interval is determinate by CONFIG_LWIP_SNTP_UPDATE_DELAY at compile time.
I agree that to change the sync interval in runtime is useful for some use cases. I will add a function to set it.
Thanks.

@Eugene-Ilyushchyts
Copy link

Eugene-Ilyushchyts commented Feb 4, 2020 •
edited
Loading

Hi @KonstantinKondrashov ,
Are you sure that it works ? Have you checked this ?
Let's see example from esp-idf release 4.1 (same behavior on the release 4.0 )

I (29) boot: ESP-IDF v4.1-dev-1961-g73384c1-dirty 2nd stage bootloader
I (29) boot: compile time 22:45:12
I (30) boot: chip revision: 1
I (34) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (41) boot.esp32: SPI Speed : 40MHz
I (46) boot.esp32: SPI Mode : DIO
I (50) boot.esp32: SPI Flash Size : 2MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label Usage Type ST Offset Length
I (71) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (78) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (86) boot: 2 factory factory app 00 00 00010000 00100000
I (93) boot: End of partition table
I (97) boot_comm: chip revision: 1, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x1a02c (106540) map
I (152) esp_image: segment 1: paddr=0x0002a054 vaddr=0x3ffb0000 size=0x03974 ( 14708) load
I (158) esp_image: segment 2: paddr=0x0002d9d0 vaddr=0x40080000 size=0x00400 ( 1024) load
I (159) esp_image: segment 3: paddr=0x0002ddd8 vaddr=0x40080400 size=0x02240 ( 8768) load
I (171) esp_image: segment 4: paddr=0x00030020 vaddr=0x400d0020 size=0x7b0cc (504012) map
I (356) esp_image: segment 5: paddr=0x000ab0f4 vaddr=0x40082640 size=0x13d04 ( 81156) load
I (391) esp_image: segment 6: paddr=0x000bee00 vaddr=0x400c0000 size=0x00064 ( 100) load
I (391) esp_image: segment 7: paddr=0x000bee6c vaddr=0x50000000 size=0x00004 ( 4) load
I (411) boot: Loaded app from partition at offset 0x10000
I (411) boot: Disabling RNG early entropy source...
I (412) cpu_start: Pro cpu up.
I (415) cpu_start: Application information:
I (420) cpu_start: Project name: sntp
I (425) cpu_start: App version: 1
I (429) cpu_start: Compile time: Feb 4 2020 22:45:11
I (435) cpu_start: ELF file SHA256: 189bb229ffd4d0d8...
I (441) cpu_start: ESP-IDF: v4.1-dev-1961-g73384c1-dirty
I (448) cpu_start: Starting app cpu, entry point is 0x40081278
I (0) cpu_start: App cpu up.
I (459) heap_init: Initializing. RAM available for dynamic allocation:
I (465) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (471) heap_init: At 3FFB92C0 len 00026D40 (155 KiB): DRAM
I (478) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (484) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (490) heap_init: At 40096344 len 00009CBC (39 KiB): IRAM
I (497) cpu_start: Pro cpu start user code
I (515) spi_flash: detected chip: gd
I (515) spi_flash: flash io: dio
W (516) spi_flash: Detected size(16384k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (526) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (536) example: Boot count: 1
I (536) example: Time is not set yet. Connecting to WiFi and getting time over NTP.
I (596) wifi: wifi driver task: 3ffc0e90, prio:23, stack:3584, core=0
I (596) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (596) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (626) wifi: wifi firmware version: f1dc391
I (626) wifi: config NVS flash: enabled
I (626) wifi: config nano formating: disabled
I (626) wifi: Init dynamic tx buffer num: 32
I (636) wifi: Init data frame dynamic rx buffer num: 32
I (636) wifi: Init management frame dynamic rx buffer num: 32
I (646) wifi: Init management short buffer num: 32
I (646) wifi: Init static rx buffer size: 1600
I (656) wifi: Init static rx buffer num: 10
I (656) wifi: Init dynamic rx buffer num: 32
I (666) example_connect: Connecting to Butternut...
I (756) phy: phy_version: 4180, cb3948e, Sep 12 2019, 16:39:13, 0, 0
I (756) wifi: mode : sta (bc:dd:c2:cf:83:28)
I (766) example_connect: Waiting for IP
I (1606) wifi: new:<11,0>, old:<1,0>, ap:<255,255>, sta:<11,0>, prof:1
I (2376) wifi: state: init -> auth (b0)
I (2376) wifi: state: auth -> assoc (0)
I (2386) wifi: state: assoc -> run (10)
I (2406) wifi: connected with Butternut, aid = 11, channel 11, BW20, bssid = 4a:a4:72:3b:fd:fd
I (2406) wifi: security type: 3, phy: bgn, rssi: -43
I (2406) wifi: pm start, type: 1

I (2436) wifi: AP's beacon interval = 102400 us, DTIM period = 3
I (3086) esp_netif_handlers: sta ip: 192.168.137.201, mask: 255.255.255.0, gw: 192.168.137.1
I (3086) example_connect: Got IP event!
I (3586) example_connect: Got IPv6 event!
I (3586) example_connect: Connected to Butternut
I (3586) example_connect: IPv4 address: 192.168.137.201
I (3586) example_connect: IPv6 address: fe80:0000:0000:0000:bedd:c2ff:fecf:8328
I (3596) example: Initializing SNTP
I (3606) example: Waiting for system time to be set... (1/25)
I (4606) example: Waiting for system time to be set... (2/25)
I (5606) example: Waiting for system time to be set... (3/25)
I (6606) example: Waiting for system time to be set... (4/25)
I (7606) example: Waiting for system time to be set... (5/25)
I (8606) example: Waiting for system time to be set... (6/25)
I (9606) example: Waiting for system time to be set... (7/25)
I (10606) example: Waiting for system time to be set... (8/25)
I (11606) example: Waiting for system time to be set... (9/25)
I (12606) example: Waiting for system time to be set... (10/25)
I (13606) example: Waiting for system time to be set... (11/25)
I (14606) example: Waiting for system time to be set... (12/25)
I (15606) example: Waiting for system time to be set... (13/25)
I (16606) example: Waiting for system time to be set... (14/25)
I (17606) example: Waiting for system time to be set... (15/25)
I (18606) example: Waiting for system time to be set... (16/25)
I (19606) example: Waiting for system time to be set... (17/25)
I (20606) example: Waiting for system time to be set... (18/25)
I (21606) example: Waiting for system time to be set... (19/25)
I (22606) example: Waiting for system time to be set... (20/25)
I (23606) example: Waiting for system time to be set... (21/25)
I (24606) example: Waiting for system time to be set... (22/25)
I (25606) example: Waiting for system time to be set... (23/25)
I (26606) example: Waiting for system time to be set... (24/25)

As you can see, it failed to sync for 25 seconds (in the code sntp_set_sync_interval(15000);)
This behavior occurs approximately 1 time out of 20.
This is very critical for my app. I want to note that in release 3.3 everything was fine.

@KonstantinKondrashov
Copy link
Collaborator

KonstantinKondrashov commented Feb 5, 2020 •
edited
Loading

Hi @Eugene-Ilyushchyts !
Your log shows that the device can not connect to the SNTP server. Waiting for system time to be set... (N/25). This issue is not linked with the sync interval. The sync interval will be applied only after receiving an answer from the SNTP server successfully.
Probably do you mean the receive timeout (SNTP_RECV_TIMEOUT)? but the default value is 15 sec and must not be below 15 seconds by the specification.

@Eugene-Ilyushchyts
Copy link

Eugene-Ilyushchyts commented Feb 5, 2020 •
edited
Loading

@KonstantinKondrashov
Yes, I meant the response timeout from server.
In the esp-idf release 3.3 branch, we never waited more than 2 seconds. But I had a workaround like this:

while (sntp_get_sync_status() == SNTP_SYNC_STATUS_RESET && ++retry < retry_count)
{
initialize_sntp();
ESP_LOGI(TAG, "Waiting for system time to be set... (%d/%d)", retry, retry_count);
vTaskDelay(1000 / portTICK_PERIOD_MS);
}

Now this workaround doesn't work.
Please advise how I can work around this problem by getting a response from the server within 2-4 seconds each time, as in the release 3.3 branch?

Thank you in advance.

@KonstantinKondrashov
Copy link
Collaborator

I have checked this example right now with your v4.1-dev-1961-g73384c1 version and I did not observe any issue, it updates time while the first 2-3 seconds.
I think in your case there is a problem with access to the SNTP server.

Your workaround looks strange. Each a second you call initialize_sntp(). It means you give the SNTP server only 1 sec. Please change the timeout at least to vTaskDelay(2 or 3 sec) .

while (sntp_get_sync_status() == SNTP_SYNC_STATUS_RESET && ++retry < retry_count)
{
    ESP_LOGI(TAG, "Waiting for system time to be set... (%d/%d)", retry, retry_count);
    vTaskDelay(1000 / portTICK_PERIOD_MS);
    if (retry % 3 == 0) {
        sntp_restart(); // Instead of initialize_sntp() you can use this function - sntp_restart().
    }
}

@Eugene-Ilyushchyts
Copy link

Eugene-Ilyushchyts commented Feb 5, 2020 •
edited
Loading

@KonstantinKondrashov
Thanks for the answer.
I checked the workaround you suggested and I have the following result:
of the 45 attempts, 2 were 12 seconds long and once it didn't sync at all. .
Unfortunately, This is a very long time for us.
Could you advise something else ?
I've checked this on different boards and different APs.
I observe the same behavior.

@KonstantinKondrashov
Copy link
Collaborator

@Eugene-Ilyushchyts
Could you create a new issue because this is not relevant to yours and closed? There is an issue template which guides you through the steps of creating an issue. The more information you provide here, the more likely someone here will help. Thanks!

I will try to reproduce your issue from my side.

@Eugene-Ilyushchyts
Copy link

@KonstantinKondrashov
Hi,
I created the issue #4718 29 days ago.
Is there a chance that someone will answer me on this question ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@KonstantinKondrashov KonstantinKondrashov

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@AxelLin @Eugene-Ilyushchyts @KonstantinKondrashov @Alvin1Zhang