Opened 4 years ago

Closed 4 years ago

#16675 closed defect (fixed)

BWauth longclaw outlier

Reported by: starlight Owned by: aagbsn
Priority: Medium Milestone:
Component: Core Tor/Torflow Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This ticket is somewhat vague due to my lack of
familiarity with the inner workings of TorFlow
and lack of access to a the system in question
It consists of an observed artifact that
may be attributable to one of the more
specific issues. Please feel free to close
it out and/or note where it might belong.

For the last two weeks BWauths have been
generating measurements with apparently
improved rationality. Not sure what
change caused that but it's a very welcome
development.

On July 22 'longclaw' stopped updating
bandwidth measurements for four days,
but was restored about a day ago and
is now working.

'longclaw' has, in the last few hours,
produced an large outlier observation
for a Verizon FiOS relay relative to
a group of similar relays. Understanding
the cause may help further improve the
state of TorFlow.

The following relays all operate on
fast symmetrical FiOS connections in the
North Eastern US. Since the improved
behavior appeared, these relays generally
are measured with increasing bandwidth
in the order

longclaw
gabelmoo
maatuska
moria1

First a close-match and typical observation
as of 17:00 GMT 2015-07-27:

Binnacle
longclaw Bandwidth=8055 Measured=5350
gabelmoo Bandwidth=8055 Measured=8830
maatuska Bandwidth=8055 Measured=9370
moria1   Bandwidth=8055 Measured=21500

Now for the outlier, a relay very
similar to the above though it
appears to have 30% more bandwidth
available to the relay:

EmbraceTheChaos
longclaw Bandwidth=6986 Measured=33700
gabelmoo Bandwidth=6986 Measured=9090
maatuska Bandwidth=6986 Measured=9710
moria1   Bandwidth=6986 Measured=48200

The above measure appeared abruptly in
2015-07-27-09-00-00-vote-23D . . .
and in the prior vote was the more
rational, consistent and typical

Bandwidth=6986 Measured=4710

=====

Additional similar relays:

ZzZzZz
longclaw Bandwidth=6270 Measured=2530
gabelmoo Bandwidth=6270 Measured=5530
maatuska Bandwidth=6270 Measured=6420
moria1   Bandwidth=6270 Measured=16600

AGoodFellow
longclaw Bandwidth=4082 Measured=2620
gabelmoo Bandwidth=4082 Measured=4950
maatuska Bandwidth=4082 Measured=8730
moria1   Bandwidth=4082 Measured=9740

UrbanRelayUT
longclaw Bandwidth=3145 Measured=2540
gabelmoo Bandwidth=3145 Measured=2880
maatuska Bandwidth=3145 Measured=6740
moria1   Bandwidth=3145 Measured=5380

JumpPoint
longclaw Bandwidth=2777 Measured=2470
gabelmoo Bandwidth=2777 Measured=2800
maatuska Bandwidth=2777 Measured=4440
moria1   Bandwidth=2777 Measured=5340

12xBTM1
longclaw Bandwidth=2037 Measured=1020
gabelmoo Bandwidth=2037 Measured=2220
maatuska Bandwidth=2037 Measured=1860
moria1   Bandwidth=2037 Measured=3030

The though behind this ticket is it
may be worth analyzing specific examples
of apparently unsensible measurments
made by TorFlow. Due to the homogenous
and generally high-quality nature of
the Verizon FiOS network this is a
reasonable data point.

Child Tickets

Change History (2)

comment:1 Changed 4 years ago by starlight

It appears this outlier relates to 'longclaw' going back into some kind of broken state.

Per #16667 more than half of the relay measurements have not updated for 40 hours.

The outlier arrived at the precise beginning of the outage.

comment:2 Changed 4 years ago by starlight

Resolution: fixed
Status: newclosed

Found out that 'longclaw' was running out-of-date
TorFlow missing a good number of fixes
and the other BWauths are on the new version.

This explains the outlier and 'longclaw' is
receiving the update, so this ticket is closed
as fixed.

Note: See TracTickets for help on using tickets.