[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Jul 2013 18:22:51 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
Hi Yaniv,
I'm afraid I'll need your help on this one.
I implemented your suggestion to have "server" on core. The problem is that
in some cases not all cores return correct result. In tests I've done so
far, max 3 cores returned incorrect result. Those are usually with id 0x8c*
and less often with 0x88*. What I can't figure out is why those cores
return wrong result when all cores are loaded with same code and in code
that's not integrated with JtR all use same data. Data is transferred
correctly. it can't be hardware problem because those cores sometimes
return correct results (in loop of 12 iterations, there are usually 4-5
iterations in which 1-3 cores return incorrect results). Reading result
from local memory instead from shared memory didn't make any difference. I
also tried to write result to other locations in local memory, didn't
change anything. The only difference I get is when using only 8 cores, than
those incorrect results happen rarely (I got few only when cracking
passwords). Cores communicate with host only and I don't see any
possibility for data race. I tried compiling without optimizations, also
didn't help.
I can't think of anything else that could cause occasional return of
incorrect result.
Code is in /home/kmalvoni/integration/JohnTheRipper/src and non integrated
version is in /home/kmalvoni/e_bcrypt/minimal
Thank you,
Katja
On Sun, Jul 14, 2013 at 11:14 PM, Katja Malvoni <kmalvoni@...il.com> wrote:
> Hello,
>
> I made mentioned changes but at the moment implementation is not reliable,
> sometimes it happens that some of the cores stuck. It passes self test in
> most of the cases, but it can't crack BF_tst.in from JtrTestSuite in one
> run - deadlock happens. If I limit the number of times each core is polled
> than it finishes but that's not reliable because some keys are never tried
> since some cores don't signal done and host skips results from that cores.
> Number of remaining non cracked passwords after first run differs (for last
> two runs it was 31 and 42) and than 3 for the third run (after third run
> all passwords are cracked). Performance also differs, for the first run it
> varies from around 630 c/s to 670 c/s.
> When it passes self test this is performance:
> 822 c/s real, 822 c/s virtual
>
> Tomorrow I'll try to figure out how exactly those cores stall and why it
> happens occasionally.
>
> Best regards,
>
> Katja
>
--
Katja
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
