CUDA miner

1505153555669

Comments

  • excavateexcavate Member Posts: 7
    @Genoil I reinstalled Ubuntu 14.04, working perfectly now. Thanks for looking into that.
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    edited May 2016
    @Genoil Happened again a few hours back and this time a second hardwired rig joined it, same error and potentially at exact same time (ethpool notification emails sent at same time)

    Similar rig to other one, Win7 x64, five AMD GPU, 15.7.1 drivers, 8GB RAM and AM3 CPU.
    And yet.... just these two out of a dozen or more rigs on this network.
    Post edited by Logicaluser on
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    edited May 2016
    @Genoil Happened to a third rig (also hardwired), managed to catch the log of first signs of trouble:

    m 11:14:40|main Mining on PoWhash #2ea4413b : 97.98MH/s [A0+0:R0+0:F0]
    m 11:14:42|main Mining on PoWhash #2ea4413b : 99.02MH/s [A0+0:R0+0:F0]
    X 11:14:42|stratum Handle response failed: An established connection was aborted by the software in your host machine
    X 11:14:42|stratum Handle response failed: An established connection was aborted by the software in your host machine
    X 11:14:42|stratum Handle response failed: An established connection was aborted by the software in your host machine
    X 11:14:42|stratum Handle response failed: An established connection was aborted by the software in your host machine
    X 11:14:42|stratum Read response failed: An established connection was aborted by the software in your host machine
    i 11:14:42|stratum Reconnecting in 3 seconds...
    i 11:14:46|stratum Connecting to stratum server us1.ethpool.org:3333
    i 11:14:46|stratum No new work received in 90 seconds.
    i 11:14:46|stratum Reconnecting in 3 seconds...
    i 11:14:46|stratum Connected to stratum server us1.ethpool.org : 3333
    i 11:14:46|stratum Subscribed to stratum server
    i 11:14:46|stratum Authorized worker x
    i 11:14:46|stratum Received new job #bc6570d0
    i 11:14:46|gpuminer0 set work to: #bc6570d0, target #0000000112e0be82
    i 11:14:46|gpuminer1 set work to: #bc6570d0, target #0000000112e0be82
    i 11:14:46|gpuminer2 set work to: #bc6570d0, target #0000000112e0be82
    i 11:14:46|gpuminer3 set work to: #bc6570d0, target #0000000112e0be82
    i 11:14:46|gpuminer4 set work to: #bc6570d0, target #0000000112e0be82
    m 11:14:46|main Mining on PoWhash #bc6570d0 : 5.09MH/s [A0+0:R0+0:F0]
    m 11:14:48|main Mining on PoWhash #bc6570d0 : 97.98MH/s [A0+0:R0+0:F0]
    i 11:14:49|stratum Connecting to stratum server us2.ethpool.org:3333
    X 11:14:49|stratum Read response failed: The network connection was aborted by the local system
    i 11:14:49|stratum Reconnecting in 3 seconds...
    X 11:14:49|stratum Could not connect to stratum server us1.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:14:49|stratum Reconnecting in 3 seconds...
    i 11:14:52|stratum Connecting to stratum server us2.ethpool.org:3333
    i 11:14:52|stratum Connecting to stratum server us2.ethpool.org:3333
    X 11:14:52|stratum Could not connect to stratum server us2.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:14:52|stratum Reconnecting in 3 seconds...
    X 11:14:52|stratum Could not connect to stratum server us1.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:14:52|stratum Reconnecting in 3 seconds...
    i 11:14:55|stratum Connecting to stratum server us2.ethpool.org:3333
    i 11:14:55|stratum Connecting to stratum server us2.ethpool.org:3333
    X 11:14:55|stratum Could not connect to stratum server us2.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:14:55|stratum Reconnecting in 3 seconds...
    X 11:14:55|stratum Could not connect to stratum server us1.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:14:55|stratum Reconnecting in 3 seconds...
    i 11:14:58|stratum Connecting to stratum server us2.ethpool.org:3333
    i 11:14:58|stratum Connecting to stratum server us2.ethpool.org:3333
    X 11:14:58|stratum Could not connect to stratum server us2.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:14:58|stratum Reconnecting in 3 seconds...
    i 11:14:58|stratum Connected to stratum server us2.ethpool.org : 3333
    i 11:14:58|stratum Subscribed to stratum server
    i 11:14:58|stratum Authorized worker x
    i 11:14:58|stratum Received new job #73ebf569
    i 11:14:58|gpuminer0 set work to: #73ebf569, target #0000000112e0be82
    i 11:14:58|gpuminer1 set work to: #73ebf569, target #0000000112e0be82
    i 11:14:58|gpuminer2 set work to: #73ebf569, target #0000000112e0be82
    i 11:14:58|gpuminer3 set work to: #73ebf569, target #0000000112e0be82
    i 11:14:58|gpuminer4 set work to: #73ebf569, target #0000000112e0be82
    m 11:14:59|main Mining on PoWhash #73ebf569 : 161.32MH/s [A0+0:R0+0:F0]
    m 11:15:01|main Mining on PoWhash #73ebf569 : 97.98MH/s [A0+0:R0+0:F0]
    i 11:15:01|stratum Connecting to stratum server us1.ethpool.org:3333
    X 11:15:01|stratum Read response failed: The network connection was aborted by the local system
    i 11:15:01|stratum Reconnecting in 3 seconds...
    X 11:15:01|stratum Could not connect to stratum server us2.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request
    i 11:15:01|stratum Reconnecting in 3 seconds...
    i 11:15:04|stratum Connecting to stratum server us1.ethpool.org:3333
    i 11:15:04|stratum Connecting to stratum server us1.ethpool.org:3333
    X 11:15:04|stratum Could not connect to stratum server us1.ethpool.org : 3333 , The I/O operation has been aborted because of either a thread exit or an application request


  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @Logicaluser Well this sure looks messy but it isn't the Bad file descriptor error crash. Try this: find cpp-ethereum/libstratum/EthStratumClient.cpp and comment out the m_socket.close() call in the reconnect method (line 74, just add // at the beginning of the file). Then rebuild and restart the miner. The reasoning: if we simply don't close the socket, we can't have a fatal exception while trying to close it :)

    Your log indicates another issue with the code though. It looks like two threads on the loose trying to reconnect at the same time, while there should be only one...
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    @Genoil Have commented out line 74 aka m_socket.close() , will give it a try thanks.

    Also seems like the non-crashing miners are switching back and forth to the failover pool more than usual
    More seemingly related but slightly different errors, in case they help diagnose a cause:

    m 13:05:26|main Mining on PoWhash #3a956f22 : 87.56MH/s [A739+8:R1+0:F0]
    i 13:05:28|stratum No new work received in 90 seconds.
    i 13:05:28|stratum Reconnecting in 3 seconds...
    X 13:05:28|stratum Read response failed: The network connection was aborted by the local system
    i 13:05:31|stratum Connecting to stratum server us1.ethpool.org:3333
    i 13:05:31|stratum Connected to stratum server us1.ethpool.org : 3333
    i 13:05:31|stratum Subscribed to stratum server
    i 13:05:31|stratum Authorized worker 0x
    i 13:05:31|stratum Received new job #3a956f22
    m 13:05:32|main Mining on PoWhash #3a956f22 : 89.64MH/s [A739+8:R1+0:F0]
    i 13:05:34|stratum Received new job #2c941554
    i 13:05:34|gpuminer0 set work to: #2c941554, target #0000000112e0be82


    i 13:19:51|stratum Received new job #0721158e
    i 13:19:41| No new work received in 90 seconds.
    i 13:20:02| Reconnecting in 3 seconds...
    i 13:19:46|gpuminer0 Solution found; Submitting to us1.ethpool.org ...
    i 13:20:02|gpuminer0 Nonce: 0x226e5a2ba3e4796e
    X 13:20:02|stratum Handle response failed: The file handle supplied is not valid
    i 13:20:02|gpuminer0 set work to: #0721158e, target #0000000112e0be82
    i 13:20:05| Connecting to stratum server us2.ethpool.org:3333
    Could not resolve hostus2.ethpool.org:3333, The I/O operation has been aborted because of either a thread exit or an application request i 13:20:05| Reconnecting in 3 seconds...
    i 13:20:06|gpuminer4 Solution found; Submitting to us1.ethpool.org ...
    i 13:20:06|gpuminer4 Nonce: 0x603d7e2323620a16
    X 13:20:06|stratum Handle response failed: The file handle supplied is not valid
    i 13:20:08| Connecting to stratum server us1.ethpool.org:3333
    Could not resolve hostus1.ethpool.org:3333, The I/O operation has been aborted because of either a thread exit or an application request i 13:20:08|stratum Reconnecting in 3 seconds...
    i 13:20:11|stratum Connecting to stratum server us2.ethpool.org:3333
    i 13:20:12|stratum Connected to stratum server us2.ethpool.org : 3333
    i 13:20:12|stratum B-) Submitted and accepted.
    X 13:20:12|stratum :-( Not accepted.
    X 13:20:12|stratum Read response failed: End of file
    i 13:20:12|stratum Reconnecting in 3 seconds...
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    It's the work timeout. If the miner works on the same job for over 90 seconds, it assumes something is wrong poolside and fails over. Since the average block time is 15 seconds, I figured a default of 90 would be sufficient. You can increase it using --work-timeout .
  • ethfanethfan Member Posts: 458 ✭✭✭
    edited May 2016
    @Genoil, as I posted earlier, the "Bad file descriptor Aborted" bug did not occur with --work-timeout 10 and the subsequent frequent timeouts (the failover did function with mining switching to the backup server). Did not leave it long enough to see the bug at that setting since the frequent switching must be affecting the shares rate.
    Further to the above I tried --work-timeout 10000. With sufficient time the bug re-surfaced (generally when I am sleeping! - causing hours of missed mining) I am now rolling back to 107...
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @ethfan yes I verified this yesterday on a Linux box, it's not the work timeout causing the bad file descriptor. But it happens during reconnects, becuase the bug is triggered by m_socket.close(); You could try commenting out the m_socket.close() method as I described above. That's the only thing I got working now, but unsure what will happen when a similar situation arises.

    But I can understand that you'd rather mine safely than try stuff.
  • ethfanethfan Member Posts: 458 ✭✭✭
    @Genoil, glad you found the cause. All my rigs on 107 stable >24h. Now going to try your suggestion for a few test rigs...
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    edited May 2016
    @Genoil Still occurring with 1.0.8 rebuilt with m_socket.close() line commented out. (possibly slightly less frequent, but still occurred 3x since on 2 rigs)
    Genoil said:

    Your log indicates another issue with the code though. It looks like two threads on the loose trying to reconnect at the same time, while there should be only one...

    If I read the console correctly when I last reset the miner, there may have somehow been a whopping three threads going.
    Genoil said:

    If the miner works on the same job for over 90 seconds, it assumes something is wrong poolside and fails over. Since the average block time is 15 seconds, I figured a default of 90 would be sufficient.

    I agree 90sec should be fine, they just somehow are not receiving fresh work promptly, even when my other dozen or more miners do. Tried 150 sec, still occurred.
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @Logicaluser what is exactly occuring? Do you still see
    terminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injector<boost::system::system_error >'
    what(): close: Bad file descriptor
    Aborted (core dumped)
    or only the work-timeout happening?
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    edited May 2016
    @Genoil I've not seen those particular errors, upon second look @ethfan's issue may not be related beyond both being issues with the internal stratum and/or 1.0.8

    My issue seems to all start with the errors in this post: https://forum.ethereum.org/discussion/comment/36985/#Comment_36985

    several minutes later the errors progress to this:
    https://forum.ethereum.org/discussion/comment/37030/#Comment_37030

    and finally some time later an endless loop of could not resolve host & IO operation aborted because of thread exit/app request

    I'm puzzled as to why some of my rigs are fine yet others have issues, so I'm going to grab a spare HD today and do a fresh win7 install on one of the problem rigs and see if it changes anything... some of the rigs in question are among my oldest, some using OS installs from the litecoin days.
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    edited May 2016
    @Genoil I suspect that my issue is coming from the 1.0.8 work-timeout, and the rest is the miner behaving badly when faced with frequent back and forth failovers.... perhaps then running into OS-level socket issues? and whatever more-than-expected thread issue you mentioned?

    I did a comparison earlier between 1.0.7, qtminer and 1.0.8, and it seems that at times ethpool actually is serving up the same work for ~2 minutes (even after qtminer's polling for fresh)
    Is it 90 second default for work-timeout? (--help says 60s) Trying with --work-timeout 180 now

    @dr_pra any chance we could find out the longest timespan ethpool & ethermine will serve up the same work when functioning properly?
  • dr_pradr_pra Member Posts: 445 ✭✭✭
    Block times can frequently go up to 90 seconds naturally due to mining variance of the whole network.
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    @dr_pra any suggestions as to how long the default should be until the miner switches to failover pool?
    I've tried looking for data on blocktime outliers without much luck, ethstats.net just shows the past 40 blocks.

    Oh! Thank you Vitalik!
    https://www.reddit.com/r/ethereum/comments/3jf9xy/security_alert_bug_in_go_clients_causing_increase/cuouq5t

    It seems back in September the network was occasionally producing blocktimes well over 120 seconds.... the longest being 273 seconds.
    Guess I'll try --work-timeout 300
  • dr_pradr_pra Member Posts: 445 ✭✭✭
    The value depends on the amount of false positives you are willing to accept. If I find some time I will make a few calculations.
  • lucjagerlucjager Member Posts: 1
    Is there currently a way to increase the speed of a GTX 970 in Windows 10 with the latest drivers?
    Latests drivers ± 5.6 Mh/s
    347.52 drivers ± 19.8 - 20 Mh/s

  • ethfanethfan Member Posts: 458 ✭✭✭
    @Genoil, just to let you know that commenting out the socket call has resulted in rock steady performance. Course that makes me get into other mischief - tearing down rigs and re-arranging my GPU's... and subsequent difficulties. :)
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    edited May 2016
    @lucjager no. It's a WDDM driver issue that I hope will get fixed at some point, but I have no influence on that whatsoever, other than filing bugs with Nvidia. They are well aware of the issue and take it really serious, as it affects all compute apps with random memory accesses on large datasets.

    @ethfan cool. Will leave that commented out then :)

    @Logicaluser Will also increase time-out to 120 secs then.
  • debtofbonesdebtofbones Member Posts: 12
    Needed serious help. Running nvidia 750 ti, Windows 7, ethminer-Cuda 0.9.41. What is up with this hashrate and what am I doing wrong?
  • newkidONdablocknewkidONdablock interwebzMember Posts: 121
    anybody having a 100% CPU with 1.08 while GPU mining?! am I doing something wrong?
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @debtofbones what you're doing "wrong" is trying to mine ETH with a 750Ti on Windows. It just can't be doen any longer due to a combination of driver/ hardware limitations.

    @newkidONdablock that's a lot. Perhaps it's generating a new DAG in the background? But then it's still a lot..
  • newkidONdablocknewkidONdablock interwebzMember Posts: 121
    @Genoil , it pre-generated all it needed, IDK why is it occupying the whole CPU
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @newkidONdablock what CPU, GPUs and command line?
  • newkidONdablocknewkidONdablock interwebzMember Posts: 121
    @Genoil
    intel celeron g3250, 2x280x 2x290
    ethminer.exe --farm-recheck 300 -G -S eu1.ethermine.org:4444 -FS us1.ethermine.org:4444 -O 0x000000000000000000000.rig1 --opencl-platform 1 --cl-global-work 32768 --cl-local-work 256 -R C:\amdDAG\

    happens in both 1.07 and 08
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @newkidONdablock you're not the first one to report this. On my i5 i don't see a notable difference between getwork and stratum. I might do a synchronous stratum client implementation, maybe that helps.
  • newkidONdablocknewkidONdablock interwebzMember Posts: 121
    @Genoil honestly its not a major hasle, although 100% on both cores, the system is responsive and the temps are ok so I was just asking if maybe i accidentaly turned on cpu mining with bad run commands. Thanks for all the effort mate
  • hunk3rhunk3r Member Posts: 4
    edited May 2016
    Fifth day i try to run my 670 with 1.0.8 ethminer (ethminer -F http:... -U), but i have this:

    what's problem? In benchmark "ethminer -M -U" stable 14Mh/s
  • GenoilGenoil 0xeb9310b185455f863f526dab3d245809f6854b4dMember Posts: 769 ✭✭✭
    @hunk3r the problem is windows 10. you could try installing older drivers (350.12 max) but I don't think it makes a difference for Compute 3.0 cards (only 5.2).
  • hunk3rhunk3r Member Posts: 4
    Genoil said:

    @hunk3r the problem is windows 10. you could try installing older drivers (350.12 max) but I don't think it makes a difference for Compute 3.0 cards (only 5.2).

    Thank you for answer. I have win 8.1x64. Which system is better for nvidia mining?
Sign In or Register to comment.