404 Not Found
I get this error when I try to look at the hashcows website, and when I try to mine it says "connection problems". Mining another pool for the time being but you guys have been phenominal the past week so please get someone on this ASAP! (Unless this is scheduled maintenance or something, in which case ignore the panicky idiot).
Topic: [ANN][Pool][Profit-Switch][Optional Auto-Exchange per Coin][Vardiff] ~ Hashcows - page 37. (Read 347329 times)
January 31, 2014, 12:00:58 PM
January 31, 2014, 11:43:43 AM
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?
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.
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.
Thank you, but it also doesn't display any shres too? So for me it looks like it's not getting anything from the miner?
January 31, 2014, 10:39:26 AM
Guys, whats the expected (aprox) BTC / MHs / day now? Can anyone help?
Yesterday I got 0.0148 BTC / MHs
hope that helps
Yes it does, tyvm. Was mining doges but since the new wallet it seems so random also higher diff now.
~0.014 seems good for a day
January 31, 2014, 10:38:06 AM
Does the website work on mobile for anyone?
Seems like the menu button have issues on mobile devices.
Seems like the menu button have issues on mobile devices.
The menu button doesn't seem to work too well on mobile browsers. I use the URLs
/stats/ for Statistics
/news/ for News
/workers/ for Workers
/balances/ for Coin Balances
January 31, 2014, 10:34:53 AM
Guys, whats the expected (aprox) BTC / MHs / day now? Can anyone help?
Yesterday I got 0.0148 BTC / MHs
hope that helps
January 31, 2014, 10:10:15 AM
Does the website work on mobile for anyone?
Seems like the menu button have issues on mobile devices.
Seems like the menu button have issues on mobile devices.
January 31, 2014, 09:59:18 AM
Guys, whats the expected (aprox) BTC / MHs / day now? Can anyone help?
January 31, 2014, 08:30:07 AM
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?
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.
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.
January 31, 2014, 06:40:22 AM
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?
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?
January 30, 2014, 10:48:59 PM
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.
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
January 30, 2014, 10:44:52 PM
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.
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/
January 30, 2014, 09:19:27 PM
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.
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.
January 30, 2014, 04:36:13 PM
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)
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
January 30, 2014, 04:24:35 PM
I use Bitstamp for that, takes 3-5 days
January 30, 2014, 12:11:49 PM
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.
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
January 30, 2014, 12:04:23 PM
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://bitcointalksearch.org/topic/cacti-template-for-cgminer-monitoring-76502
- 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
January 30, 2014, 08:57:04 AM
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 Upper bound on time spent scanning current work, in seconds (default: 60)
--expiry|-E 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.
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
--expiry|-E
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!
January 30, 2014, 02:45:58 AM
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 Upper bound on time spent scanning current work, in seconds (default: 60)
--expiry|-E 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.
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
--expiry|-E
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.
January 30, 2014, 02:23:17 AM
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.
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:
Quote
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
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.
January 30, 2014, 02:11:38 AM
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.
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
Jump to: