[ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com

[Flep182]

I get it.  Since it's only a $1.65 it's okay for him to steal it, or because he stole more from you two it's okay to steal it from me?  
Or how about it obviously would have been more but I stopped mining there as soon as I realized I wasn't getting paid the full amount?
Or perhaps you two just think it is okay for a pool operator to steal funds from their user's, as long as it isn't that much?  By the way, what's the limit?  2 dollars?  10 dollars?  a hundred?  How much does he have to steal before it isn't okay?  How much has he stolen between me and the other people "missing" transactions?

Or perhaps I am being harsh accusing him of stealing, but then what do you call it when you know you owe someone money and don't pay them for 3 weeks?  I tried to be polite and patient but how long does it take for a pool to pay out if they are competent and honest?  

Anyways, since you two think it is such a trivial amount then I will take you up on your offer to "mail" me the money, please by all means go ahead and send the stol....I mean "stuck" bitcoins to my listed bitcoin address and I will consider the matter closed.  

I'm sure that the competent, honest, polite, and patient person that you are will return this payment once the CleverMining payout comes through. For now though shut the fuck up.

https://blockchain.info/tx/e262807375e97fa17474b3633c2bf8a6894bfbd2eeaccfe7c973be1fadce006e

Thanks for that, and if he doesn't return the money there's always trust rating. Not a single message since btw

[1714203651]

1714203651

[1714203651]

1714203651

[1714203651]

1714203651

[1714203651]

1714203651

[1714203651]

1714203651

[rodeoclownicp]

Ever plan on paying me?  3 weeks would sure seem like plenty of time....

Including your bitcoin address in your post would probably help speed up the support process..

I have already included it a half dozen times.   And been blown off each time.   Along with all the other people who haven't gotten paid either.  His software is obviously borked because I am not the only one having this problem; coins that were earned just stay in "waiting to be exchanged" forever.  Mine have been there for three weeks, others have had this problem longer.  He will eventually come along and promise "to fix it soon, just wait one more week please", at which point nothing will happen.  

I don't know if he is intentionally stealing from his customers, too incompetent to fix his code, or just doesn't give a shit, but eventually your coins will get stuck too just like mine and some other people's, and then you can join us in waiting

Regarding old unexchanged balances.

The pool has ~20 BTC of old unexchanged balance out of over 9500 BTC mined since the pool start, which is only 0.20%. They are some post-fork blocks that got stuck somewhere and automated scripts couldn't resolve their status automatically. I need to manually check and investigate what is the status of these mined blocks. The pool has mined almost 700,000 blocks of dozens different coins since start and there were over a hundred forks which we needed to resolve through, because these new pump-and-dump coins tend to fork a lot. The unexchanged balance are leftovers from forks which couldn't be resolved automatically by our scripts. Some part of this balance are just orphaned blocks and there are no valid coins behind them, so this part will be converted to zero as is any other orphaned block. Some part of this are valid blocks which got stuck somewhere and it will be resolved, exchanged and paid as usual.

I started sorting it manually today and I hope to finish it in this week. This is time-consuming and manual work, so please be patient.

He's not stealing, nor incompetent and does actually give a shit. So don't worry, he won't run away with your precious 1,95 usd.

hey speak about your own money and dont berate forum members in matters that are not your business it doesnt matter if it was 0.000001 pennys... we all know the leaving balance gets stuck and you never get it back... and requests go un-answerred or someone tries saying its not in the "ready for payout"-ya we know,it never will be, which is what people are saying in the first place. the balances should continue to the "ready to pay out" at the same rate they move to "ready to pay out" mining or not- it is suspicious and anybody has the right to point it out that when you never pay out miners after they stop hashing it adds up- and while its adding up, the person who needs to fix it benefits, and the person that benefits just so happens to never fix the problem, but hey nothing to see here move along people. then on top of that people are rude to the guy who wants his own property...?

[Androidicus]

On the subject of d=xxx

If one has, say, two rigs of 4 x GS Blades mining on same BTC address; is the d=xxx based upon the total hash rate at the single address or the 'per blade' or even 'per module' hash rate?

I'm guessing its the total but just want to ensure best outcome...

[jekv2]

Terk, I just want to personally thank you again for implementing manual diff. It is doing wonders, man. I can run my gridseeds @ 128 and my fury @ 1024.

Gridseeds need low diff as the fury needs high diff to keep the hw errors down.

Thumbs up man.

[byt411]

On the subject of d=xxx

If one has, say, two rigs of 4 x GS Blades mining on same BTC address; is the d=xxx based upon the total hash rate at the single address or the 'per blade' or even 'per module' hash rate?

I'm guessing its the total but just want to ensure best outcome...

As far as I understand, it should be per mining software. ex. if you have all the blades running on the same cgminer, then the vardiff is based on the total hashrate, but if they are on seperate controllers, then on every controller.
If you set the d=xxx, you should have to set it for every controller.

[suchmoon]

On the subject of d=xxx

If one has, say, two rigs of 4 x GS Blades mining on same BTC address; is the d=xxx based upon the total hash rate at the single address or the 'per blade' or even 'per module' hash rate?

I'm guessing its the total but just want to ensure best outcome...

It really depends on what you are trying to do. I set all my blades to 512 to make sure that every half-blade submits a share in a reasonable amount of time and that my monitoring software can alert me if no shares were submitted in let's say 10 minutes. There is no hard rule, just try to keep it not too low to avoid saturating your resources.

[Androidicus]

Ok, TY both...

I have 2 on one Pi and 5 on another - both running Starminer which I have found to be very good. Trying 1024 on both confs as all going to one BTC address...

Will see what happens as had v.high rejects on one of the rigs.

...

[gtraah]

I am loosing around 4.5mhs today in this pool, My local hashrate shows perfect but the pool today is reporting 4.5mh lower on the greater part of today On the (Hash Stats Wheel). whats the go with that?

4.5mh is quite alot !

[Exciter666]

Any news about the X11 pool?

[coinflow]

I am loosing around 4.5mhs today in this pool, My local hashrate shows perfect but the pool today is reporting 4.5mh lower on the greater part of today On the (Hash Stats Wheel). whats the go with that?

4.5mh is quite alot !

4.5 MH/sec. of what total rate?

[williamj2543]

Remember, the hash rate on the pool is not the actual hashrate you are getting, but it is calculated based on the amount of shares submitted. Check your mining configuration, and your internet connection.

[byt411]

Remember, the hash rate on the pool is not the actual hashrate you are getting, but it is calculated based on the amount of shares submitted. Check your mining configuration, and your internet connection.

As long as it did not disconnect from the pool, you are earning 100% of what you are supposed to earn.

[williamj2543]

Remember, the hash rate on the pool is not the actual hashrate you are getting, but it is calculated based on the amount of shares submitted. Check your mining configuration, and your internet connection.

As long as it did not disconnect from the pool, you are earning 100% of what you are supposed to earn.

Although if you are having connection problems, less shares could be submitted, leaving you with the same actual hashrate, but less shares submitted to the website, so the site thinks that you have less of a hashrate due to the less shares.

[Master Of Gladness]

No excuse for stuck coins. If blocks are being solved for a coin by any pool then they mature.  Pay up.  If you cant do a manual payouts yourself, just stay away from that pool.
 
I mined at clever but the hashrate I get there after days and days is 5-10% lower than at say coinotron or f2pool and f2pool is like 8000+ miles away.
I test pools with some of my miners for a week or 2, compare payouts and go from there.

1.3Mhs x 5= 5.4 at clever but 6.5-7 or more at another pool when the reject/stale rate is included. I lost a tiny bit of profit during the testing.

vardiff locked at 512 may be the cause but I dont have time to wait for someone to fix their pool.  I leave and check back in a few weeks. ROI is all that is important.

Also, dont be a dick because he may take offense and your $1 will never arrive.

The pool now supports manual difficulty.

NEW! Setup your own difficulty
Our new stratum server has VARDIFF enabled and it should work great for most users. But if you have a miner with dozens of chips working as a single connection you might want to setup your own difficulty. You can do this by using password d=XXXX where XXXX is number between 128 and 65536 (only powers of 2 are accepted, so 128, 256, 512, etc, e.g. d=512). This will set a fixed difficulty and disable vardiff. It works per connection so you can choose separate difficulty for each of your miners.

http://clevermining.com/faq

Some temporary changes to the pool
Temporarily vardiff is disabled and there's a fixed difficulty 512. Fee is at a fixed 2%. The FAQ isn't updated yet to reflect this.

Then why is that up on the site still?

Because there are much more important things to do than updating the stupid faq, such as tweaking the profit engine, fix stuck balances and prepare the x11 multipool?

Attention to detail ever hear of it?  If it is lacking in one place, the odds are other things are missed as well. Try to sorta kinda almost do a job in the real world and see where it gets you.  If I did it in my job, I would be gone and looking for a new job or jail time because people would be DEAD. Design a bridge that collapses at ANY time in its normal useful life and see where it gets you. There is no room for mistakes and sloppy work. I guess you work for the government where clueless people get to keep the job they have and get raises no matter what happens

Lack of attention to detail is why payouts are stuck. 100's of other pools get it right all day long everyday. The there are those who don't even look at the faq. What faqing idiots!

Next,
If the hashrate on your miners is stable then you are ok, If they are jumping all around on one pool and not other pools the flaky pool is the issue not your miners. Pools that change coins cause stops and starts as new work is issued based on the coin that appears to be the most profitable and this will show as a lower hashrate because you are changing work (blocks).

  
 

[byt411]

I am loosing around 4.5mhs today in this pool, My local hashrate shows perfect but the pool today is reporting 4.5mh lower on the greater part of today On the (Hash Stats Wheel). whats the go with that?

4.5mh is quite alot !

 I am having the same issue.

Can you describe your issue more clearly, as in how much hash you are pointing at CM, and how much it reports? This doesn't help...

[Mick2K]

Any updates about X11 pool? I don't like it to have scrypt and X11 on different pools.

[coinflow]

Pools that change coins cause stops and starts as new work is issued based on the coin that appears to be the most profitable and this will show as a lower hashrate because you are changing work (blocks).

I'd also say, that this is the main problem.

It works like this:
The miner is working on a coin, while the pool already switched to another coin. The miner submits the done work to the pool and the pool answers: "Don't give me these results, they are no longer valid, because we are already working on another coin", throws it into the bin, and the submitted work is not counted for your REAL hashrate (the "pool-hashrate"). That explains the difference between what the mining-software shows and what the clevermining-website displays.

I'd say, if a switching-pool could/would solve this problem, the profits would be much higher. Why not let the miner still submit his work for the other coin, counting that as valid, and after that giving him work for the new coin? That should be solvable technically somehow, right?

Edit: If you see this behaviour, that also explains, why setting a high difficulty is not always the best solution. The same goes for the length of the work queue. Though the miner can work better, it takes longer to solve the work, and if the pool switched over to another coin in the meantime, before the miner could submit the results, even the best results don't count. With Vardiff it is the same problem. Vardiff continously adjusts to the possible hashrate of the miner. If you have a monster machine, it sets the share-difficulty high, and when the pool switches over to the next coin, before the work-results were submitted, all is lost and Vardiff then has to readjust. So if the pool switches often, you can really lose quite a lot of your possible profit.
Again, all switching pools should really work out a solution, that allows miners to deliver their work for the previously mined coin first and count that as valid, even if the pool already switched to the next, more profitable, coin.

[emdje]

Pools that change coins cause stops and starts as new work is issued based on the coin that appears to be the most profitable and this will show as a lower hashrate because you are changing work (blocks).

I'd also say, that this is the main problem.

It works like this:
The miner is working on a coin, while the pool already switched to another coin. The miner submits the done work to the pool and the pool answers: "Don't give me these results, they are no longer valid, because we are already working on another coin", throws it into the bin, and the submitted work is not counted for your REAL hashrate (the "pool-hashrate"). That explains the difference between what the mining-software shows and what the clevermining-website displays.

I'd say, if a switching-pool could/would solve this problem, the profits would be much higher. Why not let the miner still submit his work for the other coin, counting that as valid, and after that giving him work for the new coin? That should be solvable technically somehow, right?

Edit: If you see this behaviour, that also explains, why setting a high difficulty is not always the best solution. The same goes for the length of the work queue. Though the miner can work better, it takes longer to solve the work, and if the pool switched over to another coin in the meantime, before the miner could submit the results, even the best results don't count. With Vardiff it is the same problem. Vardiff continously adjusts to the possible hashrate of the miner. If you have a monster machine, it sets the share-difficulty high, and when the pool switches over to the next coin, before the work-results were submitted, all is lost and Vardiff then has to readjust. So if the pool switches often, you can really lose quite a lot of your possible profit.
Again, all switching pools should really work out a solution, that allows miners to deliver their work for the previously mined coin first and count that as valid, even if the pool already switched to the next, more profitable, coin.

+1

[chinatom]

clevemining     delay > 250MS  to china.
waffle            delay < 190MS  to china.

so - - plz.

[fivejonnyfive]

clevemining     delay > 250MS  to china.
waffle            delay < 190MS  to china.

so - - plz.

uh. wat?