Topic: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com - page 103. (Read 554401 times)

Scrypt multipool is kinda dead guys.

Vertcoin just came out with merged mining. I am mining Vertcoin, Monoclecoin, and Parallaxcoin at the same time! My hashes are sent to each blockchain so there is no loss of hash rate. So I am mining 1.25 MH/s Vertcoin, 1.25 MH/s Monoclecoin, and 1.25 MH/s Parallaxcoin. This just came out from the Vertcoin devs on Friday and tons of people are jumping in.

I have a feeling I will be merged mining with 50+ coins soon. ^_^

Well, you don't really explain anything, I'm fine with that.  I'm not sure what you mean by "at least looked at that one line of code".  Yes it depends on chip clock, yes it depends on number of chips, yes, it depends on time per something that's coming from chip info structure (I assume live value) and some constant defined elsewhere.  So what?  Doesn't GPU calculation do essentially the same (GPU clock * number of calc units * some constant * variable time per calc) (I'm sorry I'm too lazy to dig up the actual line of code)?

About betarigs graphs, for GPU what betarigs shows is almost exactly what cgminer shows, for GS what betarigs shows is 5-15% lower than what cgminer shows (and it's worse for larger arrays with higher number of GS pods).  Regardless of your explanation, claimed rig speed has to be adjusted for inefficiency, and for larger gridseed arrays it is higher than for smaller.  When you lease out your rigs, what is the base for the claimed speed?  Do you get it from cgminer/bfgminer or painstakingly calculate based on A: value?

And I ran the suggested experiment, about hour and a half right now (highly unscientific).  Two gridseed rigs, four pods each, same clock etc one pointing to specific coin with difficulty 256-512 and little block restarts, another to clevermining with steady difficulty 512 and lots of restarts.

Current results:
rig 1 (other pool, lower diff, less restarts): A:112384 R:0 WU:4.1
rig 2 (CM pool, higher diff, more restarts): A:105984 R:2048 WU:2.4

about 4% difference including rejects, and so far second rig is not closing in on the first (and first is having plenty of restarts too, bad example actually.)

Maybe you can do the same experiment and report your results?

Multi-pools switch between multiple coins, and some of those coins have a very low-diff and/or a fast block time.  If CM starts mining a low-diff coin, rejects go up because the block find rate is high (so, there is a large percentage of time when a found share will be stale); if it's a fast block coin too (say, <1min block times) this compounds the issue and rejects go even higher.  Every other multi-pool encounters the same thing - WafflePool has periods of 10% reject rate, but settles around 3% overall.

As for 'de-tuning' your rigs - this is expected and necessary.  The optimal tuning for maximum accepted shares varies significantly between coins.  Since a multi-pool is mining many coins, you have to at least partially tune of the lowest common denominator (specifically lower xI values for faster coins).

It's important to note that any decent multi-pool (CM and WP for example), almost certainly consider reject rates in their coin selection algorithms.  So, if you're mining with 10% rejects for a while, that coins is going to be probably 15% more profitable then the next best option (so, 5% more profitable when accounting for rejects).

Heya Terk!

Please understand that I write this after reading all of the associated posts previous, and with what I believe to be a clear understanding of what you have said relating to this issue thus far...


New board member, big fan of what you have accomplished to date with CleverMining. I am fairly new to this whole mining gig, but am a quick study and have two 5MHash rigs running very nicely now with SGMiner 4.1.271.

To make a long story short, I think if you want more hashpower, we HAVE to figure out if there is anything possible that can be done to iron out what arguably seems to be an abnormally high reject rate.

Once I got my machines running stable, I used "Mining Performance Charts" and "PoolPicker" to figure out which pools to try for best BTC/Mhs. I have tried Wafflepool, ScryptGuild, HashCows, CoinFu... Most all of them for at least 24 hours, a few of them a LOT longer, including CleverMining. That said, I am sure a lot of other folks around here have as well.

Hands down, I like the operational feedback and stat presentation of CleverMining above all the rest. Most times the relative profitability too. "And here it comes"...  

But!

So I have been mining with you pretty steady since 4/18 until the bottom dropped out a few days ago (again?) and figured I might try the rig leasing option a bit to see how that goes, so I swapped to NiceHash for a couple of days and did above average there. Now with all of this experimentation, there is no question from my experience that for whatever reason, the only way I can get a slightly above comparable reject rate as I get everywhere else is to start backing down on my xintensity. In my case, I have to back it off about 10% to average around  a 1.5-3% reject rate which is still higher than the .5-2% I average I get almost everywhere else with my optimal settings. No sweat, I can deal... I like your service enough to take a small hit in performance to get "cleaner" work stats and appreciate the rest of what you have to offer... As long as I can get a decent hash/power ratio and come in equal or below the "Montreal/Canada Average Rejected" rate, Im happy...

But I come back to CleverMining this afternoon, and with those same conservative settings I am now averaging 6.6%? As I said before, I truly prefer your service, but it is getting to the point where to get rejects under control, we have to de-tune the rigs to a degree that they are no longer operating anywhere near full capacity for the power we use, and especially so in relation to the rest of the failover options in our conf files.

Please understand that my intent with this post is in no way meant to belittle or criticize your awesome work. You have done an outstanding job thus far and I hope you understand how much we all appreciate your efforts. My intent here is simply an effort to bring to your attention what in my mind is arguably the only hindrance to the growth that I believe CleverMining is capable of. As much as any of us might prefer yours or any other service over the others for any variety of reasons, the bottom line is ROI. From this perspective, throwing away 660Kh in rejects or de-tuning the rigs to basically the same amount of loss in effective hash rate to get rid of the rejects just doesn't seem reasonable when viewed in context with the accept/reject performance of your growing number of competitors. It's like tossing two of your Gridseeds or one of your GPU's (without the corresponding reduction in power) when you use this service because they simply don't count here. As much as you already have over and above the "other guys" with your achievements thus far, this issue is not conducive to our ROI, and therefore your potential for growth. Because of my experience as a software producer I am well aware that you may or may not be able to get a handle on this. But hopefully, with your full attention and proven capabilities, something can be done to address it sooner rather than later.


Thanks for all you do!

Hatch

Of course you cannot submit half shares, that would be an invalid share (reason: below target).  The key here is to realize that no matter what your share difficulty is, each diff 1 share has the same probability of being stale.  Whether you are submitting the equivalent of 512 or 1024 "diff 1 shares" (or any other number of diff 1 shares) at a time, is entirely irrelevant.  Truncating or rounding would never come into calculating these statistics.

I'm going to give up on this. Phzi already gave you a "fingers and toes" example, can get any more basic than that.


Really  I was directly responding to this:


What do you mean then by "cgminer shows"?


I said that you should not trust cgminer's gridseed hashrate, but look at "A:" instead. That was again in response to your statement that "graphs" show 10-15% lower rate than cgminer, and I explained why that could be. Betarigs graphs are based on shares, cgminer numbers are based on inaccurate assumptions. I never said that 300Mhz and 900MHz are the same, or that 10Mh/s somehow equals 1Kh/s. If you had tried the example configurations I gave you or at least looked at that one line of code it would be quite obvious what's going on. If you don't like my explanation that's fine, I'll survive that 

I was not talking about reject rate.  In the screenshots earlier, when block changes, nothing is submitted because share is too difficult and miner didn't have a chance to finish calculation, and A: doesn't increase (neither does R:).


Here goes accusations of "having problems with facts".  I was not even talking about displayed hash rate until you mentioned it.  But are you trying to say that chips hash at the same rate regardless of clock or that 300Mhz chip is equivalent 900MHz chip and they should cost the same?  I hope not.

Or maybe you are trying to say that because hash rate displayed in miner is meaningless nobody should ever care about it?
And if that's the case, I'll gladly rent your 10Mh/s rig and pay for 1kh/s.


Now this is interesting.  I think that in second calculation you have to truncate, you cannot submit half of share, is that correct?  So resulting diff 1 shares will be Trunc( 5 - 0.5 ) * 1024 = 4096, is it not?  I mean it will probably work out in a longer (much longer) run but not in a short one.

I'm going to try an experiment...

Reject percentage will be statistically the same no matter what the difficulty - the time window in which you may mine a stale share remains exactly the same irrelevant of share diff.  So, accepted work will be statistically the same.  Look at it this way, if you on average have 10 shares per minute at 512, then you have 5 shares per minute at 1024.  If you have 6 seconds every 60 seconds where you are mining old work (which will result in a stale shares if a share is found), then on average 1/10th of all work will be stale (6/60 = 1/10).  Therefore, you would have on average (10-(10/10))*512 = 4608 diff 1 shares at diff 512, and (5-(5/10)*1024 = 4608 diff 1 shares at diff 1024. Note, they are exactly the same.

Conclusion: difficulty only affects short-term variance.  Statistically, it has NO affect on profits.

Reject rate does not depend on pool difficulty. In the long term you will be getting the same reject rate (percentage) at diff 512 or diff 1024 or diff 1, all other things being equal.

You seem to be thinking that there is a "duration" to solve a share. There is no duration, only a probability of any given hash meeting the specified difficulty.


I just stated a fact. I even gave you an example to try if you don't believe me, since you seem to have a problem with facts. You can tell cgminer to run your Gridseed at a frequency it is not capable of running at, and cgminer will happily report a high hashrate, even though submitted shares will be low if any. You can also give cgminer an incorrect number of chips and it will report an incorrect hashrate. It does not count the actual hashes generated, it just assumes that a Gridseed at X frequency with Y chips will produce Z hashes. Here is the relevant line of code in dtbartle's cgminer, which most if not all Gridseed cgminer clones are based on:

https://github.com/dtbartle/cgminer-gc3355/blob/master/driver-gridseed.c#L705

Because there are what we call "Fake Rejects", which are displayed as "Rejected Untracked Stratum share on pool 0", which is basically just a communication error between miner and pool.

Ah I see it. Wonder why it said 17.3% then .

Not sure you understand what I'm saying so here it is.  Share of difficulty of 1024 takes twice as long as difficulty 512 (approximately), right?

So let's assume that diff 1024 takes a second to solve, and 512 half-second; then in a minute miner ideally solves 60 1024 diff shares or 120 512 diff shares and total is the same (60 * 1 * 1024 = 120 * 1 * 512 = 61440).
Then let's assume that only 90% of 1024 shares are accepted, and 95% of 512 diff shares (due to block changes etc).  Then accepted work during a minute (or any other period of time) is not the same (60 * 0.9 * 1024 = 55296 < 120 * 0.95 * 512 = 56386).

So in ideal case it does average out, but that is not my point.  It does not "average out" when rejection rate is different depending on difficulty and this is what it looks like to me in case of gridseeds.  Where am I wrong?

Regarding "speed" that cgminer shows for gridseeds, well, there should be a reference point, right?  There is the advertised speed, that is used in comparisons, and pricing of hardware, and dismiss it as "fake" is not really correct.

You, sir, are very correct. That's exactly how it works. So 2 x 512 = 1 x 1024.
Get it mneehon?

cgminer already shows shares submitted as "difficulty 1", i.e. multiplied by pool difficulty. In other words, if pool diff is 512 and it accepts a share, cgminer's "A:" will increase by 512, if pool is VARDIFF then "A:" will increase by whatever the diff is at that time. So that part is already taken care of and my point still stands - run it for 24 hours, check the "A:", compare it to whatever your benchmark is.

P2Pools settings and VARDIFFs exist mainly to produce smooth hashrate charts and to reduce server load (higher diff = fewer worthless shares for the server to deal with).

Not sure I get your point about Betarigs - are you the rig owner or the renter? If you're are the renter, then the rig owner is overstating the hashrate, if you're the owner - well...

Keep in mind that cgminer for gridseeds shows the theoretical hashrate based on the number of chips and frequency. Try setting freq=1000 or chips=2 and you'll see what I mean. In other words, it's meaningless. Use "A:".

In the picture you provided your real reject rate is shown on the same line as the hashrate and it's around 2%.

Ah I didn't realise profitability had decreased so much in this time. I'll probably just mine in winter to keep me warmer lol.

I stick to an intensity of 10 so the system does not become unresponsive.


edit: I just shut it down and "Reject Ratio: 17.3%" seems rather high, doesn't it? This had been running all night and then all day at the point I stopped it.

Well, no. 2 512 shares = 1 1024 share. The 24 hour average, regardless of difficulty, should be nearly the same.

Rejects are still the same, if not more with low difficulty, since stales are very easily produced.

I wonder if you can show that "basic math" you are talking about.  I believe that if share is not submitted, it cannot be "replaced" by twice the shares during the same size time slot later because miner doesn't generate shares, it accepts work from pool.  One has to count how many shares are submitted in 24 hours when share difficulty is e.g. 64, and then count how many shares are submitted in 24 hours when share difficulty is 1024, and then compare these two numbers taking into account share size.

You are assuming that these two numbers are the same.  There is no way to test your assumption without the ability to manually set difficulty.  I'm pretty positive than due to larger number of rejected/stale shares at higher difficulty, average for 24 hours will be lower at difficulty higher than miner can handle.  Isn't that the reason VARDIFF exists and p2pools have a parameter where you can specify desired difficulty?

Also looking at graphs on betarigs (damn those graphs) I can clearly see that GPU that I lease shows accepted average rate within 0-1% of what cgminer shows, whereas 8-10 pods gridseed rigs consistently show accepted average rate 10-15% lower than what cgminer shows.

Profitability has decreased significantly since December. You can expect ~0.003 BTC per day per MH/s at this time, and you only have 0.07 MH/s, so this works out to about 0.0002 BTC per day.

You screenshot shows intensity 10, you might want to increase that.

If you can do basic math you don't have to "buy" anything. Let it run for 24 hours, check the stats. Gridseeds work fine even at 1024 diff given enough time.