Deadlines NOT confirmed jminer
-
Hey fellow Bursters,
I'm mining solo and I'm trying to understand why some of my deadlines are not being confirmed. It seems to happen randomly and the size of the deadline doesn't seem to matter. After seeing a few NOT confirmed messages, I removed the targetDeadline I had set just to see what would get confirmed and what wouldn't. Here's an example:
EDIT: No, I don't want to use the low-res resized version. Nobody can read that.
I had also tried changing the timeout value to something ridiculously high and I still get unconfirmed deadlines from time to time. At this point I am wondering if my plot files are somehow corrupted or if one or more of my drives has issues, but they all seem fine on a SMART health check. Is there any way to analyze plot files to see if they give valid nonces or is there some other problem here? @luxe @Blago @haitch
-
Here's the worst case scenario:
-
This post is deleted!
-
@Han-Solo Those are good points and I can understand if really high deadlines are not confirmed, but see my example above where I had a two minute deadline and no matter how many times I restarted jminer, it just wouldn't confirm. Maybe this was due to the network being super forked at the time, but why is it still happening today?
Specifically, I'd like to know if there's a way to find out exactly WHY my deadline is not confirmed. Was there a timeout? Was the deadline too high? Was the deadline invalid?
-
@sevencardz I think jMiner doesn't post a message if it gets a really bad none. Blago + a Ninja style pool will give you a message about "Your deadline was REALLY bad ,,,,". A lot of those would be an indication of a corrupt plot.
-
@haitch Assuming it is a corrupt plot, how would I track it down to the exact plot? Does blago's miner report such things?
-
@sevencardz In the log file it reports the nonce that was sent in - from there you can determine the file the nonce came from. eg:
15:59:09 Sender: Sent: POST /burst?requestType=submitNonce&accountId=17250039689296678890&nonce=43090691&deadline=269279145404 HTTP/1.0\r\nX-Miner: Blago v1.160705_AVX\r\nX-Capacity: 36319\r\nConnection: close\r\n\r\n
15:59:21 Sender: Received: HTTP/1.0 400 Bad Request\r\nContent-Length: 189\r\nContent-Type: text/html; charset=UTF-8\r\nDate: Fri, 10 Mar 2017 21:59:20 GMT\r\n\r\n{"errorCode":1007,"errorDescription":"The deadline for your nonce is REALLY BAD: 191532 years, 11 months, 18 days, 16 hours, 33 mins, 38 secs - wrong block? are your plot files corrupted?"}
-
This post is deleted!
-
@haitch @Han-Solo Thanks guys, I will look into both of these methods. Seems a refurbished drive may be to blame here! Full formats incoming.
-
@sevencardz First of all 'NOT confirmed' means, that the miner thought is was a good deadline, but the wallet/pool did not confirm that in response ... in latest version you should get details on that if you set 'debug=true'.
I'm still not sure what is causing this ... maybe however corrupted plotfile, maybe a bug in miner ... i always thought it is about corrupted plotfile ... @Han-Solo please tell me if you monitor a round, where jminer tells deadline is corrupted and other miner commits without issue :-)I found i very interesting, if i watch details with 'debug=true' that is seams to be always the same plotfile causing it over some rounds after message disappears again.
-
This post is deleted!
-
@Han-Solo said in Deadlines NOT confirmed jminer:
Did I said that?
P.S. In my experience CPU plotter is less likely to make a bad plot file then GPU plotter.
No, sry ... my fault ... i did read miner ... but you wrote plotter :-) Was a long work day ... maybe i'm too tired :-)
-
@luxe I had set debug=true, but I didn't see any more details on why the deadline wasn't confirmed. I am using jminer 0.4.9 and the standard burstcoin wallet 1.2.8. The first screen shot I posted is with debug on. It shows longer deadlines being removed from queue, but that's not a problem of course. Does it print more info if I send the output to a log file? I will check this again when I get home.
I also noticed with the most recent jminer that it will re-submit deadlines that got a NOT confirmed and sometimes they will then get confirmed. I like the fact that it re-submits, but I'm curious as to why my wallet would reject a deadline and then accept that exact same deadline a few seconds later with no problem? Do I need to use a different wallet?
I will also try running blago's miner alongside jminer and do some comparisons.
-
An example of a NOT confirmed that is then immediately confirmed on the next submit:
-
I also notice that if I restart jminer, then it completes the round much faster than normally. Notice that this round only took 8 seconds, whereas the previous round took 24 seconds. This only happens on the first round after you start jminer. Subsequent rounds take 24 seconds again. Why is this? Why don't I get short 8 second rounds every time?
EDIT: Seems to only happen if the round was completed at least once before, almost like it's pulling from cache, but what cache?
-
@sevencardz First of all, thanks for all your testing, you are finding stuff i never saw before :-)
On restart 'mining the same round again' ... the data is still in drive caches (i guess), so drives are no longer the bottleneck ... guess the 8s round was than limited by your gpu. Means you could add more drives without increasing round time, as long they use additional controllers.
I know i fixed the output on debug=true, but it seams it is not committed yet, sry, it will be in next version.
The info that on 2nd commit the deadline was accepted is very interesting ... even i can not remember i ever implemented that feature ... i will recheck and maybe improve it ... strange a commit result should be deterministic ...
-
@luxe Thank you for your help as well. :) Hard drive cache certainly makes sense for the 8s re-started rounds.
I was away most of the weekend but I left jminer running with your latest version to see how many plot files would identify bad deadlines and it seems that I've got at least one bad plot on every drive I'm mining, so it looks like I've got some replotting to do. Originally, I guessed the bad plots might have come from a drive I had to RMA a while back, but with the issue being this wide-spread, I am now thinking a power surge that fried my last motherboard also might've corrupted some of the plots on all the drives I was mining at the time.
I have plenty more TBs to plot though, so I will just make a bunch of brand new plots with GPU plot generator and test those to see if any of the deadlines get rejected. If they do, then I'll try again with Xplotter and see if maybe there's an issue with GPU plot generator. I somewhat doubt that though because I don't recall having these issues until recently. Either way, I will find the source of the issue.
-
@luxe So here's an interesting result. I created fresh plots on two 8TB drives with GPU plot generator and started mining them. In this round, deadline 173717 gets sent, sent again, sent again, and then gets a NOT confirmed. Not even a second later, the same deadline (from a different nonce?) gets sent again, gets confirmed and becomes the best deadline for the round.
-
@luxe I've been running jminer 0.4.5 and jminer 0.5.0 side by side for a few days. Besides the unconfirmed deadlines, one problem I've seen is that jminer 0.5.0 will queue a deadline (say 2000) and wait for a confirmation on a shorter deadline (say 1000). The problem happens when the shorter 1000 deadline never gets confirmed, then the queued deadline never gets submitted. You can end up with a round never completing and your best deadline never getting submitted (deadline 65148 was confirmed by jminer 0.4.5 in another window).
-
@sevencardz Thanks for reporting, i will look into it ... maybe it just happens due fast block ... makes no sense to commit queued after new block started ... the read order is not deterministic, so the other jminer instance may have found the deadline earlier.
