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...
Topic: [ANN][Pool][Profit-Switch][Optional Auto-Exchange per Coin][Vardiff] ~ Hashcows - page 164. (Read 347332 times)
October 15, 2013, 01:27:12 AM
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...
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...
October 15, 2013, 01:23:44 AM
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:
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.
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:
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.
Quote
- 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?
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.
October 14, 2013, 10:30:52 PM
So, what has been the payout per Mh ?
October 14, 2013, 09:19:15 PM
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:
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.
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:
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.
Quote
- 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?
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.
October 14, 2013, 04:50:52 PM
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:
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.
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:
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.
Quote
- 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?
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.
October 14, 2013, 12:33:41 AM
Cashouts should not do this...
Successfully queued 0.10825330781448221 BTC for cashout.
It should only send out the last 8 digits and not the whole balance.
Please ensure only the last 8 digits are paid out... the rest can say in the account.
eg:
Successfully queued 0.10825330 BTC for cashout.
Balance Remaining 0.00000000781448221 BTC in holdings.
I know this is petty change, but since BTC is growing over 150$/BTC, who knows... it may hit $100000 in the future and those change will be worth 150$.
Successfully queued 0.10825330781448221 BTC for cashout.
It should only send out the last 8 digits and not the whole balance.
Please ensure only the last 8 digits are paid out... the rest can say in the account.
eg:
Successfully queued 0.10825330 BTC for cashout.
Balance Remaining 0.00000000781448221 BTC in holdings.
I know this is petty change, but since BTC is growing over 150$/BTC, who knows... it may hit $100000 in the future and those change will be worth 150$.
October 13, 2013, 11:46:20 PM
I have noticed that my hash rates are now about 30-40% lower (2 mh/s instead of 3.3mh/s).
Could you make an adjustment on the Vardiff about 30% lower so that the miners are at full tilt mining shares?
Thanks.
Could you make an adjustment on the Vardiff about 30% lower so that the miners are at full tilt mining shares?
Thanks.
October 13, 2013, 03:47:24 PM
Did you take FTC out again?
Right now it seems to be the most profitable to mine, but we are on MEC for a while now.
Right now it seems to be the most profitable to mine, but we are on MEC for a while now.
It's active we just decided to hit it with a profitability hit. We currently think that if a coin is slightly less profitable it would still be better for us to farm it, rather than try to compete with the other multipools and the bigger hash. We will keep our eye on it though.
Roger that
October 13, 2013, 12:59:57 PM
Did you take FTC out again?
Right now it seems to be the most profitable to mine, but we are on MEC for a while now.
Right now it seems to be the most profitable to mine, but we are on MEC for a while now.
It's active we just decided to hit it with a profitability hit. We currently think that if a coin is slightly less profitable it would still be better for us to farm it, rather than try to compete with the other multipools and the bigger hash. We will keep our eye on it though.
October 13, 2013, 12:47:05 PM
Did you take FTC out again?
Right now it seems to be the most profitable to mine, but we are on MEC for a while now.
Right now it seems to be the most profitable to mine, but we are on MEC for a while now.
October 13, 2013, 10:44:28 AM
The issue is fixed, should have your BTC payments now.
Confirmed, got mine! Thanks!
October 13, 2013, 10:42:09 AM
The issue is fixed, should have your BTC payments now.
October 13, 2013, 10:25:32 AM
Something strange is going on.. One of my 2 cards all the sudden started overheating today.. It is getting up to 90+ before CGWatcher shuts it down..
I have never had a over heat issue until today.. They normally both run at 80...
Any ideas?
I have never had a over heat issue until today.. They normally both run at 80...
Any ideas?
Check your GPU fan speed and voltage? Maybe your fan need a little bit of oil
October 13, 2013, 10:23:50 AM
Having the same problem too, is it fixed?
October 13, 2013, 10:18:23 AM
We are aware of the BTC withdraw issues, we are looking into it and will keep you updated.
October 13, 2013, 08:54:09 AM
Automatic payouts not working? My BTC balance is above threshold, but not paid out.
Manual isn't either. I tried withdrawing BTC a few hours ago and again a little while ago and neither went through even though I got the "Queued" green pop up.
October 13, 2013, 06:29:11 AM
Automatic payouts not working? My BTC balance is above threshold, but not paid out.
October 13, 2013, 02:15:30 AM
Hmm. I think the solution is to add more hash....
The more hash we have, the more we will hit the FTC blocks, period.
And now that FTC is here, i'm tempted to switch over my remaining (middlecoin) hash, for which I believe FTC has been a mainstay as relates to their profit numbers.
The more hash we have, the more we will hit the FTC blocks, period.
And now that FTC is here, i'm tempted to switch over my remaining (middlecoin) hash, for which I believe FTC has been a mainstay as relates to their profit numbers.
Do it *nudge nudge*
October 12, 2013, 09:17:10 PM
Hmm. I think the solution is to add more hash....
The more hash we have, the more we will hit the FTC blocks, period.
And now that FTC is here, i'm tempted to switch over my remaining (middlecoin) hash, for which I believe FTC has been a mainstay as relates to their profit numbers.
The more hash we have, the more we will hit the FTC blocks, period.
And now that FTC is here, i'm tempted to switch over my remaining (middlecoin) hash, for which I believe FTC has been a mainstay as relates to their profit numbers.
October 12, 2013, 02:40:36 AM
I see you have added FTC and unfortunately hit some bad luck on your first round
Just to be ahead of people complaining here about wasting their electricity for 40 minutes: it will even out over time.
The next rounds of FTC might hit above average and you won't complain then
I am happy FTC is in there, great work cows.
Just to be ahead of people complaining here about wasting their electricity for 40 minutes: it will even out over time.
The next rounds of FTC might hit above average and you won't complain then
I am happy FTC is in there, great work cows.
Jump to: