feat(utils): use NTP timestamps to avoid sync problems #883
Conversation
lrubiorod
force-pushed
the
ntp
branch
3 times, most recently
from
2c4dae4 to
e7d6168
Compare
|
I think it would be better to move the NTP updating mechanism outside of the get_timestamp function. The main issue with the current approach is the timeout: a call to get_timestamp can block for up to 5 seconds. We could have a periodic callback, for example in EpochManager, which would call update_global_timestamp. This way all the calls to get_timestamp have more or less the same overhead. It would be really nice if that function was async, so that it doesn't block the executor thread, but the NTP crate used here does not allow that. I don't know if there are other crates with that feature, but we could create a new issue for replacing the NTP request with an async one. |
lrubiorod
force-pushed
the
ntp
branch
2 times, most recently
from
eecffe4 to
39f428d
Compare
lrubiorod
force-pushed
the
ntp
branch
3 times, most recently
from
a1585b2 to
4026853
Compare
lrubiorod
force-pushed
the
ntp
branch
2 times, most recently
from
7eccc41 to
0fcea21
Compare
config/src/config.rs
Outdated
| @@ -276,6 +281,17 @@ pub struct Mining { | |||
| pub enabled: bool, | |||
| } | |||
|
|
|||
| /// Ntp-related configuration | |||
There was a problem hiding this comment.
| /// Ntp-related configuration | |
| /// NTP-related configuration |
And we should probably explain somewhere what is NTP and why it's useful.
There was a problem hiding this comment.
in witnet.io documentation?
There was a problem hiding this comment.
Ok, created witnet/documentation#20
lrubiorod
force-pushed
the
ntp
branch
4 times, most recently
from
60c8d37 to
eec7e62
Compare
Close #874