Fix unclosed link

parent e6ae1cc5
......@@ -100,8 +100,8 @@ elapsed between two different timestamps, or a duration. Converting from a
ratio of `TickDifference` to `TaiDifference`. This ratio represents the
frequency at which `Tick` increases. After this multiplication, the number you
get is the amount of "real time" that has passed since the local clock started
ticking. To get the absolute time, you add it to some starting point, which in
our API is called `get_wall_boot`. We also maintain start times for three other
ticking. To get the absolute time, you add to it an offset which centers the
tick 0 with the TAI epoch. We also maintain start times for three other
particularly notable epochs as `Tick`: when the machine started, when the
process was created, and when the thread was created. These are retrieved with
the `get_start` function.
......@@ -111,12 +111,15 @@ the system into hibernation? At that point in time, the local clock stops
ticking entirely. This would make the `ratio` completely skewed! To handle this,
we introduce the idea of _discontinuities_ into the mix. A discontinuity
represents a period of time where the system clock was stopped for some reason.
Right now, the only reasons we have are `Suspend`, representing that the system
was in some low-power state where the clock couldn't be running, and
`Wraparound`, representing that the system clock overflowed. These are
relatively rare events, but it's important to account for them. If you can think
of other cases, let us know by either tweeting `@cmrx64` or bringing it up in
`#robigalia` on Freenode!
Right now, the only reasons we have are:
- `Suspend`, representing that the system was put in some low-power state where
the clock couldn't be running
- `Wraparound`, representing that the system clock overflowed.
These are relatively rare events, but it's important to account for them. If you
can think of other cases, let us know by either tweeting `@cmrx64` or bringing
it up in `#robigalia` on Freenode!
The last hitch we care about is _clock source changes_. Maybe a particular clock
was found to be unreliable, and was replaced with another. Or maybe a thread was
......@@ -132,8 +135,7 @@ Local relative clocks can be pretty good, losing only a few seconds a week
which, worst case, would correspond to ~1 minute a week). How do we convert that
into an absolute clock? How do we make sure that our internal clock reflects
proper time? The answer is... it's complicated. Time synchronization is worthy
of its own blog post. Once we've implemented it, and I understand it better, I
might write something about it separately.
of its own blog post, but I'll cover the basics here.
Right now, we use http://www.synclab.org/docs/[RADclock]'s algorithm
for this. http://www.synclab.org/pubs/tscclock_2007_GOOGLE_slides.pdf[These
......
......@@ -12,7 +12,7 @@ If you're using `rustup`, run something like:
rustup default nightly-$DATE
The `$DATE` we use for CI can be found https://gitlab.com/robigalia/runner/blob/master/Dockerfile#L33[approximately here.
The `$DATE` we use for CI can be found https://gitlab.com/robigalia/runner/blob/master/Dockerfile#L33[approximately here].
After that, just one last step:
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment