Allow for limited wallclock rollback #2781
Labels
consensus
issues related to ouroboros-consensus
Comments
mrBliss
added a commit
that referenced
this issue
Dec 1, 2020
iohk-bors bot
added a commit
that referenced
this issue
Dec 2, 2020
2785: Allow for limited wallclock rollback r=mrBliss a=mrBliss Fixes #2781. By default, we will allow the system clock to roll back three seconds to account for time changes because of NTP. When this happens, `TraceSystemClockMovedBack` will be traced. Not that the current slot won't decrease, we'll just stay in the same slot longer. When the system clock rolls back more than three seconds, we still shut down with the fatal `SystemClockMovedBack` exception. Co-authored-by: Thomas Winant <thomas@well-typed.com>
iohk-bors bot
added a commit
that referenced
this issue
Dec 2, 2020
2785: Allow for limited wallclock rollback r=mrBliss a=mrBliss Fixes #2781. By default, we will allow the system clock to roll back three seconds to account for time changes because of NTP. When this happens, `TraceSystemClockMovedBack` will be traced. Not that the current slot won't decrease, we'll just stay in the same slot longer. When the system clock rolls back more than three seconds, we still shut down with the fatal `SystemClockMovedBack` exception. Co-authored-by: Thomas Winant <thomas@well-typed.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
BlockchainTimedoes not allow the time to go back one slot or more because of system clock changes (e.g., NTP sync). In the Byron era, slots were 20s, so this hardly every happened. Now, in the Shelley era, slots are 1s, and the clock going back one second or more because of an NTP sync is much more likely. Shutting down the node with aSystemClockMovedBackexception in such cases is rather drastic.We should allow the clock to roll back up to some configurable number of seconds without throwing a fatal exception. When the rollback is within the configured maximum, we should trace a warning but leave the slot unchanged. When the rollback is more than the configured maximum, we will still throw the fatal
SystemClockMovedBack. This is important, because if time moved too far back, we'd have to move blocks from the ImmutableDB to the VolatileDB.The text was updated successfully, but these errors were encountered: