Proposed new parameter: --lhr-wait-time

[InterClaw]

When the GPU starts LHR locking and NBMiner stops mining, I feel that the miner starts back up too quickly sometimes, not giving the GPU ample time to unlock/"forget". Because what happens a little too often is that when it resumes mining it will immediately detect a lock again, and round and round we go...

If I was able to increase the downtime by setting a value to a parameter like "--lhr-wait-time" or maybe "--lhr-unlock-time", then I think the chances are greater for the resumption to be successful more times than not. What is it now? Like 15 seconds? I think being able to configure it to something like 30 seconds here would help a lot.

[Tom5051]

lower your LHR value a bit. Usually only see a second lock after 7 or 8 minutes here then good for days.

[InterClaw]

Avoiding the lock from happening in the first place is of course a good idea.

But when it does happen I think it would be good to have more tools at your disposal to get past it as efficiently as possible. I think this would help.

I'm not sure though what makes the miner start back up. Is it monitoring something on the GPU? And the new lock is just that - a new lock? Or is it just randomly giving it some seconds and then tries again?

[Tom5051]

I don't see the point of what you are asking.

[InterClaw]

You don't understand what I'm asking? Or you don't see the point in asking that at all?

I'm hoping it's the former, so I'll explain it in simpler terms:

1. There's a lock.
2. The miner stops.
3. ????
4. The miner starts.

I'm trying to figure out what happens in step 3. Is it a timer? Or is it actually detecting that the GPU unlocks itself?

• If it's a timer, then I believe that in my case it hasn't waited long enough for the GPU to unlock, since it will fairly often just detect a lock again and stop. If I would be able to configure it to wait a bit longer before resuming mining, I think I would have greater success in avoiding endless loops of stops and starts.

• If it's not a timer, and it acutally does detect the GPU unlocking, then I guess there's not much to do about this. In these situations I have to restart the miner completely when it can't sort this out on its own. Having a bit of a grace period using this proposed parameter might still help though.

[Tom5051]

I'll say it again, lower your LHR value a bit if you are getting that many locks. It doesn't make much difference to the hash rate like memory over clocking does.

[InterClaw]

Yep, for sure! I already do that and the lower I set that starting point, the less likely it is I'll have a lock to begin with. And this is not happening that often and many times the miner is able to resolve it by itself.

It's just that there are situations where it doesn't seem to be able to do that on its own. Never said they were frequent, just that it can happen for time to time. Well, I did say "a little too often". Which I still think it is. Some people might be completely unaffected by this as well.

I can set the LHR value even lower to never get a lock. But recovering from a lock is an intended feature of NBMiner, right? And I think this suggestion could be another tool for the miner to have at its disposal to combat that when it happens.

It's just an idea, that's all.