nicehashdev
|
|
May 24, 2014, 10:53:58 AM |
|
I had an order pointed at drkpool.com:3333 - 542 GH were accepted, then my order went dead. Gave it two hours, while my physicals miners were working fine with the pool; cancelled and resubmitted the order - losing my non-refundable fee in the process. My physical miners are still running great with the pool, NiceHash has my pool as dead still. Current order is 9235. Not happy That sounds like pool blocked NiceHash. Some pools are still using old techniques and are not adjusted to high speed hashing power. I suggest you contact them and inform about this.
|
|
|
|
scartstorm
Newbie
Offline
Activity: 6
Merit: 0
|
|
May 25, 2014, 07:58:35 AM |
|
Now that the DDOS issues are behind us, how are you systems producing X11? I have about 6-7MH on the X11 algorithm and for some reason for the past 2-3 days, production has been nonexistent. Per day since the 22nd, my gear seems to be producing around 0.003BTC, which is nowhere near the actual amount I should be getting according the prices up on Nicehash.
Before the stat reset after the fight against DDOS, I was pulling in 0.01 BTC per 24 hours consistently.
|
|
|
|
nicehashdev
|
|
May 25, 2014, 10:59:49 AM |
|
Check your stats to see what is going on.
|
|
|
|
Ajeto
Member
Offline
Activity: 97
Merit: 10
|
|
May 25, 2014, 09:23:44 PM |
|
Any idea what difficulty should i set on Raspberry Pi with 5 blades (25 Mh/s)+?
|
|
|
|
phzi
|
|
May 25, 2014, 11:48:07 PM |
|
Any idea what difficulty should i set on Raspberry Pi with 5 blades (25 Mh/s)+?
Presuming you mean share difficulty: Higher if you want less bandwidth consumption, but more variance. Lower if you want higher bandwidth consumption, but less variance. Performance/output will be statistically the same no matter what share difficulty the pool is using. 1 share every few seconds on average is a reasonable target, IMO.
|
|
|
|
p4u
Member
Offline
Activity: 111
Merit: 10
crypto lover
|
|
May 25, 2014, 11:58:46 PM Last edit: May 26, 2014, 12:16:47 AM by p4u |
|
Any idea what difficulty should i set on Raspberry Pi with 5 blades (25 Mh/s)+?
Presuming you mean share difficulty: Higher if you want less bandwidth consumption, but more variance. Lower if you want higher bandwidth consumption, but less variance. Performance/output will be statistically the same no matter what share difficulty the pool is using. 1 share every few seconds on average is a reasonable target, IMO. I would say that higher is always better in reference to the profitability. The RTT (round-trip-time) between the worker and the pool will be something like 30ms (in one of the best scenarios). It means 3% of a second, so 1 share every 2 seconds means 1.5% of penalization (if not using jobs queue of course). The minimum network I/O the better, always. EDIT: actually it will depend on the implementation of the worker client. In if it is blocking until he gets the ACCEPT or not.
|
|
|
|
JHammer
Member
Offline
Activity: 112
Merit: 10
|
|
May 26, 2014, 12:06:25 AM Last edit: May 26, 2014, 01:22:00 AM by JHammer |
|
Is something wrong with Nicehash? I have all 30 MH's pointed here but a lot of my MH's is failing over to my backup pool... Why???
Also getting Large Rejects rate 19.42 (9.88%) WAY High..
Something is wrong with Nicehash.. Heading someone else for a while.
|
|
|
|
JHammer
Member
Offline
Activity: 112
Merit: 10
|
|
May 26, 2014, 02:00:25 PM |
|
Are there not enough orders for my 30 MH's? I am trying to figure out if my fail over to my backup pool is legit as there are not enough orders or is there an issues here with NiceHash or is there an issue with my Fail-over and the way it is working..
We REALLY need more clear easy to read vision on # of orders vs. numbers of miners and when one side or the other is short..
Something simple like..
There are currently Orders for 4.2 TH and there are miners providing 5.2 TH... So there is an overage of 1 TH that will cause some miners here to fail over to their Back up pool.
OP please advise..
Also.. Rejects a lot higher for me than normal. Normal on here has been less then 1%.. Now on here my Reject rate is 13+% Is this a Miner issue or a pool Issue?
|
|
|
|
csa1234
Full Member
Offline
Activity: 289
Merit: 100
O2-Protocol.com Carbon Offset DeFi
|
|
May 26, 2014, 03:06:02 PM |
|
im having some big troubles here, i bought 0.079 BTC x11 hashing power to hash at coinmine.pw .... the pool did not credit any balance or share to my account, i already send several emails to the pool support and also posted my problem at their bitcointalk thread: https://bitcointalk.org/index.php?topic=406178.280Its not fun or fair to loose my hard earning of over 2 weeks in just 20 minutes and nobody reply or look at the situation (the owners) to help, please kindly help me support from nicehash to see if there was share work done on your side so i can have proof to send to the pool owner
|
O2-Protocol.com Carbon Offset DeFi
|
|
|
nicehashdev
|
|
May 26, 2014, 03:20:57 PM |
|
im having some big troubles here, i bought 0.079 BTC x11 hashing power to hash at coinmine.pw .... the pool did not credit any balance or share to my account, i already send several emails to the pool support and also posted my problem at their bitcointalk thread: https://bitcointalk.org/index.php?topic=406178.280Its not fun or fair to loose my hard earning of over 2 weeks in just 20 minutes and nobody reply or look at the situation (the owners) to help, please kindly help me support from nicehash to see if there was share work done on your side so i can have proof to send to the pool owner If your BTC balance was reduced, then work was done. We have our own share validators in place. But if the pool you selected mined coin that does not use X11 coin, then all shares from NiceHash to the pool would be rejected. Are there not enough orders for my 30 MH's? I am trying to figure out if my fail over to my backup pool is legit as there are not enough orders or is there an issues here with NiceHash or is there an issue with my Fail-over and the way it is working..
We REALLY need more clear easy to read vision on # of orders vs. numbers of miners and when one side or the other is short..
Something simple like..
There are currently Orders for 4.2 TH and there are miners providing 5.2 TH... So there is an overage of 1 TH that will cause some miners here to fail over to their Back up pool.
OP please advise..
Also.. Rejects a lot higher for me than normal. Normal on here has been less then 1%.. Now on here my Reject rate is 13+% Is this a Miner issue or a pool Issue?
That sounds like you having connection issues with NiceHash. We did no changes that could reflect this behavior, also there is no one else complaining regarding this. Orders are pretty much irrelevant for providers. You are paid the average price, not the price of order your miner is working on. We changed this distribution to more fair one quite a while ago. You are paid what main page says and what following API says: https://www.nicehash.com/api?method=stats.global.current
|
|
|
|
JHammer
Member
Offline
Activity: 112
Merit: 10
|
|
May 26, 2014, 04:18:18 PM |
|
im having some big troubles here, i bought 0.079 BTC x11 hashing power to hash at coinmine.pw .... the pool did not credit any balance or share to my account, i already send several emails to the pool support and also posted my problem at their bitcointalk thread: https://bitcointalk.org/index.php?topic=406178.280Its not fun or fair to loose my hard earning of over 2 weeks in just 20 minutes and nobody reply or look at the situation (the owners) to help, please kindly help me support from nicehash to see if there was share work done on your side so i can have proof to send to the pool owner If your BTC balance was reduced, then work was done. We have our own share validators in place. But if the pool you selected mined coin that does not use X11 coin, then all shares from NiceHash to the pool would be rejected. Are there not enough orders for my 30 MH's? I am trying to figure out if my fail over to my backup pool is legit as there are not enough orders or is there an issues here with NiceHash or is there an issue with my Fail-over and the way it is working..
We REALLY need more clear easy to read vision on # of orders vs. numbers of miners and when one side or the other is short..
Something simple like..
There are currently Orders for 4.2 TH and there are miners providing 5.2 TH... So there is an overage of 1 TH that will cause some miners here to fail over to their Back up pool.
OP please advise..
Also.. Rejects a lot higher for me than normal. Normal on here has been less then 1%.. Now on here my Reject rate is 13+% Is this a Miner issue or a pool Issue?
That sounds like you having connection issues with NiceHash. We did no changes that could reflect this behavior, also there is no one else complaining regarding this. Orders are pretty much irrelevant for providers. You are paid the average price, not the price of order your miner is working on. We changed this distribution to more fair one quite a while ago. You are paid what main page says and what following API says: https://www.nicehash.com/api?method=stats.global.currentThanks.. Checking with GAW Would connection issues also cause the TONS of rejects I am now getting on HiceHash? Never before yesterday have I gotten so may rejects here(Or anywhere)
|
|
|
|
nicehashdev
|
|
May 26, 2014, 05:15:36 PM |
|
Yes, if there is high delay on connection, you would be getting a lot of stale shares (Job not found).
|
|
|
|
toxic0n
Member
Offline
Activity: 413
Merit: 10
|
|
May 27, 2014, 12:21:17 AM |
|
Hey, everyone! I've made a simple widget for monitoring of my hashrates, balance, etc You can see your current hashrate, reject rate, unpaid balance and even automatically convert the balance to one of the supported currencies. Just type in your BTC address, choose the currency, refresh interval, whether you would like to receive notification for low hashrate and you're ready to go. You can also view the hashrate graph by simply tapping on the widget. This widget supports multiple workers (Scrypt, SHA256, X11, etc) on the same BTC address. Enjoy! https://play.google.com/store/apps/details?id=com.inductiveconcepts.nicehashwidget
|
|
|
|
x8008
|
|
May 27, 2014, 12:36:19 AM |
|
my miners at gawminers are now having crazy amounts of rejects, high percentage.. what is the cause of this?
|
|
|
|
Trimegistus
Legendary
Offline
Activity: 1564
Merit: 1027
|
|
May 27, 2014, 09:11:07 AM |
|
Orders are pretty much irrelevant for providers. You are paid the average price, not the price of order your miner is working on. We changed this distribution to more fair one quite a while ago. You are paid what main page says and what following API says: https://www.nicehash.com/api?method=stats.global.currentIf I understood this statement correctly, then there is no point in setting the minimum price in the password field. We will always get paid by the average price, right? I mean, why should I bother to set the minimum price for SHA hashing at 0.05? Maybe this will cause some unneeded login failures. Am I right? If the sellers are paid always by the average price and not by the price of the order they are currently working on, it won’t make any sense to input minimum prices in the password field, right? We can just input a random low price and we will always get paid by the average as everybody else. Maybe the OP should change the FAQ: "You can limit your miners to work on NiceHash only if the payment is good enough. You can still leave NiceHash as your primary stratum server. NiceHash stratum server will only be activated if there are orders that matches your price threshold. Otherwise miners will work normally on your backup/secondary pool."
|
|
|
|
amacar
|
|
May 27, 2014, 09:32:07 AM |
|
If I understood this statement correctly, then there is no point in setting the minimum price in the password field. We will always get paid by the average price, right? I mean, why should I bother to set the minimum price for SHA hashing at 0.05? Maybe this will cause some unneeded login failures. Am I right? If the sellers are paid always by the average price and not by the price of the order they are currently working on, it won’t make any sense to input minimum prices in the password field, right? We can just input a random low price and we will always get paid by the average as everybody else. Maybe the OP should change the FAQ: "You can limit your miners to work on NiceHash only if the payment is good enough. You can still leave NiceHash as your primary stratum server. NiceHash stratum server will only be activated if there are orders that matches your price threshold. Otherwise miners will work normally on your backup/secondary pool." If average price is 2.8 BTC/GH/Day and you have p=2.7, then your miner will work but if you have p=2.9 then your miner won't work on nicehash.
|
|
|
|
Trimegistus
Legendary
Offline
Activity: 1564
Merit: 1027
|
|
May 27, 2014, 10:10:48 AM |
|
If average price is 2.8 BTC/GH/Day and you have p=2.7, then your miner will work but if you have p=2.9 then your miner won't work on nicehash.
That was my point exactly. After reading the FAQ I thought I could set a number of prices trying to sell my hashing power for the highest value. Namely, I have nicehash as my main pool and also as two of my failover pools. The main pool has a higher price, the second one a lower price and the third one an even lower price. Now I realize I should have only a minimum price because I will always get paid by the average price. Right?
|
|
|
|
amacar
|
|
May 27, 2014, 10:36:52 AM |
|
Now I realize I should have only a minimum price because I will always get paid by the average price. Right?
You are right.
|
|
|
|
odie158
Member
Offline
Activity: 85
Merit: 10
|
|
May 27, 2014, 03:50:07 PM |
|
How did a new order #10152 get ahead of my order #8920 on the sha256 cue at .04btc/th/day. I put my order in days ago and have been waiting for it to come to the top of the cue and to have a new order queued ahead of mine at the same price is unfair.
|
|
|
|
kenshirothefist (OP)
|
|
May 27, 2014, 06:41:37 PM |
|
Am I right? If the sellers are paid always by the average price and not by the price of the order they are currently working on, it won’t make any sense to input minimum prices in the password field, right? We can just input a random low price and we will always get paid by the average as everybody else.
Maybe the OP should change the FAQ:
"You can limit your miners to work on NiceHash only if the payment is good enough. You can still leave NiceHash as your primary stratum server. NiceHash stratum server will only be activated if there are orders that matches your price threshold. Otherwise miners will work normally on your backup/secondary pool."
This faq has truly been obsolete, we've updated it now to reflect the current status.
|
|
|
|
|