Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T torflow
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Network Health
  • torflow
  • Issues
  • #16675
Closed
Open
Created Jul 27, 2015 by starlight@starlight

BWauth longclaw outlier

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.

Assignee
Assign to
Time tracking