Wanted feature / option

["Michael_google gmail_Gersten" <keybounce@xxxxxxxxx>]

I finally realized what feature I'd like to see. CircuitMinimumBandwidth.

Have a config option to tell Tor how much CPU time it can expect to
give to processing onions (which will tell it how many active
connections it can handle) (Or tell it directly how many active ones
it can handle).

Tor knows the total bandwidth it has to use.
There's good heuristics for telling how much bandwidth a connection
will need. (Most will need a high initial push, and then occasional,
intermittent spikes; if a connection needs a lot for more than <N>
seconds, it's likely to need a lot for a while longer. Etc.)
There's a way to tell when the CPU limit will prevent any more data
transmission.

Combined, this would allow a node to refuse non-specific node requests
(normal circuits would be blocked if the tor server is busy, but a
".node.exit" would still be allowed).

This would also eliminate any perceived "slowness" of tor -- no longer
would I see 22 MB nodes in my path, yet dialup users could still use
them. If I have a 1300 MB node in my path, I know it can handle my 150
request, and not be either so swamped that I'm only seeing 15, or so
overloaded that it's past it's CPU limit. Equally, I know that I can
tell tor (without having to use "nice") not to steal all my CPU while
I'm using my computer.

Potential problems? What would we do if we could not find a viable
circuit? What if every node is asked and reports "Busy" -- how do we
tell the user that "Tor is full", or should a lowspeed connection be
made anyways?