Author

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

legendary
Activity: 1302
Merit: 1068
Now, why would the efficiency ever be below 100% of LTC, why not mine LTC if it's more profitable?

I'm going to guess that the profitability% is based on expected LTC gain. It is silly to think that we'd be mining something worth 70% of LTCs.

Which means only the overall matters. If the profitability dip under for a bit, it is not relevant.

The reason could simply be that even if we're mining something worth 140% LTC, mining isint garanteed thing. You can get alot of tokens one hour (more than expected) and then for a few hours get less token that expected.

Or not, i just got here. Maybe i don't know what i'm talking about, since i'm just basing this on the stats available on the main page.
newbie
Activity: 4
Merit: 0
I was wondering the same thing.  Add it to the rotation, we have the MH/s for it.  I just started here today, not a good start Sad
newbie
Activity: 40
Merit: 0
Now, why would the efficiency ever be below 100% of LTC, why not mine LTC if it's more profitable?

Terk answered this question a few pages back. Pg. 107
newbie
Activity: 13
Merit: 0
Now, why would the efficiency ever be below 100% of LTC, why not mine LTC if it's more profitable?
legendary
Activity: 1302
Merit: 1068
I'm getting alot of

[2014-03-06 22:02:36] Stratum connection timed out
[2014-03-06 22:02:36] Stratum connection interrupted

this evening.

Is it my connection, my cudaminer or the pool?

Also, When i try to add my cpu's 40khs to my gpu's 170khs, (by running 2 different worker) over the course of the day, the site report i've been doing 130khs(with 9khs wasted). Why does it look like my cpu's khs is being substracted from my gpu's work?

data is slower to show a true picture of lower hash rates because samples are sparse compared to higher hashing set up, so it would be hard to pin down what you are experiencing.  I would start by checking the BTC address in your cpu miner. 

minerd.exe --url=stratum+tcp://us.clevermining.com:3333 --userpass=u:p

Its running, and rarely i get work accepted/rejected on the cpu. So the command line should be fine. This isint an instant thing, this is over the course of a day, the cpu worker doesnt seem to get credited even tho it says work accepted and my khs credited is much lower than what it should be. Like my CPU get 20khs accepted and my GPU 170khs, site says 130khs over the day, 9khs wasted while it should be around 190khs. When i turn off my cpu worker, i get 160khs to 180khs daily average. Seem fair since i get a 172khs accepted average on my miner.

The only thing i see is they are both on same computer so same IP.

Either way, i just shut off my cpu miner, seem to be alot of trouble for little.

I'M more worried about the random DC

[2014-03-06 22:02:36] Stratum connection timed out
[2014-03-06 22:02:36] Stratum connection interrupted
newbie
Activity: 5
Merit: 0
Ok, ASIA and EU servers are UP.... Perfect !!!

Let's think now about a PROFIT !!! 4 days we are more than 30% lower from usual!

Terk you are our HOPE !
newbie
Activity: 33
Merit: 0
I'm getting alot of

[2014-03-06 22:02:36] Stratum connection timed out
[2014-03-06 22:02:36] Stratum connection interrupted

this evening.

Is it my connection, my cudaminer or the pool?

Also, When i try to add my cpu's 40khs to my gpu's 170khs, (by running 2 different worker) over the course of the day, the site report i've been doing 130khs(with 9khs wasted). Why does it look like my cpu's khs is being substracted from my gpu's work?

data is slower to show a true picture of lower hash rates because samples are sparse compared to higher hashing set up, so it would be hard to pin down what you are experiencing.  I would start by checking the BTC address in your cpu miner. 
legendary
Activity: 1302
Merit: 1068
I'm getting alot of

[2014-03-06 22:02:36] Stratum connection timed out
[2014-03-06 22:02:36] Stratum connection interrupted

this evening.

Is it my connection, my cudaminer or the pool?

Also, When i try to add my cpu's 40khs to my gpu's 170khs, (by running 2 different worker) over the course of the day, the site report i've been doing 130khs(with 9khs wasted). Why does it look like my cpu's khs is being substracted from my gpu's work?
hero member
Activity: 616
Merit: 522
Alright, then I have no idea what is causing this. Anyway you can ignore it. It's some problem with cgminer/sgminer and the true stats are per-GPU.
newbie
Activity: 6
Merit: 0
I still have the error "Rejected untracked stratum share from pool 0"

I turn off all of my miners today for some cleaning and swapping ram stick (for better heat dissipation) and still see it when I put it back on.

Using sgminer 4.0.0 though.
newbie
Activity: 33
Merit: 0
Did you reset the stats?

I actually just restarted cgminer completely, and I am still getting roughly 1:1 A:R in the top section of CGMiner's display
hero member
Activity: 616
Merit: 522
Did you reset the stats?
newbie
Activity: 33
Merit: 0
I just restarted sgminer 4.1.0 on win8.1

the untracked errors are still being counted.

 Wink

I second this, rejected untracked at roughly 1:1 to accepted, true reject around 2-3% from Atlanta Ga to Oregon server.
jr. member
Activity: 37
Merit: 1
I just restarted sgminer 4.1.0 on win8.1

the untracked errors are still being counted.

 Wink
hero member
Activity: 616
Merit: 522
I think I know what was causing the “rejected untracked share” error message and I fixed it.

Some miners ask stratum server for transaction list for a mined block. This is unnecessary in stratum protocol as stratum was designed to be able to work without sending the whole transaction list to miners and only sending hashed merkle root. The pool software responded with an error to this get_transaction request and miners were detecting this error as rejected share, but as it wasn't really a rejected share it couldn't match job id with any jobs that were sent so it didn't put it in GPU stats. It still included it in the overall stats at the top.

I changed the error message and error code which is returned for get_transactions and I hope cgminer/sgminer will recognise this response correctly.

If you experienced this issue before, please let me know if this has changed.
sr. member
Activity: 476
Merit: 250
Power to the people!
I will be manually handling high unexchanged balances and address corrections first thing tomorrow morning. I'm sorry for the delay.

Hope its soon my Total Expected has droped from 0.023 to 0.0185 over the last 2 days almost 3 without any payout i had to switch pools so i could get payouts to change over while coins are at a high price.
full member
Activity: 307
Merit: 102
I will be manually handling high unexchanged balances and address corrections first thing tomorrow morning. I'm sorry for the delay.

Thanks for the heads up ^.^

Looking forward to it, the unexchanged will make a nice bonus  Grin
newbie
Activity: 9
Merit: 0
I will be manually handling high unexchanged balances and address corrections first thing tomorrow morning. I'm sorry for the delay.

Thanks for the heads up ^.^
newbie
Activity: 4
Merit: 0
I'd like to +1 the idea of either/and/checkbox for "AVERAGE" or "MEDIAN" numbers on the user stats charts.  I know it's likely down near the bottom of your TODO list Terk, but my excel does this and gives me that mentally, but visually might give the teeming masses some peace of mind Wink.

Also,
I know that 80+ pages back there was mention of the vardiff being something other than 512; with the fast, low diff coins that are in the mixture, 512 is way too large. When is that going to get a look back in? I don't necessarily need a user configurable worksize, but wouldn't it be an easy fix to the system to select a pool worksize commensurate with the speed and difficulty of the coin being mined? All the rejects I get are "job not found" rejects which I don't know what you did with your hack of the backend, but that appears to be the same as the normal error you get when submitting a stale share when the block has changed, just without the hash codes to indicate which job.

To all of you who are whining on about profits:
Middlecoin:     0.0093 BTC/MH over 50 Days
Clevermining: 0.0112 BTC/MH over 30 Days
 
Thanks for the great work Terk!
jr. member
Activity: 37
Merit: 1
n00b question: when checking rejects in cgminer do you look at the R value at the top next to your average overall hashrate? or the R value next to the GPU? because in my case these numbers are drastically different (50% reject vs 2%)

I assume its the per card rate, but is there a reason why I'm getting 50% in the top number?

Your GPU values are the correct values.  The other R is counting Untracked Rejected Shares as well.  Read Terk's explanation a few pages back (p.108).

Cheers.
Jump to: