Skip to content
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

An 0.5s System Error #101

Open
WhymustIhaveaname opened this issue Apr 23, 2020 · 3 comments · May be fixed by #102, #132, #146 or #148
Open

An 0.5s System Error #101

WhymustIhaveaname opened this issue Apr 23, 2020 · 3 comments · May be fixed by #102, #132, #146 or #148
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project

Comments

@WhymustIhaveaname
Copy link

This library only saves seconds will lead to a system error between 0 and 1 second, average 0.5s.

For example, the program synchronizes at 0h0m0 .9s. By the design, it saves time as 0s. After 0.2s, i.e. 0h0m1.1s, I use getFormattedTime(). It should return 0h0m1s, but it will return 0h0m0s. It will not update the time until 0h0m1.9s. As so it will update 2s at 2.9s, 3s at 3.9s. This is a const system error.

The NTP can achieve an accuracy below 10ms. So this about 0.5s error is catastrophic.
issue79 and issue23 relate to this.
@WhymustIhaveaname
Copy link
Author

I rewrite something and,
1 increase time accuracy to not above 100ms
1.1 complete decimal part of NTP
1.2 use high-freq polling
1.3 add _current_epoc_dec and get_millis() so that ms can be known
2 rewrite update()
2.1 solved overflow problem
2.2 change update()'s return type to byte in order to carry more info
2.3 add a not-request-too-fast feature by adding _last_fail in update()
3 change all unsigned long to uint32_t, int to uint16_t, etc. to make it more stable

If you want to update this repo, I can help.

@Testato
Copy link
Contributor

Testato commented Apr 24, 2020

Please submit a Pull Request so we can review it

@WhymustIhaveaname
Copy link
Author

I submit a Pull Request.
I have tested my codes in LAN and in WAN. As to the accuracy, it can achieve 10ms in LAN and 100ms in WAN.

@WhymustIhaveaname WhymustIhaveaname mentioned this issue May 6, 2020
Open
@per1234 per1234 linked a pull request Nov 5, 2021 that will close this issue
Increase time accuracy #102
Open
@per1234 per1234 added type: imperfection Perceived defect in any part of project topic: code Related to content of the project itself labels Jun 23, 2024
This was linked to pull requests Jun 23, 2024
Increases the accuracy of the synchronization by a factor of 50. #132
Open
Enable fractional second timestamps (re-integration of #102) #146
Open
Added processing of fractional time, setting of currentEpoch, sanity checking of received timestamps, and new example. #148
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project
Projects
None yet
Milestone
No milestone
3 participants
@Testato @per1234 @WhymustIhaveaname