* Libertas liber...@mykolab.com [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
On 2015-01-01, Miod Vallat m...@online.fr 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
On 2014-12-31, Libertas liber...@mykolab.com wrote:
One possible explanation is that its randomness store gets exhausted.
OpenBSD's RNG subsystem doesn't get exhausted like this.
teor teor2...@gmail.com 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
Libertas liber...@mykolab.com 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
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
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 code for
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
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% less traffic than would be
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
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 OpenSSL
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
On 1 Jan 2015, at 07:39 , Greg Troxel g...@lexort.com wrote:
Libertas liber...@mykolab.com 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,
14 matches
Mail list logo
