Jminer error "Nonce was committed to pool, but not confirmed [...]"



  • I got the Jminer error "Nonce was committed to pool, but not confirmed ... caused by connectionTimeout, currently '6 sec. Try increasing it!". So I increased the timeout value in jminer.properties from 6000 to 60000. Then I started getting these errors about submitting extremely long deadlines (13000 years etc.). Is the timeout value connected to the deadlines in some way? If so, what is the maximum timeout value I could set it to?



  • The timeout defined in jminer.properties is the allotted response time value. Depending on your connection speed and other operations your PC might be doing you may have to increase is from 6000 to a slightly higher number. Keep in mind this number is thousands of seconds, so every 1000 is one second. I raised my default value from 6000 to 20000 (20 seconds) and I no longer receive this error.

    Your extremely long deadlines are a by product of something else. How large is your plot?

    Can you post a screen shot of the miner right after it has started up and a full copy of your jminer.properties (please remove your passphrase)?

    HTH,

    -IceBurst


  • admin

    @Propagandalf The miner sends a request to the pool, the timeout specifies the time, it will wait for a response. If you have it at 60sec. the pool maybe respond after a new round has started, that could cause the deadline to be very high if it gets validated against the new block mining info. Try what @IceBurst suggested. The miner gets this error about high deadline from pool ... as response to commit deadline. Is is not a calculation made by miner.



  • @IceBurst said:

    How large is your plot?

    Can you post a screen shot of the miner right after it has started up and a full copy of your jminer.properties (please remove your passphrase)?

    My plot is 6,4 TB. Here is a screenshot of my startup screen
    0_1467744778589_Screenshot 1.png It says (0 GB) after presenting my GPU, is that value OK or supposed to be something else?

    Here are my jminer.properties

    plotPaths=F:/Burst/plots,E:/Burst/plots,C:/Burst/plots,
    poolMining=true
    numericAccountId=12477725988673239741
    poolServer=http://pool.burst-team.us
    walletServer=
    winnerRetriesOnAsync=
    winnerRetryIntervalInMs=
    devPool=
    devPoolCommitsPerRound=
    soloServer=http://localhost:8125
    passPhrase=snip
    targetDeadline=
    platformId=1
    deviceId=0
    restartInterval=240
    chunkPartNonces=320000
    refreshInterval=2000
    connectionTimeout=20000

    @luxe

    If you have it at 60sec. the pool maybe respond after a new round has started, that could cause the deadline to be very high if it gets validated against the new block mining info.

    So, if I understand you correctly, there is a chance that I validate my nonces against the wrong block if I set the timeout for too long, thus making my submitted deadline invalid. Is that correct? The original error states that the nonce was committed, but not confirmed. Does that mean that everything is alright, or MUST we get a confirmation in order to have a valid deadline? In other words, could I ignore the error?

    Unless I have misunderstood, this means that having a low timeout value in jminer.properties is harmless (but will produce an error sometimes), whereas setting a too high value may actually make your submitted deadlines invalid?


  • admin

    it says (0 GB) after presenting my GPU,

    It says capacity '6875 GB'

    Is that correct?

    Yes, high timeout does not effect your mining, but may result in such errors.



  • I'll tell you what I did not see....
    The plot listing, you may want to turn that on. Add to your jminer.properties

    listPlotFiles=true
    

    It can help with finding plot problems in the future, however it appears you are all sorted out. I see you running successfully on pool.burst-team.us with a pending payout of 39 coins. I see your full plot size of 6.7TB. I would say everything is working as expected



  • @luxe
    @IceBurst

    Thanks to both of you.

    When I use Blago's miner, I use about 34 seconds to read all plots. When I use Jminer, I use about 25 seconds. Is this more or less what it should be like?

    I have intel HD graphics 4600 integrated gpu and 16 GB ram, and I also have Geforce 860 M with 2 GB dedicated ram. So, I do not understand what the "6875 GB" capacity refers to. Also, it does say "(0 GB)" where it says "DEVICE - [0] GeForce GTX 860M (0GB)", but I'm not sure if that matters.

    WIll it make a difference if I choose the integrated vs. the dedicated GPU?



  • My guess is that you are using the on board graphics card for processing the plot and not the nVidia and I am basing that off of your provided items. You may want to modify you jminer.properties one more time to:

    deviceId=1
    

    The application starts counting video cards at zero (0) and increments for each card. If it assigned the on board graphics to zero (which it's saying the nVidia is) that explains why the nVidia is not reading the plots. I know this is counter intuitive to what the output is saying but I would try it any ways.

    The reading of "6875GB" refers to your total plotted size on disk which equates to 6.8TB of plots. The larger your plot the better chance you have of finding a faster/shorter deadline.

    In all cases the GPU miner should be faster than the CPU miner but performance can vary based upon the actual graphics card and the connection methodology for the HDDs.

    Hope this helps,

    -IceBurst


  • admin

    Good answer IceBurst. I just want to add something:

    The Win Client always takes the deviceId=0 and even overwrites it, when you click "Start Mining" with it. If you change your config by hand, you should start your miner by hand, too.



  • @iceburst and @dawallet Thanks for the help. My options seem to be
    platform (0) openCL 1.2
    device (0) Intel HD Graphics 4600
    device (1) i7 CPU

    platform (1) Nvidia CUDA
    device (0) GeForce GTX 860M
    and no further devices.

    Whether I configure the miner for platform (0) and device (0), or platform (1) and device (0), I get the same read speeds. Do you reckon this is normal? If so, then there is no point in using the GeForce for reading plots, when I can instead use it for GPU mining some other coin, and let the Intel GPU focus on Jminer.

    Configuration (0)+(0) gets work group size "512" and computing units "20", whereas configuration (1)+(0) gets work group size "1024" and computing units "5". Any chance of a simple explanation of these values?



  • I'll mess up the metrics here and someone can correct me. If I recall the the first metric is similar to threads, the number of concurrent processes to run, the second is the number of calculation to perform on a thread and then return back to get a new work load. If someone can double check my understanding it would be greatly appreciated. To mine with the nVidia you need to be on Platform 1, device 0. I recommend starting jminer form the command line. I can provide a sample jminer.properties if that helps.

    My dedicated mining machine actually mines four coins at once, two on the primary GPU, one on the CPU and then uses the on board the GPU only for jminer.

    HTH,

    -IceBurst



  • @IceBurst

    Thanks again for the explanation!

    No thanks, that won't be necessary as I'm running Jminer fine now from the run.bat with a functional jminer.properties file.

    I'm now mining ETH with my primary GPU, Burst/Jminer with my on board GPU and XMR with my CPU. I believe the EuropeCoin (ECR) crew are in a test phase with RAM mining too, but I'm not entirely familiar with the concept. I hope it means I can mine a fourth coin with the same computer though, hehe. Would you mind sharing which coins you mine?



  • @Propagandalf said:

    @IceBurst

    Would you mind sharing which coins you mine?

    I guess it's not really a big secret so I'll share:
    I mine ETH on the GPU -> Auto-Converted to BTC
    I mine DCR on the memory of the GPU
    I mine Lyra2 on the CPU -> Auto-Converted to BTC
    I mine BURST on the HDD

    Funny World,

    -IceBurst



  • @Propagandalf said:

    Whether I configure the miner for platform (0) and device (0), or platform (1) and device (0), I get the same read speeds. Do you reckon this is normal?

    I think it's normal. Reading speed of the hard drive should be the bottleneck, I suppose...


  • admin

    @Dario's-wallet said:

    @Propagandalf said:

    Whether I configure the miner for platform (0) and device (0), or platform (1) and device (0), I get the same read speeds. Do you reckon this is normal?

    I think it's normal. Reading speed of the hard drive should be the bottleneck, I suppose...

    Yes, the GPU is only used for deadline calculations of the data read from plotfiles. With 30GB+ Plots you can reach a point were CPU is at 100% (CPU performance may have increased a lot ... this are some old experiences i made.), in such cases you can benefit from GPU. If your CPU becomes the bottleneck.
    So in your case the round time surely only depends on how fast you can read the data.