Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jan 2016 08:18:56 +0100
From: magnum <>
Subject: Re: meaning of p/s, c/s and C/s

On 2016-01-11 06:48, Patrick Proniewski wrote:
> On 11 janv. 2016, at 00:12, Marek Wrzosek wrote:
>>> but eventually, it would not end:
>>> 1 0g 0:00:39:30 N/A 0g/s 937.9p/s 3839Kc/s 29456KC/s 0Euj..3Guj
>>> 2 0g 0:00:39:30 N/A 0g/s 929.0p/s 3803Kc/s 29177KC/s maUy..pcUy
>>> 3 0g 0:00:39:30 N/A 0g/s 932.2p/s 3816Kc/s 29278KC/s a8qO..darO
>>> 4 0g 0:00:39:30 N/A 0g/s 937.8p/s 3839Kc/s 29455KC/s WCZ3..ZEZ3
>> I think, the percentage and ETA values are just estimated. However if
>> percentage is close to 100% or ETA expires, then jtr could show N/A.
>> Similarly when it is close to 0% and ETA is far in the future, jtr will
>> show N/A, too. Cracking process should end eventually. How long did you
>> wait?
> I've waited 51 minutes, then ended the process. After a quick calculation, I realized it should have taken about 1h and few minutes to complete the 4 character space at 4*940 p/s, but it's no big deal. I'm just very surprised the ETA can be so wrong on a short session. May be it's too short to get the opportunity to adjust, as I've seen in previous multi-day sessions.

I'm pretty sure we have a bug in mask mode ETA calculation but I've yet 
to nail it. There are so many combinations: node/fork, resume, hybrid, 
GPU-side mask and so on. In most cases, ETA is correct but sometimes I 
notice it gets screwed up.

In this case, you used fork and pure mask. Maybe we should have a closer 
look at that. There were incorrect bug fixes in the past, that fixed 
something but broke something else. Those fixes were reverted but the 
original problem may still be present.


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.