[tor-bugs] #9262 [Tor]: Refactor cell scheduling to consider all connections at once

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Jul 18 18:29:10 UTC 2013


#9262: Refactor cell scheduling to consider all connections at once
----------------------------------------------+-----------------------------
 Reporter:  nickm                             |          Owner:  andrea            
     Type:  enhancement                       |         Status:  assigned          
 Priority:  major                             |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor                               |        Version:                    
 Keywords:  tor-relay circuitmux performance  |         Parent:                    
   Points:                                    |   Actualpoints:                    
----------------------------------------------+-----------------------------
Description changed by robgjansen:

Old description:

> Right now, our cell scheduling works by ensuring that every connection on
> which *any* circuit wants to write has at least one cell buffered for
> writing, and by putting more cells into the connection's write buffer
> every time a write makes it get low.  The circuitmux logic is only used
> to choose which circuit on a given connection should have permission to
> write.
>
> But this approach does a bad job in that it treats all connections
> equally: instead, it should look at all connections _which would like to
> write now_, and decide among them.
>
> Andrea is working on this one.  As I understand it, the approach is to
> decouple the "Put a cell on this connection's output buffer" logic from
> the two things that trigger it: draining the output buffer a little in
> response to a libevent event, and making a circuit active on a connection
> which had no active circuits or buffered cells before.  Instead, the main
> event loop should update a list of connections which would like to have
> cells put on them, and periodically (every X usec, or every time through
> the libevent loop, or something like that) queue cells onto the selected
> connections.
>
> The details above will be a little tricksy.  Andrea, could you explain a
> little more about your approach here?  Alternatively I think I can dig up
> the conversation we had about this stuff, if you're okay with my posting
> it.

New description:

 Right now, our cell scheduling works by ensuring that every connection on
 which *any* circuit wants to write has at least one cell buffered for
 writing, and by putting more cells into the connection's write buffer
 every time a write makes it get low.  The circuitmux logic is only used to
 choose which circuit on a given connection should have permission to
 write.

 But this approach does a bad job in that it treats all connections
 equally: instead, it should look at all connections _which would like to
 write now_, and decide among them.

 Reported by Rob Jansen.

 Andrea is working on this one.  As I understand it, the approach is to
 decouple the "Put a cell on this connection's output buffer" logic from
 the two things that trigger it: draining the output buffer a little in
 response to a libevent event, and making a circuit active on a connection
 which had no active circuits or buffered cells before.  Instead, the main
 event loop should update a list of connections which would like to have
 cells put on them, and periodically (every X usec, or every time through
 the libevent loop, or something like that) queue cells onto the selected
 connections.

 The details above will be a little tricksy.  Andrea, could you explain a
 little more about your approach here?  Alternatively I think I can dig up
 the conversation we had about this stuff, if you're okay with my posting
 it.

--

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9262#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list