Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #25716

Closed (moved)
Open
Opened Apr 05, 2018 by Roger Dingledine@arma

Arrange an experiment on the test network where we dump create cells on a relay and time the responses

In #25347 (moved) I asked: "Do we have any reason to believe that the calculation in have_room_for_onionskin() is at all accurate? That is, are we sometimes sending this response when there are only 0.25 seconds worth of create cells in our queue? Or are we sometimes not sending them even though there are 5 seconds of cells queued?"

We have a test network, with real relays on it.

We should arrange an experiment where we fill a relay with various levels of create cell load, and keep track of response times and response codes. For one, that will help us tune the calculation that have_room_for_onionskin() makes. For two, it will help us with a new level of testing that we don't get from our unit tests.

Ideally we should arrange the experiment so it is easy to repeat, and then we can run it periodically (as a regression test) without too much additional effort. And e.g. run it with the relay using various values of NumCPUs.

In particular, I am interested to discover if we waste a lot of time in the "glue" stages of the cpuworker where we could be more efficient about queueing work items well but we're not. And, as we get better with modularization, we should be able to see an improvement here.

See #7291 (moved) for where this timing estimation thing first came in.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#25716