Opened 11 years ago

Last modified 3 years ago

#1116 new defect (None)

'Stable' flag assignment inconsistant

Reported by: StrangeCharm Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-dirauth mtbf data-export
Cc: nickm, karsten, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

Looking at a consensus document [though I used for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.

According to the v3 directory specification at ,
routers with a weighted MTBF more than either the median or seven days should be marked stable, and MTBF data more
than a month old shouldn't be that relevant when assigning the flag. Since the median uptime is about 3 days, one should
roughly expect that any router with more than 30 days of uptime (and which are still valid) should have the stable flag.
However when relays are sorted in order of uptime, several apparently-longrunning routers do not have the flag.

Since this data is liable to change as relays go up an down, here are some noted not-'stable' routers at the time of
writing. The routers have uptimes more than a month, so their (correctly) weighted MTBF should certainly be more than
a week, and more than the median, about three days.

wie6ud6be - 148d
anonymde - 112d
torpfaffenederorg - 110d
rentalsponge - 70d
xhyG5r96QGlRqL - 57d
niugnip - 56d
oeiwuqej - 49d
gremlin - 42d
editingconfigishard - 39d

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (7)

comment:1 Changed 11 years ago by nickm

Okay, so either we're calculating MTBF wrong, or we're using it wrong when we compute our votes, or the MTBF
on these routers is low despite their high uptimes. (A router is supposed to be counted as having "failed"
for MTBF purposes not when it goes down and resets its uptime, but when the authority tries to connect to it
and fails. It is possible for a router to have a high uptime but a low MTBF. I am not sure whether this is
happening here or not.)

It would be cool to see live MTBF data and votes from every authority for a single consensus. Step 1 here is
probably to export MTBF data somehow so we can see how it looks.

comment:2 Changed 10 years ago by nickm

Description: modified (diff)
Milestone: Tor: unspecified

comment:3 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:4 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:5 Changed 3 years ago by nickm

Cc: StrangeCharm,nickm,karsten,SebastianStrangeCharm, nickm, karsten, Sebastian
Keywords: tor-dirauth mtbf data-export added; tor-relay removed
Severity: Normal

comment:6 Changed 3 years ago by merge

I don't have any new idea, but let's update this issue:

Among the relays with 90+ days uptime, I see around 15 relays without the stable flag. Of course they have outdated tor versions, but nevertheless the stable flag doesn't seem to be as reliable as can be. A few examples:

0F12 5FE6 14BF 3E5D 3910 1F7A 9C78 F5B3 74EB 0FF9
DD6F 0796 240C 03E6 1BAC 87B0 B384 E675 25C7 E3D0
CD1C 81E4 B0C9 2BE9 2A73 5DE2 FC60 9DF6 48D7 9152
9092 050F 63BE B196 12EC ED2E 98FE A066 447E 2207
A5A7 38F0 45ED DE9A 7EB9 4A44 7ECB 5F53 FD41 6452
1380 0C84 2784 3491 3889 80FF 9991 7180 7BB7 E737
79DE B4E0 2FD0 8AE1 AEB4 D859 4AAB 0823 75E9 062D
A5E3 D05A 4F44 A915 C429 BF71 2334 A4E2 8E46 A10C
23C1 585A 1214 D4BB 0945 8829 72BE EC1A 025C B36A
EB41 A0C0 1EEC D85A A692 ADC6 60B9 1B5D 5B85 48A3
4DDF E360 220A 80F2 0A30 7152 186B 87B5 9D88 3536
242E 1E2E A7C4 1310 AD87 5935 6070 0BBC 2F9F 790B

what they seem to have in common is quite varying traffic over time, or being very slow.

comment:7 Changed 3 years ago by StrangeCharm

Cc: StrangeCharm removed
Note: See TracTickets for help on using tickets.