Block!!  |
|
|
|
SG and DE node users.
I've tracked down the bug in the node code that caused people to hash into thin air without failing over and have implemented a workaround for it to prevent the cause from happening. In addition I've implemented a change to make it more robust in ckpool itself at disconnecting clients connected to the node but that would warrant a ckpool restart at the main pool which isn't justified at this stage.
Apologies for the lost time when hashing on the SG node. Please give it another go and watch carefully for any issues. Thanks for your patience!
Ok just reconnected to SG node. Let's see if it runs smoothly. |
|
|
|
|
Just noticed my hashrate fell off the chart. Using direct ip for SG node also no good. Same problem as before and my miner also didn't failover. Back to using the main pool node.
|
|
|
|
i see this when i ping sg.kano.is
C:\Users\User>ping sg.kano.is
Pinging sg.kano.is [2400:8901::f03c:91ff:fef1:5056] with 32 bytes of data:
Reply from 2400:8901::f03c:91ff:fef1:5056: time=12ms
Reply from 2400:8901::f03c:91ff:fef1:5056: time=13ms
Reply from 2400:8901::f03c:91ff:fef1:5056: time=14ms
Reply from 2400:8901::f03c:91ff:fef1:5056: time=13ms
Ping statistics for 2400:8901::f03c:91ff:fef1:5056:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 14ms, Average = 13ms
no ip address ?
main kano.is is ok
de is also ok
dash says it's dead & alive time to time but when it's back, miner hangs & does not failover.
That's ipv6 address (2400:8901::f03c:91ff:fef1:5056) This is what I've got Pinging sg.kano.is [139.162.5.112] with 32 bytes of data:
Reply from 139.162.5.112: bytes=32 time=169ms TTL=56
Reply from 139.162.5.112: bytes=32 time=170ms TTL=56
Reply from 139.162.5.112: bytes=32 time=170ms TTL=56
Reply from 139.162.5.112: bytes=32 time=169ms TTL=56
Ping statistics for 139.162.5.112:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 169ms, Maximum = 170ms, Average = 169ms
|
|
|
|
@Kano I'm starting to get these issues again from SG node. "Accepted untracked stratum share from pool 0" "Lost x shares due to no stratum share response from pool 0" Current traceroute snapshot. traceroute to sg.kano.is (139.162.5.112), 30 hops max, 128 byte packets
1 RT-N56U (192.168.1.1) 0.735 ms 0.472 ms 0.270 ms
2 172.22.0.1 (172.22.0.1) 12.356 ms 5.642 ms 3.144 ms
3 103-6-148-37.myrepublic.com.sg (103.6.148.37) 37.225 ms 2.462 ms 2.771 ms
4 103-6-148-13.myrepublic.com.sg (103.6.148.13) 2.852 ms 5.009 ms 3.919 ms
5 63949.sgw.equinix.com (202.79.197.235) 165.467 ms 166.278 ms 165.983 ms
6 139.162.0.6 (139.162.0.6) 164.369 ms 162.777 ms 165.351 ms
7 sg.kano.is (139.162.5.112) 168.665 ms 169.558 ms 168.497 ms
 |
|
|
|
yeah, I am only 3-5ms away from the exchange, I will jog there and give it a good kick  Buy the server a packet of kopi-o. It might be feeling tired, need a different type of kick. |
|
|
|
Yeah had (exactly) the same problem with someone else also.
I'm wondering if there was a network issue in SG somewhere?
(that fixed itself)
SG hash rate stayed up about 87TH but that meant of course there was a drop out of about 30TH (you and the other person)
I'm always connected (from Aus) and there was no drop out from here either.
I guess we'll have to see if it happens again, and make sure you run an mtr/traceroute
Yeah maybe jus a gremlin somewhere on the local national network. SG node was running fine for me since I connected to. No worries. Thanks kano. |
|
|
|
@kano Managed to use my router to do a traceroute traceroute to sg.kano.is (139.162.5.112), 30 hops max, 38 byte packets
1 172.22.0.1 (172.22.0.1) 2.842 ms 3.574 ms 2.809 ms
2 103-6-148-37.myrepublic.com.sg (103.6.148.37) 1.739 ms 2.184 ms 2.830 ms
3 103-6-148-13.myrepublic.com.sg (103.6.148.13) 3.231 ms 2.129 ms 3.587 ms
4 63949.sgw.equinix.com (202.79.197.235) 169.505 ms 171.319 ms 170.766 ms
5 139.162.0.6 (139.162.0.6) 166.933 ms 167.413 ms 169.022 ms
6 sg.kano.is (139.162.5.112) 169.502 ms 168.508 ms 167.880 ms
traceroute to stratum.kano.is (104.194.28.194), 30 hops max, 38 byte packets
1 172.22.0.1 (172.22.0.1) 3.048 ms 2.251 ms 3.202 ms
2 103-6-148-37.myrepublic.com.sg (103.6.148.37) 2.343 ms 1.684 ms 2.764 ms
3 103-6-148-13.myrepublic.com.sg (103.6.148.13) 4.152 ms 2.756 ms 2.084 ms
4 116.51.27.101 (116.51.27.101) 4.736 ms 5.488 ms 5.953 ms
5 ae-1.r20.sngpsi05.sg.bb.gin.ntt.net (129.250.3.146) 2.968 ms 4.664 ms 3.836 ms
6 ae-8.r22.osakjp02.jp.bb.gin.ntt.net (129.250.3.109) 78.554 ms 84.637 ms 83.794 ms
7 ae-8.r21.osakjp02.jp.bb.gin.ntt.net (129.250.6.193) 75.030 ms 88.953 ms 76.144 ms
8 ae-4.r22.lsanca07.us.bb.gin.ntt.net (129.250.2.176) 193.132 ms 180.175 ms 188.132 ms
9 ae-1.r00.lsanca07.us.bb.gin.ntt.net (129.250.3.17) 184.719 ms 182.881 ms 190.035 ms
10 xe-0-0-0-32.r00.lsanca07.us.ce.gin.ntt.net (129.250.202.38) 185.079 ms 189.353 ms 179.787 ms
11 192.228.109.50 (192.228.109.50) 175.558 ms 184.272 ms 178.243 ms
My miner has automatically switched back to the SG node. Seems to be running normal now. |
|
|
|
What actually are you mining with and what's your username - (PM me if you want) There's only a few users on the SG server that make up the ~135TH on there. If you are running linux then do the following 2: mtr --report sg.kano.is
mtr --report stratum.kano.is
Also if you swap to the main pool stratum.kano.is does that make any difference? My userID is MiningAsia. Running Knc Neptune (only 2 cubes out of 5, cgminer 4.9.1). Running windows so can't test those commands. Now mining at main pool (stratum.kano.is), everything running normal. My config: [Main pool]: sg.kano.is:3333 [Failover 1]: stratum.kano.is:3333 [Failover 2]: de.kano.is:3333 |
|
|
|
I'm seeing these messages now (ongoing). Full of such messages. Edit: Restarted my miner. Seeing SG node dead. Mining on main node. |
|
|
|
|
Getting lots of such frequent messages from cgminer while connected to SG node.
"Accepted untracked stratum share from pool 0"
"Lost x shares due to no stratum share response from pool 0"
|
|
|
|
nice ... will be quite beneficial to all us miners on linux when you can compile it in linux ... #crysx +1 for linux support |
|
|
|
lyra2v2 is working here..
(Release 62)
Previously mentioned R62 which didn't run on my machine, I found the problem. It seems CUDA 7 was the problem. I removed it and put in CUDA 6.5 and now everything is ok. |
|
|
|
|
@SP_
Think there is something wrong with lyra2v2 in Release 62. I compiled it on my ubuntu box running 2x 750Ti and get a whole load of errors. Adjusting intensity doesn't make a difference.
[2015-08-30 06:28:14] GPU #0: result does not validate on CPU!
[2015-08-30 06:28:15] GPU #1: result does not validate on CPU!
However running quark is completely fine. I then compiled Release 61 from source and lyra2v2 runs fine.
|
|
|
|
Can anyone tell me how to get a multi GPU rig mining Ethereum with the ethminer-cuda? I have all Nvidia maxwell cards and have tried everything I could to get it to work. Any thoughts? My machines run Windows 8.1 and my .bat file is ethminer -F http://eth2.suprnova.cc:3000/pokeytex.cgar/10 --mining-threads 5 thanks in advance. - pokeytex CUDA SWITCH-- Where is the Cuda switch "-U"? And, at a pool, you normally need your account number, not a user name. You need to generate an account number with Geth, the text-only command line wallet. Check the several CryptoMining Blog articles on how to set up and run Ethminer, several have been linked on recent pages in this thread. If you are running Windows 8.1 and have 750ti cards, you will not get optimal results, only ~1Mh/s per card. There is a known bug. --scryptr @scryptr supurnova.cc uses username.workername, not wallet address like other pools for ethereum. So his .bat file is only missing -U |
|
|
|
And the speed? Any faster?
I compiled for windows with cuda 6.5. There is a windows bug in it, my 750Ti is only at 2.2+MHs instead of the possible 9+MHs. Did you build with debug?  then build release. I think the kernal need some tuning. Might work on it later. I see work has been done by tvprovut in his fork. I always build release. From what I've read on the other forum, the same code works correctly in linux. Others that run in windows get bad hashrates. Whatever the problem is, is beyond my understanding. My system: Win10, Nvidia driver 355.60, CUDA 6.5 windows 10 is the problem, it sends the missing hashes to microsoft's pool haha... |
|
|
|
And the speed? Any faster?
I compiled for windows with cuda 6.5. There is a windows bug in it, my 750Ti is only at 2.2+MHs instead of the possible 9+MHs. Did you build with debug? then build release. I think the kernal need some tuning. Might work on it later. I see work has been done by tvprovut in his fork. I always build release. From what I've read on the other forum, the same code works correctly in linux. Others that run in windows get bad hashrates. Whatever the problem is, is beyond my understanding. My system: Win10, Nvidia driver 355.60, CUDA 6.5 |
|
|
|
And the speed? Any faster?
I compiled for windows with cuda 6.5. There is a windows bug in it, my 750Ti is only at 2.2+MHs instead of the possible 9+MHs. |
|
|
|
|
Show Posts
