Topic: [ANN][Pool][Profit-Switch][Optional Auto-Exchange per Coin][Vardiff] ~ Hashcows - page 168. (Read 347342 times)
October 02, 2013, 07:01:29 AM
Getting 75% rejections on my GPU miners and 7% or so on slow slow CPU miners while we're on XNC. One of the worst rejection rates I've seen so far with my miners. Can't wait to jump off this coin.
October 02, 2013, 05:52:34 AM
Any sort of intensity over 18 is really not worth it in terms of the added power consumption.
My 7950s @ 1100/1600 @ 1.1v:
@ 18i do 630khs @ 200w
@ 19i they do 645khs @ 220w
@ 20i they do 655khs @ 240w
So as you can see i'm literally consuming an extra 120w for ~another 100khs when the intensity is set full blast @ 20.
The same could be said even for intensity 18, but the jump in wattage from 17 to 18 is negligible but 18 still produces an extra 20-25khs over 17.
My 7950s @ 1100/1600 @ 1.1v:
@ 18i do 630khs @ 200w
@ 19i they do 645khs @ 220w
@ 20i they do 655khs @ 240w
So as you can see i'm literally consuming an extra 120w for ~another 100khs when the intensity is set full blast @ 20.
The same could be said even for intensity 18, but the jump in wattage from 17 to 18 is negligible but 18 still produces an extra 20-25khs over 17.
October 02, 2013, 03:51:41 AM
Additionally, if you are using Windows, Intensity is max 13. On Linux is 20.
You can set intensity to 20 on windows but I find that anything above 18 on multipools gives a higher reject rate.
October 02, 2013, 02:39:53 AM
Pool is down, I guess. So, what's a good failover for this one?
I just woke up to fix this. Will have nearmiss take a look at why its happening again.
He did code some more fail overs but for some reason this one wasn't caught
Sorry fellas!
This cow is going back to sleep
October 02, 2013, 02:24:52 AM
Pool is down, I guess. So, what's a good failover for this one?
October 02, 2013, 01:55:20 AM
Why 'Confirmed Balance' still ZERO?
How long have you been mining? Confirmed balance for btc updates once daily at 03:00 UTC.
got it
October 02, 2013, 01:47:10 AM
What pools/coins do you guys use or recommend as failover for this one?
October 01, 2013, 11:57:35 PM
Okay, well I'll try for one more day. So far
Day 1 0.0147 BTC/Mh
Day 2 0.0160 BTC/Mh
Under performing what I was getting on wemineltc.com by about 10%
Day 1 0.0147 BTC/Mh
Day 2 0.0160 BTC/Mh
Under performing what I was getting on wemineltc.com by about 10%
October 01, 2013, 10:13:26 PM
have some open issues with our IFC funds and the exchange. Caused a bit of a dip in our potential profits for the day. Hopefully its cleared up shortly and rolled into tomorrow's payout.
October 01, 2013, 09:57:40 PM
Um, do you have any scientific support of such a claim? Not tryin' to flame, but first time i've ever heard that theory.
If anything, the disruption on each start/stop cycle is like giving the cards a mini-break.
Either way, my cards are all in the low 70s C range, and every little disconnect / reconnect only drops their temps maybe 5-10C before the server kicks back up.
I doubt this getwork failure between each coin change will cause any damage to your graphics cards. But this is what I was complaining about when I said I see getwork failures on this pool. It happens between every coin change. I have tried middlecoin, multipool and CryptoSwitcher to jump between coins. None of them have getwork failures or any delay when switching coins.
So does Multipool, all 3 of the multi crypto mining pools have this issue/problem/whatever it is. Usually my miners will trip over to a backup pool for a few seconds and then back to the main pool to continue on with the new round.
FYI, for the "breaks" from the multipool, I have it fall over onto a good paying coin... Made 0.00595612 BTC from it for about 10-20 minutes of outage/failovers. If you put the right coin as failover, you can hit a nice block or 3. I ended up getting 2 blocks in the same minute. Just make cgminer failover into SOLO Mining Mode when hashco.ws is not responding, NOT to another pool. I average about 4 blocks a day in failover mode.
October 01, 2013, 08:16:05 PM
1741 MNC 00:07:53 1 2 23 46.6 0.08 1.92 0.000243 BTC
1740 IFC 00:12:07 220 14417920 77 5046273.2 376631.81 14041288.19 0.00175 BTC
WTF why did it switch from IFC (12 minutes @ 0.00175 BTC) to MNC (8 minutes @ 0.000243 BTC)?
Spend more time on IFC plz...
It's not worth it, we have tried it when it wasn't in its "high profitability time" and the payout is no where near as good as even MNC.
October 01, 2013, 08:09:55 PM
1741 MNC 00:07:53 1 2 23 46.6 0.08 1.92 0.000243 BTC
1740 IFC 00:12:07 220 14417920 77 5046273.2 376631.81 14041288.19 0.00175 BTC
WTF why did it switch from IFC (12 minutes @ 0.00175 BTC) to MNC (8 minutes @ 0.000243 BTC)?
IFC is being a big winner for us. Please spend more time on IFC...
1740 IFC 00:12:07 220 14417920 77 5046273.2 376631.81 14041288.19 0.00175 BTC
WTF why did it switch from IFC (12 minutes @ 0.00175 BTC) to MNC (8 minutes @ 0.000243 BTC)?
IFC is being a big winner for us. Please spend more time on IFC...
October 01, 2013, 07:34:23 PM
Are you running these cards in 1 rig or 3? What mining software are you running? What are the settings for your cards?
2 rigs actually, on has 2 GPUs. Running cgminer through GUIMiner-scrypt. Maybe I'll update it when the rigs are back up ( rigs are down due to power failure in the area).
Settings (from memory), are close to this:
-g 1 --thread-concurrency 7500 -I 18 -w 256
as someone suggested it in this thread, I also tried adding
--expiry 5 --queue 0 --scan-time 5
Seems to make no difference.
I an running multiple 7xxx cards and my reject rates have always been low on HC.
Must be your config.
Must be your config.
That may be possible, but other pools don't report such high reject rates, including middlecoin, give-me-ltc, etc. Most report under 5% rejects.
You probably did not use --no-submit-stale with cgminer... This is why the high reject rates.
Turn that option on and try again.
Turn that option on and try again.
But that will only mask the rejects, then I'll only see the efective hash-rate at the pool and never figure out why there are so many rejects in the first place!
I can't comment on guiminer-scrypt as I use cgminer myself with cgwatcher on top. One of my rigs has 2x5870's and 2x5850's and runs with a 5% reject rate. I haven't included my mem and clock speeds but my cgminer command line reads:
--thread-concurrency 8000 --intensity 18 --lookup-gap 2 --worksize 256 -g 1 --expiry 5 --queue 0 --scan-time 5
Some people say that expiry, queue and scan-time have no effect, but I find if I don't have these in for the multipools I get a higher reject and stale rate. If I mine LTC directly I do not put those settings in and get 1-2% rejects mining on wemineltc. I don't have no-submit-stale enabled as half the time with the above settings a stale share that is submitted it is accepted.
[2013-10-01 22:00:33] Pool 0 stale share detected, submitting as user requested
[2013-10-01 22:00:33] Accepted 25ecd518 Diff 532/37 GPU 0 pool 0
[2013-10-01 22:00:33] Accepted 55759c15 Diff 122/37 GPU 2 pool 0
Try cgminer, try playing with your thread-concurrency, try changing your intensity. I find that running at anything over 18 again gives myself more stales on multipools, I run everything on 20 mining LTC. Might take some playing but there will be a sweet spot.
Additionally, if you are using Windows, Intensity is max 13. On Linux is 20.
October 01, 2013, 06:53:29 PM
Why 'Confirmed Balance' still ZERO?
How long have you been mining? Confirmed balance for btc updates once daily at 03:00 UTC.
October 01, 2013, 04:55:32 PM
Thank you very much, I will try CGwatcher, as Guiminer scrypt has stopped development. I will try your settings and play around a little, didn't expect so much difference and nuance in a multi coin pool vs one scrypt coin pool.
I will also try -verbose to see if I can debug any problems, thanks glon.
I will also try -verbose to see if I can debug any problems, thanks glon.
It's --verbose , not -verbose
And you can thank me later.
October 01, 2013, 04:47:36 PM
Thank you very much, I will try CGwatcher, as Guiminer scrypt has stopped development. I will try your settings and play around a little, didn't expect so much difference and nuance in a multi coin pool vs one scrypt coin pool.
I will also try -verbose to see if I can debug any problems, thanks glon.
I will also try -verbose to see if I can debug any problems, thanks glon.
October 01, 2013, 04:03:01 PM
Are you running these cards in 1 rig or 3? What mining software are you running? What are the settings for your cards?
2 rigs actually, on has 2 GPUs. Running cgminer through GUIMiner-scrypt. Maybe I'll update it when the rigs are back up ( rigs are down due to power failure in the area).
Settings (from memory), are close to this:
-g 1 --thread-concurrency 7500 -I 18 -w 256
as someone suggested it in this thread, I also tried adding
--expiry 5 --queue 0 --scan-time 5
Seems to make no difference.
I an running multiple 7xxx cards and my reject rates have always been low on HC.
Must be your config.
Must be your config.
That may be possible, but other pools don't report such high reject rates, including middlecoin, give-me-ltc, etc. Most report under 5% rejects.
You probably did not use --no-submit-stale with cgminer... This is why the high reject rates.
Turn that option on and try again.
Turn that option on and try again.
But that will only mask the rejects, then I'll only see the efective hash-rate at the pool and never figure out why there are so many rejects in the first place!
I can't comment on guiminer-scrypt as I use cgminer myself with cgwatcher on top. One of my rigs has 2x5870's and 2x5850's and runs with a 5% reject rate. I haven't included my mem and clock speeds but my cgminer command line reads:
--thread-concurrency 8000 --intensity 18 --lookup-gap 2 --worksize 256 -g 1 --expiry 5 --queue 0 --scan-time 5
Some people say that expiry, queue and scan-time have no effect, but I find if I don't have these in for the multipools I get a higher reject and stale rate. If I mine LTC directly I do not put those settings in and get 1-2% rejects mining on wemineltc. I don't have no-submit-stale enabled as half the time with the above settings a stale share that is submitted it is accepted.
[2013-10-01 22:00:33] Pool 0 stale share detected, submitting as user requested
[2013-10-01 22:00:33] Accepted 25ecd518 Diff 532/37 GPU 0 pool 0
[2013-10-01 22:00:33] Accepted 55759c15 Diff 122/37 GPU 2 pool 0
Try cgminer, try playing with your thread-concurrency, try changing your intensity. I find that running at anything over 18 again gives myself more stales on multipools, I run everything on 20 mining LTC. Might take some playing but there will be a sweet spot.
October 01, 2013, 03:49:23 PM
Um, do you have any scientific support of such a claim? Not tryin' to flame, but first time i've ever heard that theory.
If anything, the disruption on each start/stop cycle is like giving the cards a mini-break.
Either way, my cards are all in the low 70s C range, and every little disconnect / reconnect only drops their temps maybe 5-10C before the server kicks back up.
I doubt this getwork failure between each coin change will cause any damage to your graphics cards. But this is what I was complaining about when I said I see getwork failures on this pool. It happens between every coin change. I have tried middlecoin, multipool and CryptoSwitcher to jump between coins. None of them have getwork failures or any delay when switching coins.
So does Multipool, all 3 of the multi crypto mining pools have this issue/problem/whatever it is. Usually my miners will trip over to a backup pool for a few seconds and then back to the main pool to continue on with the new round.
October 01, 2013, 03:38:00 PM
you got profit?
October 01, 2013, 03:13:36 PM
LOL. Always happens. Wait and wait and wait, then make a post and the miners reconnect.
Jump to: