hi nicehash dev, me and my friends getting disconnect problem, around 2 to 3 hours (give or take) we cant connect to Nicehash (or Nicehash disconnect with us), if we want to reconnect we have to reboot modem to get new IP, after modem reboot - got new IP, we can connect to Nicehash just fine (we using dynamic ip internet).
This problem start after DDoS and maybe because of you starting ban IP with too many reject (my reject always 2 to 5% and I tried all the way but cant get my reject lower -if someone know please tell me, thanks), is there anyway for us to avoid this disconnect problem, its really annoying to wake up at night each 2 to 3 hours to reset modem.
P/S: me and my friends live same country but we use diff ISP and we live in diff town so this cant be internet problem.
Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 289. (Read 794394 times)
June 18, 2014, 05:45:12 AM
June 18, 2014, 04:44:15 AM
Should be fine now for all miners that couldn't connect.
We have raised minimal difficulties for both providers and buyers. Providers can now use diff 128 or higher for scrypt, nscrypt, sha256 and keccak, 0.04 or higher for x11 and x13.
Buyers have to use pools that support min diff 32 for scrypt, nscrypt, sha256 and keccak. We are in era of fast ASIC and it is simply unacceptable for pools to still have so low difficulties (imagine how many diff 32 shares a 80MH/s scrypt ASIC sends, if one simple 500KH/s card can already produce 1 share per 10 seconds). If your favorite pool does not support higher diffs, we suggest you to contact them and explain that they are loosing important money on fees that they could gain when just increasing their diff (which is one setting in config file).
We have raised minimal difficulties for both providers and buyers. Providers can now use diff 128 or higher for scrypt, nscrypt, sha256 and keccak, 0.04 or higher for x11 and x13.
Buyers have to use pools that support min diff 32 for scrypt, nscrypt, sha256 and keccak. We are in era of fast ASIC and it is simply unacceptable for pools to still have so low difficulties (imagine how many diff 32 shares a 80MH/s scrypt ASIC sends, if one simple 500KH/s card can already produce 1 share per 10 seconds). If your favorite pool does not support higher diffs, we suggest you to contact them and explain that they are loosing important money on fees that they could gain when just increasing their diff (which is one setting in config file).
June 18, 2014, 02:43:55 AM
Hello
All my miners report that stratum servers for SCRYPT(3333), SHA256(3334), SCRYPT-N(3335) and KECCAK(3338) are dead.
Only X11 and X13 are working. Same for 4xxx ports.
I am located in Slovakia.
I have used traceroute to determine connection and only X11 and X13 returned results.
Anybody can help?
All my miners report that stratum servers for SCRYPT(3333), SHA256(3334), SCRYPT-N(3335) and KECCAK(3338) are dead.
Only X11 and X13 are working. Same for 4xxx ports.
I am located in Slovakia.
I have used traceroute to determine connection and only X11 and X13 returned results.
Anybody can help?
June 17, 2014, 10:47:23 PM
anyone stuck on waiting for work available from the pool
as long as use p=0.7；d=0.01 as passwd and payout rate fall under 0.7
the miner never switch to backup server
please help
as long as use p=0.7；d=0.01 as passwd and payout rate fall under 0.7
the miner never switch to backup server
please help
June 17, 2014, 10:45:56 PM
nicehashdev, I posted a reply for you in the profitability thread, reposting here just in case. This is debugging output from cudaminer.
* Rebuilt URL to: http://stratum.nicehash.com:3333/
* Adding handle: conn: 0x7f994c013e80
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 1 (0x7f994c013e80) send_pipe: 1, recv_pipe: 0
* About to connect() to stratum.nicehash.com port 3333 (#1)
* Trying 91.223.115.35...
* TCP_NODELAY set
* Connected to stratum.nicehash.com (91.223.115.35) port 3333 (#1)
* Connection #1 to host stratum.nicehash.com left intact
[2014-06-18 10:43:23] > {"id": 1, "method": "mining.subscribe", "params": ["cudaminer/2014.02.28"]}
[2014-06-18 10:43:23] stratum_recv_line failed
[2014-06-18 10:43:23] ...retry after 15 seconds
* Rebuilt URL to: http://stratum.nicehash.com:3333/
* Adding handle: conn: 0x7f994c013e80
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 1 (0x7f994c013e80) send_pipe: 1, recv_pipe: 0
* About to connect() to stratum.nicehash.com port 3333 (#1)
* Trying 91.223.115.35...
* TCP_NODELAY set
* Connected to stratum.nicehash.com (91.223.115.35) port 3333 (#1)
* Connection #1 to host stratum.nicehash.com left intact
[2014-06-18 10:43:23] > {"id": 1, "method": "mining.subscribe", "params": ["cudaminer/2014.02.28"]}
[2014-06-18 10:43:23] stratum_recv_line failed
[2014-06-18 10:43:23] ...retry after 15 seconds
June 17, 2014, 10:15:57 PM
I have been providing SHA256 hashing power for some time on the site, but for the last 24 hours my SHA256 miners haven't been receiving any work. I don't have the minimum price set, so i thought it was related to the DDOS attack, but that has passed already. All my SHA256 mining software connect to the site, just no work is being given. So is anyone having these issues??? I also provide x11 hashing power, but that is working just fine. I am located in Japan. Thank you!
Am I the only one with this problem?? i have been provide hash power on SHA256 for quite some time, and now i am not getting anymore work. i have changed nothing on my end, no settings/ports or software. what is going on? my x11 miners are chugging along just fine....
June 17, 2014, 03:45:28 PM
Would it be possible to return orderid when a new order is created with the API?
Will be available with next deployment of frontend.
June 17, 2014, 03:06:41 PM
Would it be possible to return orderid when a new order is created with the API?
June 17, 2014, 01:42:22 PM
We are now running with higher difficulty until the problem is discovered and resolved.
June 17, 2014, 01:24:38 PM
Is there something wrong with the difficulty? Ever since the problems with the X11/X13 yesterday, my difficulty settings are being ignored. I've set d=0.01 but difficulty stays at 0.04.
I've tried changing my difficulty but it stays at 0.04.
I've tried changing my difficulty but it stays at 0.04.
June 17, 2014, 12:06:45 PM
I can not connect my second rig to the 4336/4337 port, while the first one works fine! I have setup the password as follows: f0=0;f2=0;f3=4;f4=3.1;f5=0 So it should switch between x11/x13. Again, it works fine on the first rig while the second rig (same btc adress, same password) can not connect to either 4336/4337 servers. Btw the second rig works fine when set to 3336/3337, but I would like for it to benefit from the switch function of the 4xxx ports too.
June 17, 2014, 10:15:30 AM
Are you using sgminer recommended by NiceHash or something else to mine?
bfminer from hashra. If you want i can give you my btc add so you could check on nicehash stat.
June 17, 2014, 10:13:09 AM
Are you using sgminer recommended by NiceHash or something else to mine?
June 17, 2014, 03:09:29 AM
Hi nicehash.
Great service!
Wanna know,just put 10.2MH on nicehash, but the Round accepted speed MH/s nver reach the entire hashrate of my rig.
He is stable at 5-7 sometimes 8mh,but rig work stable at 10.2MHS.
Is that normal?
Great service!
Wanna know,just put 10.2MH on nicehash, but the Round accepted speed MH/s nver reach the entire hashrate of my rig.
He is stable at 5-7 sometimes 8mh,but rig work stable at 10.2MHS.
Is that normal?
June 17, 2014, 01:52:58 AM
I still can't connect to anything.. no x11, no x13, and no 4xxx ports.... dev got any updates or answers?
June 17, 2014, 01:37:05 AM
my worker 14 hours no payouts, why? work on X13
June 16, 2014, 10:29:33 PM
I have been providing SHA256 hashing power for some time on the site, but for the last 24 hours my SHA256 miners haven't been receiving any work. I don't have the minimum price set, so i thought it was related to the DDOS attack, but that has passed already. All my SHA256 mining software connect to the site, just no work is being given. So is anyone having these issues??? I also provide x11 hashing power, but that is working just fine. I am located in Japan. Thank you!
June 16, 2014, 10:23:44 PM
@brucen
Thank you for your answer. However this doesn't seem to solve my problem. The thing is multi-algo works fine if I run it from cmd. But when i use the same config and run it from Cgwatcher it keeps using ckolivas (which i don't have in my config at all) which ends up in crashing the drivers and just not working etc... I'm pretty sure the problem here is cgwatcher, but i cant monitor multiple rigs without it
Thank you for your answer. However this doesn't seem to solve my problem. The thing is multi-algo works fine if I run it from cmd. But when i use the same config and run it from Cgwatcher it keeps using ckolivas (which i don't have in my config at all) which ends up in crashing the drivers and just not working etc... I'm pretty sure the problem here is cgwatcher, but i cant monitor multiple rigs without it
June 16, 2014, 09:23:41 PM
@Ajeto
Sgminer mutli-algo has to start with a base kernel before it can change to the current multi pool kernel. There is no way to change that because that is how it is designed. You can check it out by writing the config file from the miner when it is running and you will see the pool-kernel in the algorithm section, but there is also a "kernel" : "ckolivas.cl" in the general config section at the bottom. Without the kernal specification on the general config section, it will still revert to the default kernel config when it first compiles the bin file.
What I do is let the miner compile the bin file with the ckolivas kernel, then wait for a minute or so until the multi-algo section compiles. On my system it takes up to 3 minutes before the final bin file is compiled and the miner starts working.
Sgminer mutli-algo has to start with a base kernel before it can change to the current multi pool kernel. There is no way to change that because that is how it is designed. You can check it out by writing the config file from the miner when it is running and you will see the pool-kernel in the algorithm section, but there is also a "kernel" : "ckolivas.cl" in the general config section at the bottom. Without the kernal specification on the general config section, it will still revert to the default kernel config when it first compiles the bin file.
What I do is let the miner compile the bin file with the ckolivas kernel, then wait for a minute or so until the multi-algo section compiles. On my system it takes up to 3 minutes before the final bin file is compiled and the miner starts working.
June 16, 2014, 09:16:33 PM
Anybody have a way to show each rig instead of a summary of total rig?
Jump to: