PlasmaPower / nano-vanity

A NANO vanity address generator (supports OpenCL)
BSD 2-Clause "Simplified" License
92 stars 31 forks source link

Reset current attempt stats after match #25

Closed webmaster128 closed 6 years ago

webmaster128 commented 6 years ago

Closes #24

PlasmaPower commented 6 years ago

When both reading and writing 0, the attempts counter should be accessed inside of the start time mutex, to avoid race conditions. That said, have you considered just not resetting the attempts counter? It makes sense to me if at the 3rd key progress is 300%. It'd give you an overall progress vs an individual progress.

webmaster128 commented 6 years ago

When both reading and writing 0, the attempts counter should be accessed inside of the start time mutex, to avoid race conditions.

I considered the case showing (attempts, start_time) where one is reset and the other is not for 250 milliseconds irrelevant. If you want to go that far and push for correctnes, we should have a struct (attempts, start_time) that is protected by a single RwLock.

That said, have you considered just not resetting the attempts counter? It makes sense to me if at the 3rd key progress is 300%. It'd give you an overall progress vs an individual progress.

I don't know if I understand correctly. All stats (estimated, keys, ratio, speed) are currently based on the current attempt and changing this is probably out of scope. Personally I have no interest in other limits than 1 and unlimted, in which case the overall progress makes no sense.

webmaster128 commented 6 years ago

That said, have you considered just not resetting the attempts counter?

Ahh, now I get it. Interesting thought. No, I did not consider that. It would be a much simpler solution to #24

webmaster128 commented 6 years ago

Just let me know which way you prefer. I'm fine with both

PlasmaPower commented 6 years ago

I'd prefer not resetting the attempts counter. I don't think there's a significant difference for the user, so let's stick with what makes the code simpler.

webmaster128 commented 6 years ago

Here we go: #26