[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E5001317-68EE-497D-ACFF-E70656A531F2@gmail.com>
Date: Thu, 25 May 2017 07:49:00 -0700
From: B B <dustythepath@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: CL_OUT_OF_RESOURCES error with --format=dmg-opencl
Magnum,
I have been experiencing some errors on startup, and also a decrease in p/s. Also I can no longer specify GWS on the command line as this causes an error also. Without declaring GWS I seem to have to wait out or make multiple attempts before the process proceeds without error.
Here are the errors:
OpenCL CL_OUT_OF_RESOURCES error in common-opencl.c:1515 - WaitForEvents failed—this happens with or without specifying GWS
OpenCL CL_OUT_OF_RESOURCES error in common-opencl.c:1820 - Error creating command queue— seems to happen randomly
I tried using GWS to get back the performance I had before the changes, which decreased by almost a third from 728 to 500.
The specifying of a GWS number worked well previously.
I figured that you would like to know about these errors regardless.
Thanks for your work!
Let me know if this should be/have been posted to GitHub
Bill
--
> On May 10, 2017, at 3:23 PM, magnum <john.magnum@...hmail.com> wrote:
>
> On 2017-05-11 00:11, B B wrote:
>> On May 10, 2017, at 1:32 PM, magnum <john.magnum@...hmail.com <mailto:john.magnum@...hmail.com>> wrote:
>>> A part of the problem is likely that your hash has a lot higher number of iterations than what is auto-tuned for and you get bitten by the kernel duration watchdog. We should definitely auto-tune for actual loaded hashes, not test vectors - but that's not implemented yet for this format.
>>>
>>> Try running for a while with really low GWS just to see if it evades the error:
>>>
>>> GWS=1024 ./john —inc=custom —format=dmg-opencl hashfile —mask=?w?d??d?dknownword
>>>
>>> If 1024 doesn't work, halve it until it does.
>>> If 1024 works fine, try doubling it until best speed with no error (or until no speedup from doubling). Note that it's fine to stop a session with some GWS and resume it with some other, ie.
>>>
>>> GWS=64 ./john —inc=custom —format=dmg-opencl hashfile —mask=?w?d??d?dknownword
>>> ...
>>> <job stopped>
>>> ...
>>> GWS=128 ./john -restore
>>
>> Success!
>>
>> I tried GWS=1024, then went to 4096. At 4096 my p/s increased 5 fold up to 715p/s from 128p/s.
>>
>> Thats very impressive
>>
>> For the heck of it, since we were declaring only GWS instead of LWS and GWS, I tried GWS=8192 and replicated the error. I suppose I could pump it up a little more or try half again but will probably leave it at 4096 and watch for your eventual updates in GitHub for this particular issue. My latest ETA has moved from late June to 9 days out.
>> My desktop IS very slow now. So I may incrementally lower the single kernel invocation as stated in the README, however the performance increase is quite nice, thank you.
>>
>> 10 years of data might be worth a second video card ;)
>>
>> Thanks magnum
> Cool, I'm glad it was that easy. Watch https://github.com/magnumripper/JohnTheRipper/issues/2538 for updates.
>
> magnum
>
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.
