On 11/5/14, grarpamp wrote:
> ...
>1 DragonFly
kudos, whoever you are!
(i love this flavor more than most :)
best regards,
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relay
On 1/3/15, usprey wrote:
> Summary:
> The documentation is still somewhat vague on the best use of the
> "HardwareAccel" option.
you could submit a patch ;)
>> *HardwareAccel* *0*|*1*
>>
>> If non-zero, try to use built-in (static) crypto hardware acceleration
>> when available. (Default: 0)
On 5/31/15, Jannis Wiese wrote:
> ...
> At the moment I just see urras missing from the consensus...
i would like to report a missing Tor-DA to the authorities. ;)
best regards,
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists
On 8/21/15, Mike Perry wrote:
> ...
> What I really need now is any examples of common routers that have a
> default inactive/idle timeout below 10s, or allow you to set it below
> 10s. So far I have not found any.
i recall a switch vendor that used overflow condition to trim timeouts
lower, but
On 8/3/15, Yawning Angel wrote:
> ...
> Hm, doesn't running good relays on Windows (especially high capacity
> ones) require that we finish off the IOCP related work?
yes. this makes high performing Windows relays much more difficult in practice.
there are pages written years back in tor-talk, t
On 8/21/15, Mike Perry wrote:
...
>> For those into researching other flow capabilities...
>> There are also some probes in OS kernels and
>> some other opensource taps, they're not as well known
>> or utilized as nProbe.
>> Other large hardware vendors include Brocade, Avaya,
>> Huawei, and Alcat
On 9/2/15, Tim Sammut wrote:
> ...
> - Cisco IOS (and likely other platforms) will immediately export flows
>if the cache fills to capacity. This will result in flows being
>exported in less than inactive timeout,..
there is a second limit here, which is the netflow channel capacity /
st
correct address this time :/
Fwd:
#include
i am not speaking for Tor devs nor Tor project - the cautious should
wait for a review and merge.
On Sat, Dec 14, 2013 at 6:14 AM, coderman wrote:
> this is logged as trac ticket:
> https://trac.torproject.org/projects/tor/ticket
