phzi
|
|
April 19, 2014, 11:36:51 PM |
|
Had same problem I restarted miner it reconected just fine.
Yup... but this certainly isn't an acceptable solution. I lost a minute of hashing while I was watching my rigs... if I wasn't sitting here, they would probably still be stuck almost an hour later, because there haven't been any new jobs.
|
|
|
|
deznuts
Newbie
Offline
Activity: 44
Merit: 0
|
|
April 20, 2014, 12:02:29 AM |
|
Something is broken with the work queues... With p=9.8 set right now, my rigs connect to the pool, but never receive any work (and will sit idle for a LONG time). It appears that the pool is accepting connections when there is a job at 9.8, but not actually assigning my workers to the job.
I reported this a few days ago and it is still doing it.
|
|
|
|
phzi
|
|
April 20, 2014, 12:49:24 AM |
|
Something is broken with the work queues... With p=9.8 set right now, my rigs connect to the pool, but never receive any work (and will sit idle for a LONG time). It appears that the pool is accepting connections when there is a job at 9.8, but not actually assigning my workers to the job.
I reported this a few days ago and it is still doing it. I seem to have an sgminer patch that fixes this - won't consider a pool alive unless it is supplying work. A bit hacky, but working okay. Will test for a bit.
|
|
|
|
elpsycongro
|
|
April 20, 2014, 12:52:11 AM |
|
Had same problem I restarted miner it reconected just fine.
Yup... but this certainly isn't an acceptable solution. I lost a minute of hashing while I was watching my rigs... if I wasn't sitting here, they would probably still be stuck almost an hour later, because there haven't been any new jobs. Something is broken with the work queues... With p=9.8 set right now, my rigs connect to the pool, but never receive any work (and will sit idle for a LONG time). It appears that the pool is accepting connections when there is a job at 9.8, but not actually assigning my workers to the job.
I reported this a few days ago and it is still doing it. I seem to have an sgminer patch that fixes this - won't consider a pool alive unless it is supplying work. A bit hacky, but working okay. Will test for a bit. do let us know how that works out, and i do agree with you it is not an acceptance solution , i just happened to be watching my rig from work and noticed it idle.
|
|
|
|
greatwolf
|
|
April 20, 2014, 01:50:38 AM |
|
Haha... I was really hoping NiceHash hadn't clued in that someone might try to mine back to the pool =p. Was going to order 1BTC worth of hashing at 7.4BTC/GH, directed back at nicehash with p=9.4 haha.
Guess I have to setup a stratum endpoint if I want to try this little game =p.
But that's like a snake eating its own tail!
|
|
|
|
greatwolf
|
|
April 20, 2014, 02:44:19 AM |
|
My cudaminer isn't authenticating when I set "p=6.0" even though there is live work orders in the 7.1-6.6 range. Why does this happen? It does not appear they're all at their limit so I should be getting work on something.
|
|
|
|
phzi
|
|
April 20, 2014, 03:24:36 AM |
|
My cudaminer isn't authenticating when I set "p=6.0" even though there is live work orders in the 7.1-6.6 range. Why does this happen? It does not appear they're all at their limit so I should be getting work on something.
The live orders in the 6.6-7.1 range are "full". Buyers can limit their orders to a certain GH/s rate. If there are no jobs to join, the server will not show as live. ** (** However, sometimes this is not working correctly (mentioned in this thread a few times), and NiceHash will appear alive but not offer work.)
|
|
|
|
hutnik
Member
Offline
Activity: 95
Merit: 10
|
|
April 20, 2014, 05:40:14 AM |
|
Haha... I was really hoping NiceHash hadn't clued in that someone might try to mine back to the pool =p. Was going to order 1BTC worth of hashing at 7.4BTC/GH, directed back at nicehash with p=9.4 haha.
Guess I have to setup a stratum endpoint if I want to try this little game =p.
Tried that. Got it running. But the problem is, you don't get any workers on your order, and your order won't get to better paying orders than yours. It just sits there ie; Your order will be dead most of the time, because price is not good enough for your miningpower to come alive. If your order is alive, all workers are on better paying orders and not on yours.
|
|
|
|
phzi
|
|
April 20, 2014, 05:45:46 AM |
|
Lol... if I create two identical orders with unlimited hashrate, they seem to alternate. One goes dead, while the other one is alive, and then they switch occasionally.
Edit: ah, and now both are dead. Lame to lose 0.0005BTC x2 lol.
|
|
|
|
dspair
|
|
April 20, 2014, 06:39:28 AM |
|
|
|
|
|
mac-coin
Member
Offline
Activity: 107
Merit: 10
|
|
April 20, 2014, 07:26:46 AM |
|
Just woke up, and my rigs have been sitting there for the last 7 hours. Is there a fixed for this yet, software patch or website, As all the extra I gained by being here was lost and more.
|
|
|
|
phzi
|
|
April 20, 2014, 07:29:51 AM |
|
Buy volume picking up, price heading higher. Was making some good profit buying hashing power for the last few hours.
This site is seriously awesome - like day trading in real hashing power by the GH heh. Sell some power when it's worth it, buy some power when rates fall. Profit!
|
|
|
|
phzi
|
|
April 20, 2014, 09:22:03 AM Last edit: April 20, 2014, 09:53:49 AM by phzi |
|
I am starting to think we need a cap on hashrate... unlimited is causing crazy bidding wars - 1/4 of the pool's total hashrate as a maximum would be nice. Oh wait... I remember how this works now - better point my rigs back here again while the rates are climbing! But really tho, limiting order hashrate to maybe even 1/2 or 1/3 of the pool's total would make things seem more balanced I think. --- Quick jerry rig made bidding on hashrate much less of a pain in the ass: Would definitely suggest something like this be provided by default =).
|
|
|
|
PondSea
Legendary
Offline
Activity: 1428
Merit: 1000
|
|
April 20, 2014, 10:28:19 AM |
|
Yeah there are a few things i dislike.
Firstly as a "renter" it pisses me off i have to keep adjusting as i cant get any miners. I put it at the top rate then someone goes higher. Would be better to have a 10 min minimum or something like that before switching,
Also paying to cancel when i dont want to pay ridiculous rates anymore is just stupid. Why not put a pause option or a reduce fee option?
|
|
|
|
TheMathGuy
Newbie
Offline
Activity: 26
Merit: 0
|
|
April 20, 2014, 02:12:34 PM Last edit: April 20, 2014, 03:03:48 PM by TheMathGuy |
|
Yeah there are a few things i dislike.
Firstly as a "renter" it pisses me off i have to keep adjusting as i cant get any miners. I put it at the top rate then someone goes higher. Would be better to have a 10 min minimum or something like that before switching,
Also paying to cancel when i dont want to pay ridiculous rates anymore is just stupid. Why not put a pause option or a reduce fee option?
No offense but, the people that ''go higher'' obviously have a way to get more out of there hashpower than you do. For example, yesterday people mined whitecoin at ~0.014 BTC/MH/day while renting at ~0.011 BTC/MH/day. I am starting to think we need a cap on hashrate... unlimited is causing crazy bidding wars - 1/4 of the pool's total hashrate as a maximum would be nice.
Then people would just put RoundUp(poolhashrate/max_rentable) amount of oders in at the highest price.. The current system seems fair because it represents an auction. Also the way it works now makes NiceHash approach the maximum profit among all the scrypt coins (of course you have to deduct the 5-25% profit the renter(s) is/are making). This makes NiceHash profitable for the renter, who is out there looking for new/high profitable coins and then proceeds to rent hashrate -> other miner also find this coin and thus the bidding drives the price about 5-25% from this coins actual value (5-25% depending on how well know the coin is/gets) as well as for the miner who gets 75-95% of the current max value at all of the scrypt land without having to perform the staggering day job that is looking for profit in scrypt land. note: don't pin me down on '5-25%' it's hard to do statistics when you don't know the coin people are mining most of the time
|
|
|
|
deznuts
Newbie
Offline
Activity: 44
Merit: 0
|
|
April 20, 2014, 06:23:04 PM |
|
Just woke up, and my rigs have been sitting there for the last 7 hours. Is there a fixed for this yet, software patch or website, As all the extra I gained by being here was lost and more.
They have been trying to fix this for a few days now ever since they introduced the stupid Limited GH/s that has been messing everything up.
|
|
|
|
elpsycongro
|
|
April 20, 2014, 07:33:45 PM |
|
Just woke up, and my rigs have been sitting there for the last 7 hours. Is there a fixed for this yet, software patch or website, As all the extra I gained by being here was lost and more.
They have been trying to fix this for a few days now ever since they introduced the stupid Limited GH/s that has been messing everything up. it is starting to get really irritating, i caught my miner idling 3 times now , it will stay connected but wont freaking do anything , nicehash wont provide work and wont kill the connection.
|
|
|
|
nicehashdev
|
|
April 20, 2014, 07:51:14 PM |
|
Hello. Developer of NiceHash here.
The issue of no work is not caused by NiceHash. It is another bug in cg/sgminer that hasn't been fixed yet. It looks like after several hours of working, cg/sgminer falls into this state. Simple restart of cg/sgminer fixes the issue.
We are planning to create forked versions of: - latest sgminer - cgminer 3.7.2
Which will include: - no work bug fix when price is low - extranonce bug fix of cgminer 3.7.2 so it will be compatible with NiceHash - additional stratum method for changing extranonce1 without reconnect (improved performance of your miners when switching orders)
We will provide source (on github) as well as Windows and Linux (SMOS/BAMT/Ubuntu) binaries.
|
|
|
|
phzi
|
|
April 20, 2014, 08:07:13 PM |
|
Hello. Developer of NiceHash here.
The issue of no work is not caused by NiceHash. It is another bug in cg/sgminer that hasn't been fixed yet. It looks like after several hours of working, cg/sgminer falls into this state. Simple restart of cg/sgminer fixes the issue.
We are planning to create forked versions of: - latest sgminer - cgminer 3.7.2
Which will include: - no work bug fix when price is low - extranonce bug fix of cgminer 3.7.2 so it will be compatible with NiceHash - additional stratum method for changing extranonce1 without reconnect (improved performance of your miners when switching orders)
We will provide source (on github) as well as Windows and Linux (SMOS/BAMT/Ubuntu) binaries.
Make sure to push your changes to veox - he should include them in the sgminer git tree if they don't break anything. Glad to see the situation should improve for miners soon - this site badly needs to focus on attracting some more hashing power at the moment. A few more GH would be rather nice to see. Need moah powwah! *rubs hands together*
|
|
|
|
kenshirothefist (OP)
|
|
April 20, 2014, 09:52:01 PM |
|
Just wanted to let you know that we've updated our front page. We added some more statistics and made it a bit more friendly for new as well as our existing users. Hope you like the update.
Regarding the issues with mining software not being able to get work from NiceHash in some cases. As nicehashdev already explained in his post it's an annoying bug in the cg/sgminer mining software. Despite thorough testing we haven't identified this issue in the beta phase and I'm really sorry for you to face those issues now when we're in production. But rest assure that we're working hard to mitigate these issues in the NiceHash system itself until we provide patches for cg/sgminer sources and provide you with patched windows and linux binaries. This bug doesn't affect all version and all users and appears only in some circumstances. Thanks for understanding!
There are a couple of things you can do to mitigate these issues: - monitor your cg/sgminer mining software and automate restarts when idling (this is recommended anyway, even you're note using NiceHash); - and there is a simple way to bypass this issue if you just set you prices a bit lower (not forcing you to sell beyond your earining expectaions by any means, of course) and thus keep your miner on NiceHash for longer intervals ... keep in mind that even multipools are time-varying in profitability quite a bit so you might not get expected higher profits with high-frequency switching between NiceHash and your backup pool, even if switching would work without the mentioned issues in some cases.
Thanks for using NiceHash.com!
|
|
|
|
|