On Thu, Nov 24, 2011 at 8:51 AM, Moritz Bartl wrote:
>...
> opcontrol --dump && opreport -l
> http://axigy1.torservers.net/opdump.txt
the latter looks more like what i expected:
samples % symbol name
930011 12.9268 bn_mul_mont
831935 11.5636 sha1_block_data_order
4705106.53
Hmm. On examination it looks like there might be some uses of
OpenSSL's AES_encrypt function left around in your profile. Try
changing the beginning of Tor's aes.c so that the line that now says:
Curious whether you had a chance to try this. From the latest
profile, your biggest timesink is
On Nov 20, 2011 8:47 AM, "Watson Ladd" wrote:
>
> So why doesn't aes.c use the same thing as is initialized in crypto.c?
Because, according to our benchmarks, on systems *without* aesni or
other hardware acceleration, using the AES_* functions is actually
faster than the EVP_* ones. (By about 5%.
So why doesn't aes.c use the same thing as is initialized in crypto.c?
It would seem that this is always the right thing to do, and that
because we don't do it acceleration only works for some uses of AES.
The fix seems to be to change aes.c's use of defines to match that in
crypto.c.
Sincerely,
Wa
On Tue, Nov 8, 2011 at 10:29 AM, Nick Mathewson wrote:
> Hmm. On examination it looks like there might be some uses of
> OpenSSL's AES_encrypt function left around in your profile. Try
> changing the beginning of Tor's aes.c so that the line that now says:
>
> #undef USE_OPENSSL_EVP
>
> now say
On Sat, Nov 19, 2011 at 12:22 PM, Watson Ladd wrote:
> I'm a bit confused: I see a lot of time in
> assign_onionskin_to_cpuworker and I don't see looking in the
> code why this should take long.
Hm. This is weird enough that I'm not sure how I trust these results.
There's nothing in assign_onio
I'm a bit confused: I see a lot of time in
assign_onionskin_to_cpuworker and I don't see looking in the
code why this should take long. I'm also not seeing lots of time in
onion_skin_server handshake, which is apparently a big slow point that
had to be put in its own thread for responsiveness. The
On 11/18/2011 10:44 PM, coderman wrote:
hi Moritz, were you able to gather updated stats now that additional
flags are present?
i am very curious about the performance profiles you've observed; they
are unusual :)
The stats (opdump/opreport/vnstat/dstat) are still being generated and
public. I
0. the HiFN DS 100, DS 250, and DS 255 only do symmetric that i can see.
1. http://shader.kaist.edu/sslshader/
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
On Mon, Nov 7, 2011 at 10:28 PM, Jacob Appelbaum wrote:
> ...
> What chips do you suggest for this? I was thinking of buying a new
> machine and I think it might be nice to put up a wiki page. I know that
> I have one of those HiFn cards and it worked as well as was expected.
my understanding is
On Wed, Nov 9, 2011 at 6:12 AM, Moritz Bartl wrote:
> ...
> Bandwidth seems to have stagnated at ~215 Mbps for now. Not sure why, but I
> would guess it will improve when the nodes get Guard and Stable flags.
> http://axigy1.torservers.net/vnstat.png
hi Moritz, were you able to gather updated sta
On 09.11.2011 05:47, coderman wrote:
Looking at those profiles, I'm not seeing zlib dominating anything,
and the public key functions seem to score pretty low too. What am I
missing there? This isn't what I'm used to running into in other
profiles.
apologies, this is a general statement of my
On Tue, Nov 8, 2011 at 7:32 AM, Nick Mathewson wrote:
> ...
>> public key operations and zlib still dominate processing.
>
> Looking at those profiles, I'm not seeing zlib dominating anything,
> and the public key functions seem to score pretty low too. What am I
> missing there? This isn't what
On Tue, Nov 8, 2011 at 10:29 AM, Nick Mathewson wrote:
> Hmm. On examination it looks like there might be some uses of
> OpenSSL's AES_encrypt function left around in your profile. Try
> changing the beginning of Tor's aes.c so that the line that now says:
>
> #undef USE_OPENSSL_EVP
>
> now say
On 11/08/2011 12:28 AM, Jacob Appelbaum wrote:
On 11/07/2011 09:29 PM, coderman wrote:
On Sun, Nov 6, 2011 at 5:57 PM, Moritz Bartl wrote:
...
[notice] Using OpenSSL engine Intel AES-NI engine [aesni] for AES
however, you
are getting not only 3x-10x+ performance improvement in AES ops, but
al
On Tue, Nov 8, 2011 at 12:29 AM, coderman wrote:
[...]
> public key operations and zlib still dominate processing.
Looking at those profiles, I'm not seeing zlib dominating anything,
and the public key functions seem to score pretty low too. What am I
missing there? This isn't what I'm used to
On Sun, Nov 6, 2011 at 8:57 PM, Moritz Bartl wrote:
> Hi,
>
> Thanks to a new deal at www.axigy.com (Thanks! They're great!), we now
> have a shiny dedicated Gbit/s exit with a Sandy Bridge CPU (Quad Xeon
> E3-1230). Details on the setup steps I performed to enable AES-NI are
> documented at
> htt
On 11/07/2011 09:29 PM, coderman wrote:
> On Sun, Nov 6, 2011 at 5:57 PM, Moritz Bartl wrote:
>> ...
>> [notice] Using OpenSSL engine Intel AES-NI engine [aesni] for AES
>>
>> So my guess is that it is now being used, but I must say I would have
>> expected larger profit.
>
> this notice does ind
On Sun, Nov 6, 2011 at 5:57 PM, Moritz Bartl wrote:
> ...
> [notice] Using OpenSSL engine Intel AES-NI engine [aesni] for AES
>
> So my guess is that it is now being used, but I must say I would have
> expected larger profit.
this notice does indicate you are successfully using the dynamic aes-ni
On Sun, Nov 6, 2011 at 7:57 PM, Moritz Bartl wrote:
> Hi,
>
> Thanks to a new deal at www.axigy.com (Thanks! They're great!), we now
> have a shiny dedicated Gbit/s exit with a Sandy Bridge CPU (Quad Xeon
> E3-1230). Details on the setup steps I performed to enable AES-NI are
> documented at
> htt
Hi,
Thanks to a new deal at www.axigy.com (Thanks! They're great!), we now
have a shiny dedicated Gbit/s exit with a Sandy Bridge CPU (Quad Xeon
E3-1230). Details on the setup steps I performed to enable AES-NI are
documented at
https://www.torservers.net/wiki/setup/server#aes-ni_crypto_accelerati
21 matches
Mail list logo
