* Libertas [2015-01-02 06:25]:
> I've tuned PF parameters in the past, but it doesn't seem to be the
> issue. My current pfctl and netstat -m outputs suggest that there are
> more than enough available resources and no reported failures.
just a sidenote, it is safe to bump the default state limit
teor writes:
> Tor 0.2.6.2-alpha (just in the process of being released) has some
> changes to queuing behaviour using the KIST algorithm.
>
> The KIST algorithm keeps the queues inside tor, and makes
> prioritisation decisions from there, rather than writing as much as
> possible to the OS TCP q
On 2015-01-01, Miod Vallat wrote:
>> > I should have also specified that I didn't just go ahead and enable them
>> > because I wasn't sure if they're considered safe. I like abiding by
>> > OpenBSD's crypto best practices when possible.
>> >
>> > Is there any reason why they're disabled by defaul
I've tuned PF parameters in the past, but it doesn't seem to be the
issue. My current pfctl and netstat -m outputs suggest that there are
more than enough available resources and no reported failures.
I remember someone on tor-...@list.nycbug.org suggesting that it could
be at least partially due
On 2014-12-31 11:21, Libertas wrote:
For those not familiar, a Tor relay will eventually have an open TCP
connection for each of the other >6,000 active relays, and (if it allows
exit traffic) must make outside TCP connections for the user's requests,
so it's pretty file-hungry and crypto-intensi
> > I should have also specified that I didn't just go ahead and enable them
> > because I wasn't sure if they're considered safe. I like abiding by
> > OpenBSD's crypto best practices when possible.
> >
> > Is there any reason why they're disabled by default?
>
> Compiler bugs generate incorrect
Libertas writes:
> Some of the people at tor-...@lists.nycbug.org and I are trying to
> figure out why Tor relays under-perform when running on OpenBSD. Many
> such relays aren't even close to being network-bound,
> file-descriptor-bound, memory-bound, or CPU-bound, but relay at least
> 33-50% le
On Wed, Dec 31, 2014 at 19:42, Libertas wrote:
> Thanks for this!
>
> I should have also specified that I didn't just go ahead and enable them
> because I wasn't sure if they're considered safe. I like abiding by
> OpenBSD's crypto best practices when possible.
>
> Is there any reason why they're
On 1 Jan 2015, at 07:39 , Greg Troxel wrote:
> Libertas writes:
>
>> Some of the people at tor-...@lists.nycbug.org and I are trying to
>> figure out why Tor relays under-perform when running on OpenBSD. Many
>> such relays aren't even close to being network-bound,
>> file-descriptor-bound, memo
Thanks for this!
I should have also specified that I didn't just go ahead and enable them
because I wasn't sure if they're considered safe. I like abiding by
OpenBSD's crypto best practices when possible.
Is there any reason why they're disabled by default?
On another note, I was skeptical about
On Thu, 1 Jan 2015, at 11:49 AM, Libertas wrote:
> I also completely forgot to mention the below warning, which Tor
> 0.2.5.10 (the current release) gives when run on OpenBSD 5.6-stable
> amd64:
>
> > We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later,
> > but with a version of Open
I also completely forgot to mention the below warning, which Tor
0.2.5.10 (the current release) gives when run on OpenBSD 5.6-stable amd64:
> We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later,
> but with a version of OpenSSL that apparently lacks accelerated
> support for the NIST
12 matches
Mail list logo
