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

There was some lag in aggregating shares data from all regional servers and hourly round was created with delay. It should all be fine right now. Nothing has been lost - it just was displayed with delay. The website takes literally previous clock hour to display and if it doesn't have data for this hour yet it will display zeros. I might need to add some notice in these rare cases when our stats are delayed to don't create confusion. Sorry for that.

Look at the line chart below and you should be fine. Sometimes the circle gets screwed up.

same here, probally just a minor glitch. dont see it happen oftn but terk handles it quickly

same happens in my account, something wrong? are we mining or not?

Same here, I was freaking out for a second.

0.0 last hour hashrate.

http://www.clevermining.com/users/12NcNYb2oEh6ANo95AakEjPqQdgbcxh4m9

You might be correct as I've a secondary pool configured for my miners. However it doesn't reports my miners being connected to it. Anyway, I'll reconfigure my miners(deleting secondary pool) and then update after 24 hours of running.

P.S. I don't know what happened(even without reconfiguring my miners) but now my hash-rate is being displayed correctly!!

Well you were writing about


so I didn't have a chance to guess you're talking about 24h averages.

In that case you should read the following post and experiment with manual difficulty which might help: https://bitcointalksearch.org/topic/m.7360436

In short: there are some ASICs with faulty chips which tend to go dead/frozen if new work is sent very frequently (and CM switches coins more aggressively than other pools). Miner's controller probably restarts them if they don't send a share within reasonable time but that reasonable time is probably based on difficulty and expected time to find a share by the chip. The pool's vardiff adjusts difficulty so that your miner find a share very 10 seconds, but if you have dozens of chips inside one miner then it means each of your chip finds a share once per 5-15 minutes. If the miner restarts dead chips after 3x this time of not producing a share, then your chips can be frozen for half an hour before being restarted. If your miner has lot of frequently faulting chips then this will result in lower hashrate (because some of your chips are not working) and hashrate going up and down randomly. This doesn't happen on single-coin pools and doesn't happen on coin-switching pools which are switching coins slower than CM. This also doesn't happen on CM with miners which don't have faulty/freezing chips. Read the above post and try manual difficulty according to what the posts recommends depending on number of chips and check if this will help. It helped most of people who had similar issue.

Amount of your hashrate sent to CM is very inconsistent. This is your daily chart. Your earnings at CM are consistent with your hashrate multiplied by BTC/MHs/day as seen at http://www.clevermining.com/profits/30-days



And this is your last 24 hours hourly chart - you've been mining for most of the day at 2.6-2.7 MH/s and jumped to 5.3-5.4 only two hours ago.



Perhaps you have two 2.7 MH/s miners and one of them is switching to some other pools every now and then? The hourly chart suggests this - this is not some random 10-30% off, it simply looks like one miner connected or two.

Good news So what algos are you planning to add and how soon is that? 

Nothing new here to me.
I'm talking about the reported hashrate over at least 24 hrs. On other pools 80 MH/sec. out of the miner means ~79 MH/sec. reported at the pool side. On your pool it means ~76-78 at best, caused by the massive break-ins (presumably when the coins switch?) and times when the hashrate drops seriously (sometimes even below 70 MH/sec. for a longer time). Wafflepool is the best example on how to use the hashrate the most effective - at least for switching pools (on P2Pools with only one coin the miners output is 82-84 MH/sec. and yields 80-82 net/pool-side hashrate, only to mention it). Aside from the problem, that they only have a reported profitability of ~72% for Scrypt-coins at the moment. But that's another story and not related to the difference between submitted and paid-for hashrate (I hope so, at least ...).

Edit: Just tested your US-server for several hrs, but the result seems to be worse (of course, presumably because of the longer latencies, but you never really know in advance and have to test it), so now switched back to your EU-one.

Hello Terk, thanks for replying. Here's my BTC address: 1CfapZ4MW1GGCeW4U4Q6BEFUBYnR7kegB6 .

Thanks

Thanks for your help, to make good, good work and good day

Then I think you don't understand what is “hashrate reported by the pool”. Let me explain.

The pool doesn't know your hashrate. It can only estimate it based on number of shares which your miner submits, so what the pool shows is only an estimation. You miner knows your exact hashrate because it knows how many hashes it calculated. But it only sends to the pool hashes that meet required difficulty (they're called shares) and the pool estimates your hashrate based on these submitted shares (based on knowledge than it takes X MH/s to find one Y-difficulty share per second). But number of shares which your miner finds varies wildly as mining is a kinda-random game. Sometimes you find 10 shares in a minute, sometimes you won't find even a single share in a minute. If you look at 5-minute values then your hashrate estimated based on shares submitted can jump between 60 and 80 MH/s and even more. The shorter the timespan the bigger the variance.  Just like in throwing a dice. If you throw a dice three times and look at each result individually then you can get 1, 3 and 6. If you throw 30 times and take 10-throw averages then you can get 3, 3.6, 4.1. If you throw it 300 times and take 100-throw averages then you can get 3.4, 3.5, 3.6. It's the same with checking 5-minute, 1-hour and 24-hour mining averages. What you want to compare is 24-hour average, anything less is just too vulnerable to variance.

Big players are actually very beneficial to the pool because they help to reduce variance when we mine high-difficulty coins.

This is simply not possible with the model when covers payout transaction fees with their own money.

The pool earned 0.00001 BTC on your 0.0005 BTC (2%). Sending 0.0005 BTC costs

- 0.00000625 BTC if sent in mass-payout to multiple users or
- 0.0001 BTC if sent manually to one users.

The first would eat 62.5% of what the pool earned.
The second one would mean the pool would need to pay 10x more than it earned just to send you these coins.
And this is the reason why there are payout minimums required to trigger the payout.

You can read more about it here: https://bitcointalksearch.org/topic/m.7420290

8526 Hardware errors are most likely the reason for this. You either have some of your gridseeds broken or you overclock them too much. Try to lower the voltage and get zero hardware errors first. Then start comparing hashrate reported by your miner and by the pool.

Stopping or continuing mining doesn't matter in this issue. It's just easier to notice when you stopped mining. I'm working on these stuck unexchanged/immature balances. Most of them are orphan blocks but the pool software couldn't correctly classify post-fork orphaned blocks as valid or invalid so it left them marked as immature/unexchanged as there was some chance that there were still valid blocks. I'm reviewing this manually to recover valid blocks and will work on improving automated orphans detection in post-fork situations so that such blocks stop stucking as unexchanged.


You should start with vardiff and set fixed difficulty only if you experience issues like lower hashrate than you expected (but if you do, please make sure your miner doesn't report hardware errors as if it does, then it's the most likely reason of lowered hashrate).

You will find more details here: https://bitcointalksearch.org/topic/m.7360436 - in short: vardiff will work best for most miners. If you want to setup fixed diff, please read the linked post first.

You had an error in your address when you first connected to CM: you used 1DkxmLBhjeGaEUSN89yimg3A432JgT6XTo instead of 1DkXmLBhjeGaEUSN89yimG3A432JgT6XTo so you had two letters capitalized wrong. This is how your username was created and what's used for payouts.

I have just renamed your username to the correct value so your should expect a payout tonight.

LOL!

Hurry up then!!!

PS: Great concept. Keep up the good work.