Plus is too slow. How can I continue to use oclhashcat ?

[nobody]

Thanks for replying. Yes, I tested.Plus 0.07 is faster than reglar 0.26 if the hash count less than 100.
And I found that plus 0.07 is 10% slower than plus 0.06 while cracking 70000 md5 hashes (oclHashcat-plus64.exe 2.txt -m 0 -o 2.out a.dic -r rule\d3ad0ne_10K.rule )

[atom]

ok i found out what is the real source of the problem. i really had a hard time to find the reason because both, oclHashcat-plus and oclHashcat, share the same multihash binary search routine.

after some tests i wanted to start a trace session. so i had to recompile oclHashcat 0.26 kernels and whoops, the speed dropped (in my example) from ~4000M to ~2800M???

that lowers the possible sources to just one: the AMD SDK. when i released oclHashcat 0.26 the SDK used was 2.3.

so i quickly recompiled new oclHashcat-plus kernels with SDK 2.3 and see there, the speed is much higher than oclHashcat v0.26's.

conclusion: its good to know where it is coming from, but in this case i can not do anything more than hope AMD will put back whatever they do in SDK 2.3 in the next SDK release.

[forumhero]

if i understand this thread correctly the workaround would be one of these two options?

1. split the hash list into mulitple files with less than 100 hash per file and use Plus-0.07
2. change system clock back to 2011 and use Plus-0.06

[atom]

have it already fixed in v0.08

[wibble]

have it already fixed in v0.08

I know atom, but currently that version is not released, and to make v0.06 work you need to backdate your clock, not ideal if you have to keep audit logs for your client. So if some one does not want to, or is unable to put their clock back and does not have access to a beta copy of v0.08, they are left with slower running software than they used to have.

We know you will release it when your happy with it and we appreciate the work you put in for free on the program, just explaining why people are still commenting on this thread.