[ANN][Pool][Profit-Switch][Optional Auto-Exchange per Coin][Vardiff] ~ Hashcows

[jedimstr]

Just an FYI.  You may or may not want to upgrade your CGMiner to 3.5.1 and 3.6.1 due to a new feature that waits 5 minutes before switching back to your primary pool if you failed over to your backup pool.  I have HashCows as my Primary and Middlecoin for secondary in CGMiner for my Altcoin miners.  If we mine for 10 minutes on a particular coin, 5 minutes of that I'll be stuck on Middlecoin as backup and lose out on Hashcows.

I raised this with the CGMiner guys on their thread and here's the response so far.  Not encouraging:

With this new feature in 3.5.1:

- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

Sorry but code designed just for altcoin mining takes absolutely last priority.

Fair enough... better than a flat out "no" unless that's what this is.

That said, failover switchback timing doesn't just have to be an "Altcoin" issue.  That was just a symptom.  Making it defeatable so that it can use the previous behavior of switching back to primary pool once that pool is Alive would work.  Either way, just putting it out there.

This goes back to something I and others mentioned earlier in this thread that Hashcows had a relatively significant delay when we switched coins that triggers failover condition if you have backup pools setup.  Don't know if minimizing that delay further would help, but....

Hashcows has been Mooing pretty stably lately, so I may just disable my backup pool for now until the failover switchback timing is resolved.  Don't want to miss any of that sweet sweet Hashcow milk.

UPDATE: I reverted to the 3.5.0 version of CGMiner from git. Seems to be the last version before they implemented the failover switchback timer of 5 minutes.  For what it's worth, I also noticed horrible Hashrates and stability issues on 3.6.1 compared to previous versions for Scrypt mining.

[swiftshoot]

Just an FYI.  You may or may not want to upgrade your CGMiner to 3.5.1 and 3.6.1 due to a new feature that waits 5 minutes before switching back to your primary pool if you failed over to your backup pool.  I have HashCows as my Primary and Middlecoin for secondary in CGMiner for my Altcoin miners.  If we mine for 10 minutes on a particular coin, 5 minutes of that I'll be stuck on Middlecoin as backup and lose out on Hashcows.

I raised this with the CGMiner guys on their thread and here's the response so far.  Not encouraging:

With this new feature in 3.5.1:

- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

Sorry but code designed just for altcoin mining takes absolutely last priority.

Fair enough... better than a flat out "no" unless that's what this is.

That said, failover switchback timing doesn't just have to be an "Altcoin" issue.  That was just a symptom.  Making it defeatable so that it can use the previous behavior of switching back to primary pool once that pool is Alive would work.  Either way, just putting it out there.

This goes back to something I and others mentioned earlier in this thread that Hashcows had a relatively significant delay when we switched coins that triggers failover condition if you have backup pools setup.  Don't know if minimizing that delay further would help, but....

Hashcows has been Mooing pretty stably lately, so I may just disable my backup pool for now until the failover switchback timing is resolved.  Don't want to miss any of that sweet sweet Hashcow milk.

UPDATE: I reverted to the 3.5.0 version of CGMiner from git. Seems to be the last version before they implemented the failover switchback timer of 5 minutes.  For what it's worth, I also noticed horrible Hashrates and stability issues on 3.6.1 compared to previous versions for Scrypt mining.

Suggestion, get 3.5.1 but strip out the new code for the 5 minute failover or reduce the 5 minute failover to 30-60 seconds before compiling.

[Wipeout2097]

So, what has been the payout per Mh ?

[jedimstr]

Just an FYI.  You may or may not want to upgrade your CGMiner to 3.5.1 and 3.6.1 due to a new feature that waits 5 minutes before switching back to your primary pool if you failed over to your backup pool.  I have HashCows as my Primary and Middlecoin for secondary in CGMiner for my Altcoin miners.  If we mine for 10 minutes on a particular coin, 5 minutes of that I'll be stuck on Middlecoin as backup and lose out on Hashcows.

I raised this with the CGMiner guys on their thread and here's the response so far.  Not encouraging:

With this new feature in 3.5.1:

- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

Sorry but code designed just for altcoin mining takes absolutely last priority.

Fair enough... better than a flat out "no" unless that's what this is.

That said, failover switchback timing doesn't just have to be an "Altcoin" issue.  That was just a symptom.  Making it defeatable so that it can use the previous behavior of switching back to primary pool once that pool is Alive would work.  Either way, just putting it out there.

This goes back to something I and others mentioned earlier in this thread that Hashcows had a relatively significant delay when we switched coins that triggers failover condition if you have backup pools setup.  Don't know if minimizing that delay further would help, but....

Hashcows has been Mooing pretty stably lately, so I may just disable my backup pool for now until the failover switchback timing is resolved.  Don't want to miss any of that sweet sweet Hashcow milk.

UPDATE: I reverted to the 3.5.0 version of CGMiner from git. Seems to be the last version before they implemented the failover switchback timer of 5 minutes.  For what it's worth, I also noticed horrible Hashrates and stability issues on 3.6.1 compared to previous versions for Scrypt mining.

Suggestion, get 3.5.1 but strip out the new code for the 5 minute failover or reduce the 5 minute failover to 30-60 seconds before compiling.

Was thinking about that but 3.5.0 was the last stable version for me and I don't see anything really compelling in 3.5.1 change log except maybe the hang on shutdown fix (at least not for GPU scrypt mining). I'd rather hash at a higher rate and have it be able to run for weeks than potentially introduce instability with a half-cooked partial release compile.

[jedimstr]

So, what happened with the usual 23:00 auto payout? Last one I see was for yesterday.

UPDATE: Nevermind... posting at 2:30am is not a good idea.  My brain was ahead by a day and got confused when I saw an older date than expected in the Ledger.... Nothing to see here... Mooooooove along...

[nearmiss]

So, what happened with the usual 23:00 auto payout? Last one I see was for yesterday.

Paid out as usual.  I see a record in your ledger from 2013-10-14 23:00:03.  Are you not seeing similar?

[mindragon]

I'm curious about something. I have about 2.5mh on the pool and the estimated daily earnings are 0.015 BTC at current. This is about the same as I was earning on LTC and trading myself.

If I go to CoinChoose, CoinWarz or just about any of the profitability sites, it says that I should get significantly more than 0.015. In fact, most of them say that I should be earning around 0.1 BTC (not 0.01 BTC).

Can anyone advise as to what is wrong here?

[nearmiss]

I'm curious about something. I have about 2.5mh on the pool and the estimated daily earnings are 0.015 BTC at current. This is about the same as I was earning on LTC and trading myself.

If I go to CoinChoose, CoinWarz or just about any of the profitability sites, it says that I should get significantly more than 0.015. In fact, most of them say that I should be earning around 0.1 BTC (not 0.01 BTC).

Can anyone advise as to what is wrong here?

Perhaps others can chime in with their own numbers, but .015 for 2.5Mh/s is awfully low.  Generally our payouts have been in the range of .017-0.02+ per Mh/s, with a few dips into the high .016's now and then.  Are you seeing an abnormally high number of rejects?

[atp1916]

Disregard the last couple days (rig problems)

This is with ~2.6mhs, with 0 HW errors according to CGMiner.

Also, hello mindragon! 

[mindragon]

From the worker stats page

mindragon.1   YES   827   55   4.46%
mindragon.2   YES   1000   52   4.16%
mindragon.3   YES   639   29   5.72%

I agree that 5% is high but it shouldn't cause such an extreme drop in earnings.

On the LTC pool with same configurations (these are all 7950 and 7970's) I've never had more than .1% rejects.

Edit: Oh Hai ATP! I see you're getting about the same as I am.

[atp1916]

Mind,
This is my payout history for the last few weeks.

Alt mining, even most prof., has been sucking lately.

[mindragon]

Well it's good to see that I'm not insane

MD

[atp1916]

Hell, even on Middlecoin a month ago i was doing .1 est. payout per day.. now if i'm lucky i get .04-.05 here or on any of the other multicoin pools.

That being said, i've found that my only hedge against such bad mining times is lowering my watt usage...and my 7950s REALLY like .95-1.0 @ 950/1350.

Also traded all my 7970s in for 7950s.

[mindragon]

Also here are the CGWatcher stats. So I'll try to do some tweaking today to somehow try to lower the rejects ...

And yes, I run at stock and try to keep temps below 80. That's just how I roll

[atp1916]

There's not much you'll be able to do about the rejects (that's all on the coins), but you got 0 HW errors so you've done really all you can do.

[jedimstr]

So, what happened with the usual 23:00 auto payout? Last one I see was for yesterday.

Paid out as usual.  I see a record in your ledger from 2013-10-14 23:00:03.  Are you not seeing similar?

Nevermind... posting at 2:30am is not a good idea.  My brain was ahead by a day and got confused when I saw an older date than expected in the Ledger.... Nothing to see here... Mooooooove along...

[asor]

I recently started mining, but stopped after some minutes because of 70% reject rate. Any suggestions how to fix this - is there any special cgminer flag/setting required?

[Wipeout2097]

Could you give us an option to set the # of days allowed for auto-trade? I'm afraid that by giving just (less than) a day, that leads to a small window of opportunity, forcing dumps and bad deals.

Thanks

[Thirtybird]

I recently started mining, but stopped after some minutes because of 70% reject rate. Any suggestions how to fix this - is there any special cgminer flag/setting required?

If you were seeing it about the time you posted, it's because the pool was on XenCoin - where 56% reject ratio was normal.  Even with that, it still works out very profitable according to the stats.

[asor]

I recently started mining, but stopped after some minutes because of 70% reject rate. Any suggestions how to fix this - is there any special cgminer flag/setting required?

If you were seeing it about the time you posted, it's because the pool was on XenCoin - where 56% reject ratio was normal.  Even with that, it still works out very profitable according to the stats.

Yep, it was XNC but why is there such a difference between the coins?