[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Aug 2013 02:46:00 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: *pcount type should be uint64_t
On Fri, Aug 23, 2013 at 1:33 AM, Solar Designer <solar@...nwall.com> wrote:
> I second magnum's comments on this. 2G+ keys per call sounds excessive
> for current GPUs, in terms of kernel invocation duration. Perhaps it's
> a side-effect of how you're doing things, and you need to avoid that?
>
> You may calculate how large *pcount would be, and if it'd exceed a
> certain threshold (which you'd keep below 2G), then reduce the portion
> of mask processed on GPU until the would be *pcount value is sane.
>
For raw-md5 kernel, kernel run time is around 700ms for 7970 with 2.8G keys
per crypt. For raw-sha1 kernel, run time is 2.5s with 5.5G keys per crypt,
but this config seems to give most optimal performance. For md5 kernel c/s
report seems to be correct but for raw-sha1 it is incorrect. Maybe no
information is lost in case of 2.8G (< 2^32) keys but some bits are lost
in case of 5.5G(> 2^32) keys.
Since raw-sha1 kernel kernel run time seems bit high , I will reduce kpc
for raw-sha1, which should give correct c/s output.
For other hashes especially raw-md4 I think we might be able to limit
run-time to less than 1s even with 4G+ keys. So we are pretty much on the
edge of 32bit limit for current generation GPUs. Maybe the change would be
required for next or next to next generation of GPUs.
Regards,
Sayantan
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.
