Date: Tue, 2 Jul 2013 16:54:05 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: bug: wrong ETA in incremental mode On 2 Jul, 2013, at 15:38 , magnum <john.magnum@...hmail.com> wrote: > On 2 Jul, 2013, at 13:09 , Solar Designer <solar@...nwall.com> wrote: >> With bleeding-jumbo, I get this: >> >> $ ./john pw --format=Raw-SHA256-opencl -pla=1 >> Device 1: Tahiti (AMD Radeon HD 7900 Series) >> Local worksize (LWS) 64, global worksize (GWS) 4194304 >> Loaded 1 password hash (Raw-SHA256-opencl [SHA256 OpenCL (inefficient, development use mostly)]) >> Press 'q' or Ctrl-C to abort, almost any other key for status >> 0g 0:00:00:23 3/3 (ETA: 15:03:51) 0g/s 18827Kp/s 18827Kc/s 18827KC/s jc099685..jp2fu9 >> 0g 0:00:00:32 3/3 (ETA: 15:08:51) 0g/s 22931Kp/s 22931Kc/s 22931KC/s nbhohn7..seci2fea >> [...] >> 0g 0:00:15:50 3/3 (ETA: 23:38:51) 0g/s 26901Kp/s 26901Kc/s 26901KC/s vln0182..v12b&ff >> 0g 0:00:16:35 3/3 (ETA: 00:03:51) 0g/s 26957Kp/s 26957Kc/s 26957KC/s 04782m4rm..0352l200% >> >> Is it trying to say that it's going to complete within a day? That's >> unrealistic. This run is not supposed to complete at all, unless the >> password gets cracked. > > So the percentage is muted but not the ETA, I've never seen that. Perhaps specific to batch-mode? I'll have a look. Oh, I am seasoned: It was indeed specific to batch mode - the 3/3 was read as 3% done. In unstable, the batch mode indicator is shown as (3) which was handled correctly because it doesn't start with a figure. So this was introduced with the 1.8 core merge (my bad - I'm not *that* seasoned :-) > I also had the idea to change Incremental's get_progress() to use status.cands instead of the naive Jumbo-specific "try" counter. This should theoretically increase performance although I recall I did not see the expected slight drop when I implemented it. Actually if status.cands is usable you don't really have any reason not to implement it in core too. I did this now too. Much cleaner and restoring is handled by core code instead of the Jumbo hack. Like I feared it actually resulted in a slight performance drop... but I will ignore that - dropping a memory variable that is incremented at *every* call to crk_process_key() just has to be a good thing. 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.