Opened 5 years ago

Closed 4 years ago

#13274 closed defect (wontfix)

mean uptime (monthly) versus mean uptime (weekly) -one has too big rounding errors

Reported by: toralf Owned by: isis
Priority: Low Milestone:
Component: Metrics/Globe Version:
Severity: Normal Keywords:
Cc: starlight@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

for a newly established relay - just 12 days old - with 2 outages during that time I'm wondering why the monthly value (~95%) is bigger than the value calculated over the last week (~92%)

https://globe.torproject.org/#/relay/F1BE15429B3CE696D6807F4D4A58B1BFEC45C822

Child Tickets

Change History (5)

comment:1 Changed 5 years ago by karsten

Yup, this is a bug in Globe. When it calculates mean uptime it doesn't distinguish between 0 ("node is down") and null ("no data about uptime or downtime"). Here's what Onionoo returns for this relay's uptime in the past week:

"first": "2014-09-22 09:30:00",
"last": "2014-09-29 09:30:00",
"interval": 3600,
"factor": 0.001001001001001001,
"count": 169,
"values": [
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, null, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, null, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999,
    999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999, 999
]

Globe tells me mean uptime is 98.82%. That's 167 times value 999 times factor 0.001001001001001001 divided by 169 values.

What it should calculate is 167 times value 999 times factor 0.001001001001001001 divided by 167 values, which is 100%.

By the way, there's a related bug in the graphs which shouldn't drop to zero in case of null values but which should stop drawing the line and resume drawing at the next non-null value.

comment:2 Changed 5 years ago by isis

Owner: changed from rndm to isis
Status: newassigned

Changing Globe tickets to be owned by isis.

comment:3 Changed 5 years ago by isis

Status: assignednew

comment:4 Changed 4 years ago by starlight

Cc: starlight@… added

Another example:

BabylonNetwork06 22F9FB518CE880081B3101B70B9D85D5BD4D7967

cumulative 50 down hours in last 30 days, one-month
up-time show as 93.31% where it actually is 93.06%

The 0.25% error is large enough to cause one to beleive
that the Guard flag will return several days before
it actually will.

A nice enhancement would be to show an accurate
rendering of the dir-auth calculation of weighted
up-time alongside the unweighted value so one can
better see how far away from receiving the Guard
and Stable flags a particular relay is.

comment:5 Changed 4 years ago by karsten

Resolution: wontfix
Severity: Normal
Status: newclosed

We're about to retire Globe, and this issue is only specific to Globe and not to Atlas. Closing as won't fix.

Note: See TracTickets for help on using tickets.