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.