On 09/01/2010 02:28 PM, John Case wrote:
>
>> Also, afaik, zero people in the wild are actively running Tor with any
>> crypto accelerator. May be a very painful process... I'm not really
>> interested in documenting it unless its proven to scale by actual use.
>> I want this document to end up wi
On Wed, Sep 1, 2010 at 2:28 PM, John Case wrote:
>...
> I really do think some subset of that discussion should be included in your
> "lore", at the very least the parts pertaining to the built-in crypto
> acceleration included in recent sparc CPUs, which appear to be the only
> non-painful way to
Also, afaik, zero people in the wild are actively running Tor with any
crypto accelerator. May be a very painful process... I'm not really
interested in documenting it unless its proven to scale by actual use.
I want this document to end up with tested and reproduced results
only. You know, Scie
I should have said this in my first post, but I believe that all
subsequent replies should go to tor-relays. This should be the last
post discussing technical details of relay operation on or-talk.
Thus spake coderman (coder...@gmail.com):
> > net.ipv4.tcp_keepalive_time = 1200
>
> ^- who uses
On Tue, Aug 24, 2010 at 8:27 AM, Mike Perry wrote:
> ...
> # Set the hard limit of open file descriptors really high.
> # Tor will also potentially run out of ports.
> ulimit -SHn 65000
typically in /etc/security/limits.conf. i like to append:
* softnofile 4096
*
After talking to Moritz and Olaf privately and asking them about their
nodes, and after running some experiments with some high capacity
relays, I've begun to realize that running a fast Tor relay is a
pretty black art, with a lot of ad-hoc practice. Only a few people
know how to do it, and if you
6 matches
Mail list logo