Mining stops at a random #979
Comments
|
I saw a similar occurrence of this on my Mac while running overnight. I've got a Windows desktop that's also mining, so I can report back if it exhibits similar behaviour. |
|
I'm still seeing this issue as reported in #1008, latest develop code, so it's definitely an issue. |
|
I'm also experiencing this on my Mac (v0.9.21.1). Extremely difficult to reproduce. No clue where to start looking. I'm running a private chain. Even when I delete all my ethereum details and the DAG (under ~/.ethash), it still does not work. It finished creating the DAG... then nothing happens. Turning the miner of and on (after DAG creation), it just prints this: Nothing new happens. Similarly, if turn geth off and on, and start the miner it just does: Nothing new happens. Like I said previously, it is very temperamental. Sometimes, just waiting for a while (with no predictable period of time), it just starts again. It threw these errors in the past, and then I regenerated the DAG and it worked again. But now, even that doesn't seem to kickstart it again. Trying all possibilities to figure out why it is locking up. And trying to figure why it started working again previously. |
|
There was an ugly race condition fixed in the miner in #1031, that could be one of the causes of the lockup. As far as I see it in the code, there is still a possible data race that could cause this kind of behavior. I'll try and repro it with the above fix to see if it disappears or not. |
|
Thanks @karalabe. I was experiencing that other race condition as well, but it wasn't related to my current issues where the chain just locks up. The other race condition threw visible errors. |
|
So, I did some debugging (aka waiting). Turns out sometimes my miner on OS X just slows down to something like a 10th of its usual hashrate, thus causing blocks to sometimes be as long as 10 minutes. I can't seem to figure out when this happens to reproduce it predictably. Stop and starting it, doesn't always work. Regenerating the DAG also doesn't work always. Also, even restarting isn't predictable. So, I suspect there might be something else happening rather than just system-level resource issues. |
|
Do you still experience these (on latest develop I mean)? |
|
Haven't seen the issue on 0.9.22.60 (from Chocolatey). |
|
Unfortunately, still experiencing issues with this. Thought about making a new issue, tell me if I should. On v0.9.23. It's definitely an issue with an inconsistent hashrate still. It's incredibly difficult to debug. I have no idea where to start looking. I can't measure the hashrate before it actually solves a block. The only way I know it is actually trying to mine is that my Mac goes slightly slower & it does eventually find a block (sometimes only 10min later). Sometimes it never finds a new block (even after 30min). Then sometimes it just "snaps" back, and produces blocks on the regular (< 12s/block). I'm not sure why I'm getting inconsistent hashrates. My suspicion is that it might be DAG-related? (the only reason guess it is this, because this is the only thing that is relatively different than other blockchain mining systems). But even if I restart and try it, it is something wonky. Any advice on how to debug this? Any help appreciated. |
|
Got a log? |
|
@obscuren: That's also the problem. It's not generating anything useful (at verbosity 4 at least). At verbosity 8 there's too much noise, so I tried piping it to a logfile (to grep the related mining logs and see if there are logs I'm missing), but it seems I'm having issues with --logfile. Will debug that. fwiw. Here's the log on startup at verbosity 4. Then stopping and running it again. In both cases, nothing new happens. This is obviously after the DAG has been created. It's not related to a newly created DAG, since even if I nuke it and redo the DAG, it also just hang and waits (assuming it's generating poor hashrates). Best debug would be to know what the hashrate is before I even find a block. That could give more clues. |
|
Could you try |
|
@obscuren Not much help. |
|
It appears to be generating the DAG twice. @zelig could this be the dag update mechanism? |
|
Looking at the code, if I understand it correctly nextEpoch isn't set the first time it is started, thus it tries to generate the DAG again, but it is already done, so it just looks like it is generating it twice. That could explain that part? However. The mining works sometimes and then sometimes it doesn't. So don't think it is the generation of the DAG that is the issue. I can mine, turn it off, do some coding, not closing geth and then try to mine some new transactions and then it just doesn't mine new blocks (or 1 every 10 - 30min). So something is happening subsequently, causing hashrate to drop substantially, and randomly. I've rebooted and ran it, and the hashrate was horrible. I've used a fully encumbered system and it mined perfectly. This has been failing since 0.9.20 (the first version I tried in a while, so the error could've come from earlier), not the new auto-updating DAG code. |
|
Could you see if running with just 4 mining threads makes a difference ( |
|
Nope. Nothing. However, I've been trying to figure out what could be causing it to slow down so considerably. Understandably it behaves slightly more consistently with less load on the machine. So, I proceeded to kill all running apps, and then after about 2 minutes, it started producing blocks (while keeping 8 threads running). When producing blocks the hashrate is in the excess of 260k - 320k. 1 thread produces 59k. When it is really slow it was around 20k (for all 8 threads combined). This could just be some fluke again, because I have run geth straight from a fresh reboot and it didn't produce blocks. (I'll be pretty annoyed if it is a fluke, because I'm starting to feel like I'm just wasting everyone's time here). I just wish there was a way to know for sure that the load on the machine is causing it to decrease. Or, introduce some information what the current hashrate is (before even finding a block), and when (considering the difficulty) an expected block will be found. And as more resources become available it should update as it goes along. Is there any other way I could debug this more? Or any other way I can produce blocks more consistently and not get hiccups when developing? |
* Adds ERC20 tokens list to Ledger * adds detection for erc20 * handle error status code correctly * makes status code a constant * fmt * moves to kobigurk branch * more temp tokens for testing * revert circleci * lint * updates token list for rc1 * fixes tokens test * fixes tokens test * moves token data to a separate file and adds a comment on ERC20 transfer prefix
* README: remove unnecessary info from readme and simplify * more changes * more changes * more changes * add contribution guidelines * add test command * README: add release tag info
* README: remove unnecessary info from readme and simplify * more changes * more changes * more changes * add contribution guidelines * add test command * README: add release tag info
At random point in time, mining suddenly stops and all that is happening is blockchain downloads. Restarting the client starts mining again.
This happens on Windows 7 x64, 0.9.20. Already observed this behavior twice.
The text was updated successfully, but these errors were encountered: