a lot of "NOT confirmed DL" messages when mining



  • Hi all,

    I've just started mining, and have dedicated 7.4TB to it. I'm using the pool.burst-team.us pool. I notice about 1/10 or so of my sent deadlines get a "NOT confirmed DL" response. Checking the pool's info page, indeed these deadlines aren't listed. Occasionally there will be no response, and I will see the deadline listed on the pool's page - but when I receive the "NOT confirmed DL" message it looks like the pool doesn't get it. I can then stop the miner process, restart it, find and resend the deadline, and have it received.

    Anyway, I'm just writing to see if anyone knows of a solution to this problem. It seems like I'm throwing away 1/10 or so of my capacity now. It's especially annoying when a higher deadline is accepted and then a few seconds later a really low deadline isn't.

    0_1476841812905_burst1.jpg 0_1476841875372_burst2.jpg



  • @FlippyCakes I had this happen too. I had corrupted file really bad deadline warnings too though. Do you ever get those?

    I had to replot. But you could try to use PlotsFileChecker.exe to make sure the plots are good. It usually is the pool though. If you changed pools then I would be suspect of that. You may not see the Corrupt file warning every time too since it is only when it finds a really bad deadline.

    If you see the warning for really bad plots then turn off the miner and take out a drive each time until the error goes away. It has to be on the same block though so you know the plot that was bad is using the same deadline for that block. This will tell you which drive has the bad plot so you can know which one to replot.

    Try to go to another pool too and see if it goes away. But that pool has thousands of users and may be that also.

    https://github.com/Blagodarenko/PlotsChecker/releases/download/1.0/PlotsChecker.exe


  • admin

    @FlippyCakes There are basically three circumstances you'll get a "not confirmed" message:
    a) The deadline really never got to the pool - this does happen, not really anything you or the pool can do. It's leaving your system, but never getting to the pool
    b) The pool got and processed your deadline, but the confirmation never gets back to your system in the deadline your config has. Try increasing the deadline response.
    c) Your deadline was over the pool limit, but the message never got to you in time.

    Increase your deadline timeout, but that's about all you can do.



  • @CryptoNick thanks for your response.

    I don't think the plots are at fault. I never get any warnings or messages about deadlines being corrupt. As I said, when a deadline receives the "NOT confirmed DL" response I can stop the miner, restart it, find and resend the deadline, and have it accepted.



  • @haitch said in a lot of "NOT confirmed DL" messages when mining:

    @FlippyCakes There are basically three circumstances you'll get a "not confirmed" message:
    a) The deadline really never got to the pool - this does happen, not really anything you or the pool can do. It's leaving your system, but never getting to the pool

    In this case, does the miner receive a "NOT confirmed DL" message? Because I've occasionally had no response BUT checked the pool web page and saw the deadline was received. I don't have a problem with that because the pool still credits me.

    b) The pool got and processed your deadline, but the confirmation never gets back to your system in the deadline your config has. Try increasing the deadline response.

    This doesn't seem to be the case. Many times after receiving the "NOT confirmed DL" message I've checked the pool web page and saw that, indeed, my submitted deadline was not there.

    c) Your deadline was over the pool limit, but the message never got to you in time.

    In this case, wouldn't the miner not submit it in the first place?

    Anyway, thanks for your response. I may try switching to another pool tonight after I get home from work.



  • @FlippyCakes
    @haitch didn't mention: When the pool receives a lot of deadlines, it uses all of the CPU power it got to confirm them. If pool got more then normal, it might delay the confirmation messages to save work. They can happen to be delayed so much you never receive them with your current config.
    This is why they can be seen on the pool, but you won't get any messages back.'

    Only your best deadline shows up on the pool webpage. They can also be below the limit, which might make them invisible on the pool scoreboard. They should not be sent, but I don't know the exact details.



  • @FrilledShark said in a lot of "NOT confirmed DL" messages when mining:

    This is why they can be seen on the pool, but you won't get any messages back.

    Good to know. What I'm experiencing seems to be the exact opposite, though. I get a message saying it wasn't accepted, and the pool doesn't list the deadline.



  • @FlippyCakes
    Are you able to show a screenshot?
    Of course, if the pool told you the deadlines wasn't confirmed it doesn't show it.



  • @FrilledShark

    I've got some screenshots at the top of the thread. For checking the pool, I'm only CTRL-Fing my username on the pool's stats page. That seems to be fairly accurate.



  • @FlippyCakes
    The both screenshots are working on the same block. The only difference is that they are 10 min apart. The means the last screenshot is while the pool experiences almost no load and the first is when the pool experiences loan. Edit: and as you see, it was able to confirm the deadlines on the last screenshot, but not the first one.

    I don't think there is anything to worry about.



  • @FrilledShark

    I think it is worrisome. I'm getting a lot of these messages, and not being credited by the pool for a lot of deadlines that I send. I can't babysit the miner and manually restart it to force resend a sweet deadline just because when I originally sent it the pool was busy.



  • @FlippyCakes If you are still on burst-team.us know that it's recommended plot size is 14.166. If you are still working with only 7.4TB that might be the reason why you are not getting good DL's.

    https://docs.google.com/spreadsheets/d/1KHu9BWwy_QXIYAx2m_Tzs9BqPoTYUDhEDbHihZEXGsE/edit#gid=81124645



  • @socalguy Thanks! Yeah, I'll probably try switching pools tonight.



  • im having the same issue but also im going multiple blocks without finding any deadlines at all ... been that way all day. The file size error is from a plot im currently ploting. 0_1476925154661_Untitled.png


  • admin

    @Gibsalot With 3TB, you shouldn't be mining on pool.burst-team.us - you'll find very few deadlines. Move to pool.burstcoin.biz or pool.burstcoin.eu or one of the other pools that are set up for smaller plots.



  • i moved to pool.burstmining.club just after i posted that message im finding plenty of deadlines now about like i was when i started with burst-team.us atm i have 3TB mining but will have just under 10TB after i get everything ploted



  • Maybe there is a way to edit .cpp file from source code to force miner to restart on Not confirmed DL ?
    I'm currently mining on burstneon and got the same issue.
    On logs there is no proper confirmation from pool:

    10:52:07 ------------------------    New block: 356963
    10:52:07 Sender: started thread
    10:52:07 Start thread: [0]  Q:\plots\
    10:52:07 Read file : 1403xxx_0_1720320_1720320
    10:52:08 * GMI: Sent: POST /burst?requestType=getMiningInfo HTTP/1.0\r\nConnection: close\r\n\r\n
    10:52:08 found deadline=416472 nonce=678986 for account: 1403xxx file: 1403xxx_0_1720320_1720320
    10:52:08 * GMI: Received: HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nDate: Sat, 06 May 2017 08:52:13 GMT\r\nConnection: close\r\n\r\n{"generationSignature":"9aa3a83141238d4b3ad0de87052da3c661a708048ece4f49000ac82d89db2dc8","baseTarget":"779401","requestProcessingTime":0,"height":"356963"}
    10:52:08 Sender: Sent: POST /burst?requestType=submitNonce&accountId=1403xxx&nonce=678986&deadline=324599121813 HTTP/1.0\r\nX-Miner: Blago v1.160705_AVX\r\nX-Capacity: 460\r\nConnection: close\r\n\r\n
    10:52:09 * GMI: Sent: POST /burst?requestType=getMiningInfo HTTP/1.0\r\nConnection: close\r\n\r\n
    10:52:10 * GMI: Received: HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nDate: Sat, 06 May 2017 08:52:15 GMT\r\nConnection: close\r\n\r\n{"generationSignature":"9aa3a83141238d4b3ad0de87052da3c661a708048ece4f49000ac82d89db2dc8","baseTarget":"779401","requestProcessingTime":0,"height":"356963"}
    10:52:10 Close file: 1403xxx_0_1720320_1720320 [@ 2294 ms]
    
    10:52:10 Read file : 1403xxx_1720321_163840_163840
    10:52:10 Close file: 1403xxx_1720321_163840_163840 [@ 229 ms]
    
    10:52:10 Sender: Received: 
    10:52:10 Sender: wrong message for DL: 1403xxx
    10:52:10 Sender: Close socket. Code = 0
    
    10:52:11 * GMI: Sent: POST /burst?requestType=getMiningInfo HTTP/1.0\r\nConnection: close\r\n\r\n
    10:52:11 * GMI: Received: HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nDate: Sat, 06 May 2017 08:52:16 GMT\r\nConnection: close\r\n\r\n{"generationSignature":"9aa3a83141238d4b3ad0de87052da3c661a708048ece4f49000ac82d89db2dc8","baseTarget":"779401","requestProcessingTime":0,"height":"356963"}
    10:52:12 * GMI: Sent: POST /burst?requestType=getMiningInfo HTTP/1.0\r\nConnection: close\r\n\r\n
    10:52:13 * GMI: Received: HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nDate: Sat, 06 May 2017 08:52:18 GMT\r\nConnection: close\r\n\r\n{"generationSignature":"9aa3a83141238d4b3ad0de87052da3c661a708048ece4f49000ac82d89db2dc8","baseTarget":"779401","requestProcessingTime":0,"height":"356963"}