Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 250. (Read 794394 times)

My miner keeps zero'ing out. Does this mean it keeps disconnecting my miners?

Why?

I am using latest minera with cpuminer for my gridseeds & a second minera using cgdmaxlzeus for my fury.

And I cannot use any proxy for Minera...

Either fix it or Ima have to go back to low profit clevermining.


Not to long ago everything was working terrific.

Don't fix something that aint broke damnit. gah.

I'm using the latest dmaxl cgminer for my Zeus Blizzards and getting good hashing on westhash. you can find it here:

 https://github.com/dmaxl/cgminer/releases

 i set the price and diff in my batch file. seems all ok.

here's my bat file:

cgminer.exe --scrypt -o stratum+tcp://stratum.westhash.com:3333 -u 1CXXXXXXXXXXXz.5 -p p=0.55;d=1024 --failover-only -o stratum+tcp://useast.wafflepool.com:3333 -u 1CXXXXXXXXXXXz -p d=1024 --failover-only -o stratum+tcp://us.clevermining.com:3333 -u 1CXXXXXXXXXXXz -p d=1024 -S //./COM4 -S //./COM29 -S //./COM30 -S //./COM31 -S //./COM32 -S //./COM33 -S //./COM34 --zeus-chips 6 --zeus-clock 340

Your Thunder should be able to run at clock speed of 342. A lot of guys on the Zeus forum recommend that for blizzards to9o...but i find the 340 works best for me.

Hope this is  a bit helpful.

My Antminer S1s and S3s aren't as stable as my Zeusminers on Westhash yet ...but their overall average is slightly better than Eligius and as good as BTCGuild. I think its just the way Antminers function. Will run them through the night.

upsss, i'm sorry, my bad, 

problem solved

so i had to install the proxy for westhash now...since ya must have done something to the servers...cause it all was working fine then poof tons of disconnects..but with the proxy its back to working good...

so with the no rejects part...my thunder unit should get 27mh/s but only avg. 20-21mh/s on here...is that cause of the no reject being counted towards hashrate? so if i was on another pool it'll say around 27mh/s so 6-7mh/s are rejects? that seems really high...also with the proxy you can't append workers and getting 4096 diff rate...which sucks for a 1.4mh/s blizz

EDIT: ok now diff 8192 crazy...so now i'm going to have wild swings on hashrate?
10min later diff rate 16384 ya not going to work well off to find another pool i guess

You order is among scrypt orders: https://nicehash.com/index.jsp?a=0

Common mistake, when you forget to select algorithm

Hi,

i have a little problem, could you check order #52663

it's not executed and not showing in my order,

thank you

Thanks!  Looking at my stats it looks like I'm getting a higher reject % from westhash despite being in North America!  C'est la vie ... I'll just factor the %s into my p= numbers when comparing to pools with lower rejects and payouts.

Thank you for taking the time to write this up, I was thinking along those lines but was too lazy to post it

One problem I couldn't quite figure out is whether it's possible to have an unbalanced supply/demand ratio with this system and how that would affect profitability. The miners would set the nearest server as they do with any other pool and would not have to care about differences in profitability, that's great. What happens if there is  let's say 10 GH/s Scrypt mining power available on the US endpoint, but only 5 GH/s of orders that want that location (including the "do not care" ones). I guess the same thing could happen even with the one server, but now of course it's very likely that there will be a bunch of "just-below-LTC" opportunistic orders to scoop up any excess hashpower. With multiple endpoints we might have many cheap orders on the low-demand endpoint pushing down overall profitability even though there is high demand and lack of supply on another endpoint.

Scantime is useful only for getwork. Nothing you can do here, but to try WestHash (if you are located closer to US West). Job not found are stale shares - your miner is too late.

OK, here is an idea for unifying the service.

First off, have regionalized stratum servers such as northamerica.nicehash.com, europe.nicehas.com, and asia.nicehash.com.  Hash providers should connect their miner to the server with the lowest round trip time.  Would be nice if the NiceHash website provided a tool to help find it.

When a buyer submits an order, they should specify a preferred server to service the order but the order book should be a single list across all of NiceHash.  One additional option would be to allow a buy to limit their order to only being serviced by the specified server or from any available.

As the orders are parceled out, the highest order gets first try at it's specified server.  As you work down the list if an order can't be fully serviced by their specified server then, if they have set the order to allow it, service from any other available server.  Delay and rejects may be higher in this scenario but if a buyer wants to avoid that they can either up their price to get higher in the queue on their preferred server or set the "no float" option and accept that their order may not get run as soon.

With a unified price queue there is not as much incentive for providers and buyers to chase the best price of the moment.  Providers will go to the server closest to them for the best performance.  Buyers will set a preference for their nearest server but will deal with more round trip delay if they are in a hurry to get their order serviced.  Market forces will have a much bigger play here as the higher an order price the quicker it gets serviced across the entire system.

Looks like they're all job not found.  Anyone have any tips on reducing those?  Scantime and expiry I'm guessing?

Can you check what kind of rejects these are? Job not found or something else?

Run buy from original database and use the distributed servers for the forwarding of work.


Also I think It's time we fixed NiceHashDev's trust rating. I have never seen Nicehash screw someone.

~10% rejects with 4.3.5 on the S2 now ... very reasonable!  Great job! 

I'll have to check again ... will let you know!

Important information for ASIC miners

Many ASIC devices are using older versions of mining sofware. Some of these versions are not compatible with NiceHash due to extranonce2-bug (resulting in 99-100% rejects) and most of them doesn't support advanced stratum extranonce subscription for better efficiency (no disconnects).

We have prepared a guide that provides a solution for these issues. By using a lightweight opensource stratum proxy you will be able to overcome the extranonce2-bug and also enable extranonce subscription, resulting in optimal performance and best payouts.

Besides optimal performance and best payouts you'll also get other added value features like single-point management, REST API (pool monitoring, change pool priority, workers stats and much more) and friendly Web-Based client with hashrate graphs.

Take a look at the guide here: https://www.nicehash.com/docs/connect-via-proxy/ and report if it works for you.

Thanks for using NiceHash & WestHash!

wtf！someome has all the price orders,like 0.01-0.50,to control the price!

are you trying the new system? all my miners at 32 diff rate and stat page shows a big dip in hashrate?

well gratz to that email then lol least i can say i was close not knowing anything about running a web server or pool

We got possible solution over email and it goes like that:

We create round rewarding, where for 5 minutes no miner is being paid, but orders are being depleted for each share submitted. At the end of 5 minute time, both stratums report round balance and number of shares. Then each stratum rewards own miners according to number of shares provided in this 5 minute window. This could work and unify prices across both stratums. We will further analyse this idea and implement if it turns out to be a suitable one.