Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Tor
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
orbea
Tor
Commits
f15df2d8
Commit
f15df2d8
authored
17 years ago
by
Nick Mathewson
Browse files
Options
Downloads
Patches
Plain Diff
r13437@catbus: nickm | 2007-06-15 14:29:56 -0400
Incorporate comments [from april, ugh] into proposal 108. svn:r10636
parent
5d68fc10
Branches
Branches containing commit
Tags
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/spec/proposals/108-mtbf-based-stability.txt
+27
-4
27 additions, 4 deletions
doc/spec/proposals/108-mtbf-based-stability.txt
with
27 additions
and
4 deletions
doc/spec/proposals/108-mtbf-based-stability.txt
+
27
−
4
View file @
f15df2d8
...
...
@@ -46,12 +46,24 @@ Issues:
Alternative:
"A router's Stability shall be defined as the sum of $alpha ^ d$ for every
"A router's Stability shall be defined as the sum of $
\
alpha ^ d$ for every
$d$ such that the router was not observed to be unavailable $d$ days ago."
This allows a simpler implementation: every day, we multiply yesterday's
Stability by alpha, and if the router was running for all of today, we add
1.
This allows a simpler implementation: every day, we multiply
yesterday's Stability by alpha, and if the router was observed to be
available every time we looked today, we add 1.
Instead of "day", we could pick an arbitrary time unit. We should
pick alpha to be high enough that long-term stability counts, but low
enough that the distant past is eventually forgotten. Something
between .8 and .95 seems right.
(By requiring that routers be up for an entire day to get their
stability increased, instead of counting fractions of a day, we
capture the notion that stability is more like "probability of being
staying up for the next hour" than it is like "probability of being
up at some randomly chosen time over the next hour." The former
notion of stability is far more relevant for long-lived circuits.)
Limitations:
...
...
@@ -59,3 +71,14 @@ Limitations:
tell whether a router is up or down. So long as these aren't terribly
wrong, and so long as they aren't significantly biased, we should be able
to use them to estimate stability pretty well.
Probing approaches like the above could miss short incidents of
downtime. If we use the router's declared uptime, we could detect
these: but doing so would penalize routers who reported their uptime
accurately.
Implementation:
For now, the easiest way to store this information at authorities
would probably be in some kind of periodically flushed flat file.
Later, we could move to Berkeley db or something if we really had to.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment