Author

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

member
Activity: 68
Merit: 13
Great to see the updates put in so quick for the renters! I would also ask for the ability to switch pools without having to cancel/recreate orders (I think thats probably causing the biggest amount of order spam) but I also know with the way your system is setup it might be hard to switch that info without an actual "reset" of the order.

Anyways, great stuff. I like your approach to renting.
hero member
Activity: 700
Merit: 500
I am pretty sure it is not [an average], since my graph says 5.90 at the moment, while countless others have 5.50
Hm, maybe it's just because I have multiple rigs mining here, and they are on different jobs.

--

I think the Speed GH/s measurement is laggy or over a fairly long window.
member
Activity: 74
Merit: 10
HI,

it's possible to add on the stats page the job which are working on ?

Now with the new features to limit the hash power by job, miners are split onto few jobs, so it ccould be interesting to know on which job each miner works no ?
newbie
Activity: 11
Merit: 0
Highest, unlimited, but only 7 miners.  Majority of miners  are on one of the lowest paid tiers.

Miners   Speed GH/s
#492   Alive   6.10   0.13888305   0.01%   1561.21   0.10   0.00   No   7   0.0004
#490   Alive   6.00   0.01839692   5.67%   1.39   15.91   0.06   0.10   80   0.0530
#472   Alive   5.90   0.12783510   29.62%   1.69   787.77   13.61   0.35   161   0.3084
#484   Alive   5.90   0.26161980   9.09%   2.49   383.25   8.34   No   249   0.4266
#486   Alive   5.90   0.09758923   0.32%   31.69   4.58   0.05   0.10   4   0.0125
#485   Alive   5.70   0.48990200   0.00%   ∞   0.00   0.00   0.20   0   0.0000
#475   Alive   5.60   0.09712124   0.80%   ∞   12.05   0.18   0.10   0   0.0000
#481   Alive   5.60   0.19590200   0.00%   ∞   0.00   0.00   0.10   0   0.0000
#483   Alive   5.60   0.97990200   0.00%   ∞   0.00   0.00   0.40   0   0.0000
#489   Alive   5.60   0.09790200   0.00%   ∞   0.00   0.00   0.10   0   0.0000
#436   Alive   5.50   0.71617964   26.91%   4.89   4142.87   113.39   No   355   0.6388
#474   Alive   5.50   0.09790200   0.00%   ∞   0.00   0.00   0.10   0   0.0000
#406   Alive   5.40   0.16885492   17.49%   81.82   572.55   12.39   No   5   0.0092
newbie
Activity: 26
Merit: 0
I certainly hope it's an averaging scheme, where all workers are getting paid for their portion of work completed irrelevant of what task it was on... although that might complicate matters regarding minimum profitability settings.
I'm pretty sure it's not.
15 minutes ago I was mining @ 5.5BTC/GH, now I've been switched to 5.9BTC/GH, even though there is two 6.5BTC/GH orders.
I am actually pretty sure it is an average.  The chart shows my profitability has been fractional amounts like 5.54, 5.88, 6.12, etc since the change, and fluctuating much more rapidly.  Previously it was 5.4 for a while, and then 5.6, back to 5.4, etc.

Last 5 minutes have been at a profitability of 5.75BTC/GH/day.

A very rough average based on GH limit rather then real GH rate would be (6.5*.1)+(5.9*.3)+(5.8*.2)+(5.6*.4)+(5.4*.01) = 5.874.  Which is close enough to make me think the payout rate is definitely an average.

I am pretty sure it is not, since my graph says 5.90 at the moment, while countless others have 5.50

On a different note, is anyone else noticing the random crashes/resets? After a while almost all the hashpower seems to fallback to the unlimited orders, whether they offer more or not.
hero member
Activity: 700
Merit: 500
I certainly hope it's an averaging scheme, where all workers are getting paid for their portion of work completed irrelevant of what task it was on... although that might complicate matters regarding minimum profitability settings.
I'm pretty sure it's not.
15 minutes ago I was mining @ 5.5BTC/GH, now I've been switched to 5.9BTC/GH, even though there is two 6.5BTC/GH orders.
I am actually pretty sure it is an average.  The chart shows my profitability has been fractional amounts like 5.54, 5.88, 6.12, etc since the change, and fluctuating much more rapidly.  Previously it was 5.4 for a while, and then 5.6, back to 5.4, etc.

Last 5 minutes have been at a profitability of 5.75BTC/GH/day.

A very rough average based on GH limit rather then real GH rate would be (6.5*.1)+(5.9*.3)+(5.8*.2)+(5.6*.4)+(5.4*.01) = 5.874.  Which is close enough to make me think the payout rate is definitely an average.
sr. member
Activity: 266
Merit: 250
I certainly hope it's an averaging scheme, where all workers are getting paid for their portion of work completed irrelevant of what task it was on... although that might complicate matters regarding minimum profitability settings.
I'm pretty sure it's not.
15 minutes ago I was mining @ 5.5BTC/GH, now I've been switched to 5.9BTC/GH, even though there is two 6.5BTC/GH orders.
hero member
Activity: 700
Merit: 500
The reject rate on this is horrible. Getting almost a 20% reject using cudaminer 750 ti.
I have been averaging around 5% rejects from western Canada, which is perfectly acceptable for a pool located in the EU (no geo-located stratum endpoints here yet, but apparently coming soon).

please help me understand if i have these calculations right.

if i were to buy hashpower of 0.1 (that's 100mh/s correct?) and spend 5btc at a price of 5btc/day

i would get 100mh/s for 24 hours, is that correct?
.1GH would be 100MH, correct.  If you ordered 5BTC of hashing at .1GH, at a rate of 5BTC/GH/Day, you would get 10 days of 100MH.

also, i would essentially be bidding against other people that are purchasing hash power right? so the higher the price i list, the most likely my offer will get picked up? it looks like there is a wide range of bids, would a bid of say 2.5 btc/day get picked up? it's hard to tell it looks like every bid is being picked up right now.
Yes, you are in a bidding competition for hashing power.  The higher you bid, the higher priority your job has.  Keep in mind, however, that miners can set minimum payout rates.  For example, I have p=5 set, so if there is no work paying >5BTC/GH/day, my miners failover to another pool and won't work on lower paying jobs.  Furthermore, there have been rare few cases where the active jobs have been < 5BTC/GH/day since the pool started, so the chances of a 2.5BTC/GH/Day job getting completely quickly are very slim.

kenshirothefist, can you explain how the hashing power is distributed from the seller's perspective, especially now that there are limits on the GH per job?
I certainly hope it's an averaging scheme, where all workers are getting paid for their portion of work completed irrelevant of what task it was on... although that might complicate matters regarding minimum profitability settings.

If this isn't how it works, then I am going to setup a string of NiceHash failover pools with gradually decreasing minimum profitability, so that I'm always mining the highest paying job =p.

---

Can you please add date/time added (or maybe "Time Waiting") to the current orders table?
full member
Activity: 230
Merit: 100
The reject rate on this is horrible. Getting almost a 20% reject using cudaminer 750 ti.
newbie
Activity: 6
Merit: 0
kenshirothefist, can you explain how the hashing power is distributed from the seller's perspective, especially now that there are limits on the GH per job?

For example, which miners are sent to the highest paying jobs? how is that queue determined? when and under what circumstances do miners move from one job to another? is it first come first serve?

Say for example there are 3 jobs, buying at 5.2, 5.3, 5.4. 5.2 is no limit, and 5.3 and 5.4 are limited to 0.1GH. If a new job comes in at 6.0, limited to 0.1GH, which miners move and how is that determined?

On a related note, is it possible to update the page that shows stats for a specific miner to include what job (and perhaps what rate) the miner is working on? The closest to that info right now is in the graph, but it doesn't update that quickly, and at least for me, the speed and price seem to be at around the same height making it hard to read.

I think you've got a great idea going, and hopefully it keeps getting better and better.

Thanks
sr. member
Activity: 336
Merit: 250
please help me understand if i have these calculations right.

if i were to buy hashpower of 0.1 (that's 100mh/s correct?) and spend 5btc at a price of 5btc/day

i would get 100mh/s for 24 hours, is that correct?

also, i would essentially be bidding against other people that are purchasing hash power right? so the higher the price i list, the most likely my offer will get picked up? it looks like there is a wide range of bids, would a bid of say 2.5 btc/day get picked up? it's hard to tell it looks like every bid is being picked up right now.
member
Activity: 102
Merit: 10
Rockem Sockem
Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

Absolutely agree. Order limiting comming in the next 24 hours! Stay tuned!

From a provider standpoint how will this work? Will you have to pay at least what the current set rate is to use that available hash? I would rather not work on a lower rate before the current higher one is depleted.
member
Activity: 95
Merit: 10
Maybe pay the miners weighted average based on how much hashes are going for what price?

That's some serious math Cheesy

anyway, great service! Smiley
member
Activity: 179
Merit: 10
Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

Absolutely agree. Order limiting comming in the next 24 hours! Stay tuned!

Does it mean that some rigs will mine with profit let's say 5.3 BTC/GH/Day and some with 5.8 BTC/GH/Day? It will not be fair then.
member
Activity: 93
Merit: 250
A another nice feature that you could add is the ability to increase your bid instead of having to cancel the order.
sr. member
Activity: 457
Merit: 273
Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

Absolutely agree. Order limiting comming in the next 24 hours! Stay tuned!
member
Activity: 68
Merit: 13
Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.
legendary
Activity: 2296
Merit: 1031
cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

-snip-
sgminer lacks GridSeed support, i'm more familiar with the cgminer codebase, sgminer dropped SHA suppport and baked in lots of code that makes it difficult to patch in new algorithms, i get better performance from cgminer 3.7.2 with Kalroth's tweaks, sgminer was susceptible to the client.reconnect exploit last time i checked (fixed by this commit in the latest build), R. M. Davidson's patches don't apply to sgminer out of the box, and my build would be a headache to break into pieces to migrate to sgminer + latest cgminer + misc cgminer forks for other algos. "switch to sgminer" may be a fine solution for many, but not for me today. Wink

The bug we're talking about it related to correct handling of extra nonce 2 (extranonce2, xnonce2) size. In cgminer 2.7.2 xnonce is fixed to 4 ... however by stratum protocol this should be "dynamic/resizable". Well, actually you should ask ckolivas for details regarding that ... I'm not sure in which exact version this was patched but if you can find out I'll be very glad if you'd share the info here.
thanks! i'll drop a patch here when i track down the issue and get around to testing fixes.

Well, what we're seeing here with this cgminer-3.7.2 is similar to WinXP story ... to many users of too old software, and when support ends it's "Houston, we've got problems" Wink

-snip-
similar in the sense that a large part of the userbase didn't like the new direction and chose to rebel against it, but this is free software. cgminer 3.7.2 is still actively improved upon, though unfortunately there's a distinct lack of collaboration among devs, (myself included. Roll Eyes)

So you are updating CGminer to work with this pool?  That would be awesome.  I tried SGminer but I don't think it supports both gpu(s) 1/2 at the same time: i.e. my 5870 that runs on GPU threads 1 couldn't run at the same time as my 280x that runs using 2 gpu threads.

I ended up going with bfgminer but I had to scale back the overclock to make it stable and it still isn't stable on one of my rigs so I have to tweak it more. 

Yeah... would be awesome if you are making an update to cgminer.  Anyway I can follow updates/know status?  thx
member
Activity: 61
Merit: 10
cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

-snip-
sgminer lacks GridSeed support, i'm more familiar with the cgminer codebase, sgminer dropped SHA suppport and baked in lots of code that makes it difficult to patch in new algorithms, i get better performance from cgminer 3.7.2 with Kalroth's tweaks, sgminer was susceptible to the client.reconnect exploit last time i checked (fixed by this commit in the latest build), R. M. Davidson's patches don't apply to sgminer out of the box, and my build would be a headache to break into pieces to migrate to sgminer + latest cgminer + misc cgminer forks for other algos. "switch to sgminer" may be a fine solution for many, but not for me today. Wink

The bug we're talking about it related to correct handling of extra nonce 2 (extranonce2, xnonce2) size. In cgminer 2.7.2 xnonce is fixed to 4 ... however by stratum protocol this should be "dynamic/resizable". Well, actually you should ask ckolivas for details regarding that ... I'm not sure in which exact version this was patched but if you can find out I'll be very glad if you'd share the info here.
thanks! i'll drop a patch here when i track down the issue and get around to testing fixes.

Well, what we're seeing here with this cgminer-3.7.2 is similar to WinXP story ... to many users of too old software, and when support ends it's "Houston, we've got problems" Wink

-snip-
similar in the sense that a large part of the userbase didn't like the new direction and chose to rebel against it, but this is free software. cgminer 3.7.2 is still actively improved upon, though unfortunately there's a distinct lack of collaboration among devs, (myself included. Roll Eyes)
Jump to: