ETA on long running slow -single mode seems pretty worthless

[jfoug]

Not sure if this is something easy to fix, but it is less than worthless.

[magnumripper]

It's a core problem so maybe we should just bring it to john-users? Solar seems to have a lot of energy for Good Stuff right now.

[jfoug]

Good point (on both cases, lol)

[jfoug]

john-users or john-dev? Users 'may' not be right place, but it is possible that exposing a bug at a higher level like that might help spur solar into getting it working (or dropping it totally.

[magnumripper]

I think john-users, or he will complain :)

[jfoug]

lol. I already got my hand slapped yesterday

[solardiz]

There was no context in this issue, so adding it from https://www.openwall.com/lists/john-users/2015/08/26/2:

Date: Wed, 26 Aug 2015 05:33:24 +0300
From: Solar Designer <[email protected]>
To: [email protected]
Subject: Re: The ETA for -single is somewhat useless

On Tue, Aug 25, 2015 at 01:30:58PM -0500, JimF wrote:
> At least for slower hashes, with a large working set and or few rules.
> The ETA simply does not show up, and when it does, it is at 50% or 75%,
> etc and stays there for a LONG time.  I am not sure how easy getting this
> working properly would be, but as it stands, it has no useful value.
> 
> This is not a bug we can simply fix in jumbo. It is a john-proper issue.

This problem is only that bad when you have unusually few rules.  With
the default ruleset, the reported percentage of work done usually grows
in 1% steps.

Also, it's not just a reporting issue: this granularity coincides with
how much work will be redone if you interrupt and restore.

In fact, this is very similar to what happens in other cracking modes
when you use GPUs or high OpenMP thread counts with very slow formats
with many different salts.  With a short wordlist, you might get e.g.
50% or even DONE reported right away, but this only means that many of
the candidate passwords have been buffered and are yet to be tested
against all salts (have only been tested against some of the salts by
the time this status appears).

An enhancement for status reporting for such cases would be to consider
the percentage of salts processed for the current bunch of candidate
passwords.  However, this wouldn't address the issue of work redone on
interrupt/restore.  In fact, for those of us familiar with the issue and
the current way of reporting, this change would prevent us from easily
predicting how much work would be redone if we interrupt and restore -
and predicting this is sometimes useful for decision-making.  Maybe the
expected percentage of work to be redone on interrupt and restore needs
to be calculated and reported separately, then.

We now have #5378 for "consider the percentage of salts processed for the current bunch of candidate passwords."

Closing this one.