Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Mar 2013 11:14:06 -0300
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Idea to increase plaintext length for GPU based hashes

Em 19-03-2013 17:27, magnum escreveu:
> On 19 Mar, 2013, at 16:16 , Claudio André <claudioandre.br@...il.com> wrote:
>> Em 18-03-2013 22:21, magnum escreveu:
>>> Another approach (not necessarily mutex to yours) would be to split the transfer. Let's say we have a work size of 1M. At, say, the 256K'th call to set_key(), it could initiate a transfer of this first fourth of keys to GPU. This transfer will not stall the host side, it will take place while we continue with the next 256K keys. And so on. If we can balance this properly we should get rid of much of the transfer delay. Maybe we should split it in 8 or 16, maybe less.
>> Well, it is easy to (somehow) implement your idea. Good gain.
>> Raw:    13653K c/s real, 47953K c/s virtual
>> Raw:    17096K c/s real, 36408K c/s virtual
> I hoped for a lot more :-(
>
>> But, this not enought to do the trick. Below, I measure only the GPU part in auto-tune. I expect to be at 113M not 17M.
>> Is it only set_key() to blame? Btw: auto-tune on unstable goes at 19M.
> I tried the same on ntlmv2-opencl with various split sizes but there was no gain at all.
>
> Regarding set_key() bottleneck:
>
> magnum@...l:src [bleeding-jumbo]$ ../run/john -t -fo:lm
> Benchmarking: LM DES [128/128 BS XOP-16]... DONE
> Raw:    60458K c/s real, 60458K c/s virtual
>
> ...if we can get 60M c/s using one CPU core, we should beat that figure for any raw GPU format if we can hide transfer latency. We need some real profiling.
>
> magnum

My guess is that we are close to hardware limits in 'efficiency'. At 
6770, AMD SDK tool reports 0.85 GB/s. It is what we are getting on JtR 
(with recent ideas).

Analysis attached.





View attachment "veja" of type "text/plain" (3287 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ