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

[Anubite]

3. Regardless of the profitability rate (even with recent Doge and Meow boom) a group of friends and I are still making about half the profit in a 24 hour cycle. We switched to dedicated pools as a test and noticed a considerable difference in payout after converting to BTC.

These coins have random block rewards.

[1714869245]

1714869245

[1714869245]

1714869245

[1714869245]

1714869245

[1714869245]

1714869245

[procrypto]

I mostly use hashco.ws as a failover and don't mine much but am I wasting hashes not staying on the site for more than an hour or 2?

Thanks for any guidance.

You're fine mining for shorter periods, but your earnings may end up spread across subsequent days depending on which rounds you catch.

1. The simple but super useful Profit Diagram was removed from here: https//hashcows/profits.html

2. The "Account Ledger" was moved and disabled. As a result all transparency was lost when reviewing or analyzing payouts.

Agree, we could do with Hashcows bringing those things back asap. If you've checked out the latest news https://www.hashco.ws/news/ the ledger etc is in development. The system was rebuilt entirely after the hack to make it more secure, rendering the old ledger and charts useless. They have been working hard to rebuild and improve, while staying on top of new coin releases. The main dev is also currently squeezing things in around pressing family issues (see the news page).

3. Regardless of the profitability rate (even with recent Doge and Meow boom) a group of friends and I are still making about half the profit in a 24 hour cycle. We switched to dedicated pools as a test and noticed a considerable difference in payout after converting to BTC.

The recent Dogecoin boom is irrelevant as Hashcows barely mined it, unlike before Christmas - this is for reasons discussed elsewhere in the thread. The MEOW boom was great for a few days. Payouts from the first 24-48 hours were spaced across the following days, as the pool mined so many coins that dumping them all at once would've obviously crashed the market.

Trading strategy has to account for situations like that, where a large percentage of freshly mined coins go to Hashcows. In the case of MEOW, this has skewed some miner's perceptions of what they have or haven't got out of it. If you'd stopped mining on Hashcows 48 hours ago you'd have still got a payout yesterday. For a relative comparison to other pools, the first day or so of MEOW on Hashcows worked out at over 0.03BTC/MH/s per day based on ancedotal evidence from the IRC channel.

From a miners perspective rather than purely as a Hashcows fanboy, it makes sense to diversify your mining, if you have multiple rigs and can do so. Hashcows can be a useful part of your strategy due to the way they chase new opportunities, and if you don't mine there at all, you're potentially gonna miss a few epic days - the "off" days are still generating a decent payout in recent times. Splitting your "bread and butter", bill paying hashing power 50/50 with a pool like Middlecoin probably makes good sense, as does saving a little of your firepower for more speculative mining, which can allow you to get out ahead of the big multipools on some coins (while they're worth 0.04BTC/MH/s per day or more).

[jimlite]

What time does hashcows do auto btc payouts?
Seems everyone else does it around 9-10pm eastern.

[aTriz]

Payouts occur at 11:00 EST.

Tonight's payout is slightly delayed 30 mins or so!

[mdtspain]

I keep losing my connection to hashcows constantly.  Is this in my end or is this something that happens?

Phad

* edit * - It happens everytime hashcows switches to a new coin.  There must be a cgminer setting that prevents this.

Same here, thats why I will use hashcows as a backup server

[trasp]

I keep losing my connection to hashcows constantly.  Is this in my end or is this something that happens?

Phad

* edit * - It happens everytime hashcows switches to a new coin.  There must be a cgminer setting that prevents this.

Same here, thats why I will use hashcows as a backup server

Well, to avoid 5 minutes stability check you could go back to version 3.5.0 according to procrypt in #hashcows but if you're compiling cgminer yourself, here's a patch that lowers the retry-time after the pool switches coin down to 5s (instead of 30) and then checks stability for 5-8s:

Code:

--- cgminer.c	2014-01-29 21:56:32.959805084 +0100
+++ cgminer.c-patched	2014-01-30 09:18:41.807082381 +0100
@@ -5553,7 +5553,7 @@
 			while (!restart_stratum(pool)) {
 				if (pool->removed)
 					goto out;
-				cgsleep_ms(30000);
+				cgsleep_ms(5000);
 			}
 			stratum_resumed(pool);
 			continue;
@@ -7083,19 +7083,19 @@
 				pool->testing = false;
 			}
 
-			/* Test pool is idle once every minute */
-			if (pool->idle && now.tv_sec - pool->tv_idle.tv_sec > 30) {
+			/* Test if pool is idle. */
+			if (pool->idle) {
 				cgtime(&pool->tv_idle);
 				if (pool_active(pool, true) && pool_tclear(pool, &pool->idle))
 					pool_resus(pool);
 			}
 
 			/* Only switch pools if the failback pool has been
-			 * alive for more than 5 minutes to prevent
+			 * alive for more than 5 seconds to prevent
 			 * intermittently failing pools from being used. */
 			if (!pool->idle && pool_strategy == POOL_FAILOVER && pool->prio < cp_prio() &&
-			    now.tv_sec - pool->tv_idle.tv_sec > 300) {
-				applog(LOG_WARNING, "Pool %d %s stable for 5 mins",
+				now.tv_sec - pool->tv_idle.tv_sec > 5) {
+				applog(LOG_WARNING, "Pool %d %s stable for >5 seconds.",
 				       pool->pool_no, pool->rpc_url);
 				switch_pools(NULL);
 			}
@@ -7109,7 +7109,7 @@
 			switch_pools(NULL);
 		}
 
-		cgsleep_ms(30000);
+		cgsleep_ms(2500);
 			
 	}
 	return NULL;

On a sidenote, if you're running GNU/Linux and allready have all dependencies installed and ADL_SDK downloaded and unzipped to ~/AMD/ADL_SDK you'd download, patch, configure and compile by something like this:

git clone -b v3.7.2 https://github.com/ckolivas/cgminer.git cgminer-3.7.2
cd cgminer-3.7.2
cp ~/AMD/ADL_SDK/include/*.h ADL_SDK/
wget http://pastebin.com/raw.php?i=zxS1cbmd -O cgminer.c-patch
patch < cgminer.c-patch
./autogen.sh --enable-opencl --enable-scrypt
make

And 'make install' if you want to.

Edit: This should be a very obvious snippet, but otherwise, if you don't know what's going on it's probably good practice to not patch and run stuff you get from this or any other forum about cryptos until someone trustworthy OK'd it. Pastebin apparantly does something to the end of the file that causes 'patch' to throw an error but the file still gets patched and compiles just fine. Also, i updated the patch to lower the time between retrying to set up a new connection.

I could just skip telling you this and take a large(r) chunk of the fast blocks, but I want to support the exchange that show the most transparancy now that... well, some don't.

[kenshirothefist]

To mitigate te disconnects on coin-switches you can definitely do at least these two things (besides the already mentioned --failover-only):

1. use sgminer: https://github.com/veox/sgminer or Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build, you can find it here: http://k-dev.net/cgminer/. They include patches for resilience against pool disconnect with frequent coin switching as well as several other improvements (see http://k-dev.net/cgminer/kalroth-changes.txt)

2. Set appropriate values for scan-time and expiry:
--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: 60)
--expiry|-E <arg> Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)

A good in-the-middle values are:

"scan-time" : "15",
"expiry" : "15",

And even some more aggressive:

"queue" : "5",
"scan-time" : "1",
"expiry" : "1",

BTW: to decrease rejects, you should decrease Intensity. High intensity will hurt low-difficulty altcoins. Go for 13 with dual-thread GPU's (7970, 7990, R9 280) and with 18 with single thread GPU's. Or even beter, use xIntensity with  Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build at a level of xIntensity = 144.

edit: hashcows definitely needs a secondary stratum server ... you can't run a serious pool with just one stratum server

edit: A bit of explanation for "failover-only":
--failover-only: Don't leak work to backup pools when primary pool is lagging
The normal failover mechanism in cgminer will allow some work to go to the backup pools if there is a delay in getting work from the primary pool you have set. This can be as much as 10% if the pool has latency issues. It then only fails to the backup pool if the primary pool stops giving work for 1 minute. failover-only does not change the failover mechanism, but it does not allow work to go to the backup pools unless the primary pool has failed completely for at least a minute. It then will switch to the backup pool. If cgminer considers a pool dead or down, it tries to contact that pool 1 minutely.

Q: Work keeps going to my backup pool even though my primary pool hasn't failed?
A: Cgminer checks for conditions where the primary pool is lagging and will pass some work to the backup servers under those conditions. The reason for doing this is to try its absolute best to keep the GPUs working on something useful and not risk idle periods. You can disable this behaviour with the option --failover-only.

[aTriz]

To mitigate te disconnects on coin-switches you can definitely do at least these two things (besides the already mentioned --failover-only):

1. use sgminer: https://github.com/veox/sgminer or Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build, you can find it here: http://k-dev.net/cgminer/. They include patches for resilience against pool disconnect with frequent coin switching as well as several other improvements (see http://k-dev.net/cgminer/kalroth-changes.txt)

2. Set appropriate values for scan-time and expiry:
--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: 60)
--expiry|-E <arg> Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)

A good in-the-middle values are:

"scan-time" : "15",
"expiry" : "15",

And even some more aggressive:

"queue" : "5",
"scan-time" : "1",
"expiry" : "1",

BTW: to decrease rejects, you should decrease Intensity. High intensity will hurt low-difficulty altcoins. Go for 13 with dual-thread GPU's (7970, 7990, R9 280) and with 18 with single thread GPU's. Or even beter, use xIntensity with  Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build at a level of xIntensity = 144.

edit: hashcows definitely needs a secondary stratum server ... you can't run a serious pool with just one stratum server

edit: A bit of explanation for "failover-only":
--failover-only: Don't leak work to backup pools when primary pool is lagging
The normal failover mechanism in cgminer will allow some work to go to the backup pools if there is a delay in getting work from the primary pool you have set. This can be as much as 10% if the pool has latency issues. It then only fails to the backup pool if the primary pool stops giving work for 1 minute. failover-only does not change the failover mechanism, but it does not allow work to go to the backup pools unless the primary pool has failed completely for at least a minute. It then will switch to the backup pool. If cgminer considers a pool dead or down, it tries to contact that pool 1 minutely.

Q: Work keeps going to my backup pool even though my primary pool hasn't failed?
A: Cgminer checks for conditions where the primary pool is lagging and will pass some work to the backup servers under those conditions. The reason for doing this is to try its absolute best to keep the GPUs working on something useful and not risk idle periods. You can disable this behaviour with the option --failover-only.

Great post, everyone read that for now and listen until we have a permanent fix!

[kenshirothefist]

To mitigate te disconnects on coin-switches you can definitely do at least these two things (besides the already mentioned --failover-only):
...

Great post, everyone read that for now and listen until we have a permanent fix!

Thanks aTriz; BTC welcome at 1LfFJV321RKeUmhRAf9T5VXKreX7Zdm4y7

BTW: if you wan't to mine with pace, here are some usefull monitoring tools for cgminer:

- Nice monitoring tool for local monitoring of your miners (Linux): https://github.com/selaux/miner-dashboard
- Cacti monitoring integration with trully awesome cgminer templates: https://bitcointalk.org/index.php?topic=76502.0
- My own Nagios monitoring integration with some Nagios NRPE plugins: http://files.kobal.org/cgminer/cgminer_nagios_nrpe_checks.zip (check if current hashrate is above treshold and if all GPU's temepratures all below treshold)
- Windows monitoring tool: CGWatcher - a GUI/monitor for CGMiner and BFGMiner: http://manotechnology.blogspot.com/p/cgwatcher.html
- Windows monitoring tool: CGRemote, a remote dashboard for CGMiner and BFGMiner: http://manotechnology.blogspot.com/p/cgremote.html

[gsrcrxsi]

instead of instantaneous numbers for hashrate, can you create some plots that show the values over time?

it would be very helpful to see if there was a gap in hashrate or any other anomalies. would also be interesting to see pool hashrate over time too.

3rd times a charm

[pauldulong]

I use Bitstamp for that, takes 3-5 days

[wondabread]

To mitigate te disconnects on coin-switches you can definitely do at least these two things (besides the already mentioned --failover-only):

1. use sgminer: https://github.com/veox/sgminer or Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build, you can find it here: http://k-dev.net/cgminer/. They include patches for resilience against pool disconnect with frequent coin switching as well as several other improvements (see http://k-dev.net/cgminer/kalroth-changes.txt)

After spending 2 days on hashcows and getting tons of disconnects (without a failover setup) it left me with a miner idle mostly overnight.  I realized it was from coin switching, then read about failover.  I just came here to read about why it seems like I mine all day with no visible progress (problem understood), and wanted to point out that this advice has not only stopped my miner from disconnecting, it actually got me about 100 more khs (with light tweaking).  Kalroth's version of cgminer is fantastic to put it mildly.  I haven't even begun to tweak it seriously yet.

The disconnects would also cause sick gpus which caused some freaking out.  After a few hours of reading and configuring (and emailing kolrath, his read me references .bat files, not .conf files) not only have I not entirely disconnected all day (failover happens occasionaly), but the failover switch delay is configurable (dafaulted to 60 secs) - I set mine at 30 and it works flawlessly.

This is great advice.  I've spent a few weeks learning how to use cgminer, and I could probably spend another few weeks and still not fully understand all the settings, or find my max hash rate.  

moo

[ajpalm]

Cash out pending 1 day 7 hours, Where do i enter a wallet or exchange address to send it to???
Under account settings:
Two-factor authentication is not enabled for your account. Enable two-factor authentication for enhanced account security.
Enable Two-Factor Authentication
Unfortunately we had some 11th hour problems with the 2fa implementation, so at this time it remains disabled. We hope to bring this to everyone in the near future once other site functionality is restored.

i think that's where i would do it but i haven't been in it yet do to that message.

[aTriz]

Cash out pending 1 day 7 hours, Where do i enter a wallet or exchange address to send it to???
Under account settings:
Two-factor authentication is not enabled for your account. Enable two-factor authentication for enhanced account security.
Enable Two-Factor Authentication
Unfortunately we had some 11th hour problems with the 2fa implementation, so at this time it remains disabled. We hope to bring this to everyone in the near future once other site functionality is restored.

i think that's where i would do it but i haven't been in it yet do to that message.

Try here:
https://hashco.ws/modifycoins/

[pengoau]

I keep losing my connection to hashcows constantly.  Is this in my end or is this something that happens?

Phad

* edit * - It happens everytime hashcows switches to a new coin.  There must be a cgminer setting that prevents this.

use middlecoins cgminer version or sgminer reduce the wait to reconnect and resolve ya disconnect issue. Also configure a failover.

http://k-dev.net/cgminer

[TheSmo]

I run cudaminer since 2 hours this morning.

My hashrate (top right says 300 Kh/s and is changing, so it seems it works.
If I click on "My Workers", I see a current hashrae, it's changeing on reloads, so it seems to work.

But my round shares, both accepted and rejected do not change. Of course my payout does not change too.

CudaMiner gives me a lot "accepted x/x" messages, all 99%+ (yay!!! ).

Anyone has an idea?

[coyote]

I run cudaminer since 2 hours this morning.

My hashrate (top right says 300 Kh/s and is changing, so it seems it works.
If I click on "My Workers", I see a current hashrae, it's changeing on reloads, so it seems to work.

But my round shares, both accepted and rejected do not change. Of course my payout does not change too.

CudaMiner gives me a lot "accepted x/x" messages, all 99%+ (yay!!! ).

Anyone has an idea?

Your balance will not reflect coins you have mined until they are a) traded for BTC (in the case of coins you have set to autotrade) and/or b) the rounds have completed and the block has matured (in the case of altcoins you are keeping).

The Estimated Unexchanged balance is currently broken, and the confirmed exchanged balance can be delayed. The only balance you can take as 100% accurate is your actual balance. This balance is updated once per day, when payout occurs at 11pm US Eastern Standard Time.

Occasionally some blocks mined on a specific day will not be part of that day's payout. This could be for a number of reasons, including the time taken for blocks to mature, the time taken for deposits to exchanges like Cryptsy to confirm, and pauses for the best possible moment to trade.

The best way to judge your earnings from [Suspicious link removed] is over the course of a few days mining, as this allows time for all of the above factors, along with variance/luck as is the case with other types of mining pool.

[traumschiff]

Guys, whats the expected (aprox) BTC / MHs / day now? Can anyone help?

[Pajkho]

Does the website work on mobile for anyone?

Seems like the menu button have issues on mobile devices.

[coyote]

Guys, whats the expected (aprox) BTC / MHs / day now? Can anyone help?

Yesterday I got 0.0148 BTC / MHs

hope that helps