Sopped miners two days ago and still have fixed amount of unconfirmed BTC and NMC
Bug?
Account: cls
Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 52. (Read 499791 times)
October 03, 2012, 08:56:48 PM
October 02, 2012, 10:30:37 AM
...
cowminer version 2.8.1
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
Too lucky? No, you're just using the wrong software cowminer version 2.8.1
Code:
cowminer version 2.8.1 - Started: [2012-10-01 19:28:12] - [ 0 days 20:06:41]
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
October 02, 2012, 10:27:33 AM
That said, how does that effect efficiency calculations going forward? Stratum is effectively the same in that regard, so if you pull a template and send back getworks, how is CGminer going to calculate efficiency or does that just become a redundant metric at that point?
I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it.I'd argue efficiency isn't even a meaningful stat on Stratum. Pools sending you more job notifications aren't less efficient, they're actually MORE efficient (more frequent jobs = more current on transactions in the network).
October 02, 2012, 10:10:05 AM
Sorry but don't understand, wrong software? measures are differents if bfgminer is used with GPU or FPGA?
Kano is a troll, just ignore him.I've noticed the change of bfg by cow.
Huh? 
October 02, 2012, 09:56:18 AM
That said, how does that effect efficiency calculations going forward? Stratum is effectively the same in that regard, so if you pull a template and send back getworks, how is CGminer going to calculate efficiency or does that just become a redundant metric at that point?
I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it.I'd argue efficiency isn't even a meaningful stat on Stratum. Pools sending you more job notifications aren't less efficient, they're actually MORE efficient (more frequent jobs = more current on transactions in the network).
October 02, 2012, 09:31:09 AM
...
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
Too lucky? No, you're just using the wrong software Code:
cowminer version 2.8.1 - Started: [2012-10-01 19:28:12] - [ 0 days 20:06:41]
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
Sorry but don't understand, wrong software? measures are differents if bfgminer is used with GPU or FPGA?
I've noticed the change of bfg by cow.
Regards
October 02, 2012, 09:16:04 AM
...
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
Too lucky? No, you're just using the wrong software Code:
cowminer version 2.8.1 - Started: [2012-10-01 19:28:12] - [ 0 days 20:06:41]
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
October 02, 2012, 08:36:05 AM
I have an older cgminer (2.4.1) running on OpenWRT that was working great with EMC until last weekend (which I assume was when the var diff got turned on). Since then I get roughly 50% of my hashing power reported on the workers page.
I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
Try 2.7.5 ...I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
On 2.7.5 now, I'm putting 2GH/s+ in (10x ZTEX singles) and it all looks good on the miner side (apart from a few rejected with high-hash, which is new to me). On EMC, however, the hash rate reported fluctuates between 1~1.4GH/s, avg diff is 1.088. I expected it to fluctuate a bit higher, obviously.
Code:
(5s):2275.3 (avg):2042.6 Mh/s | Q:275 A:1573 R:214 HW:0 E:572% U:16.6/m
Code:
bfgminer version 2.8.1 - Started: [2012-10-01 19:28:12] - [ 0 days 20:06:41]
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
--------------------------------------------------------------------------------
5s:200.9 avg:201.1 u:199.7 Mh/s | A:3367 R:21 HW:0 E:174% U:2.8/m
I mine with a 6770 and get 200 Mh/s so 1/10 your's but U: that means real shares submitted to pool is much higher, always get 2.6-2.7 shares/m. Can anyboy confirm it?, is a matter or GPU vs FPGA? or Am I too lucky?.
October 01, 2012, 06:53:52 AM
That said, how does that effect efficiency calculations going forward? Stratum is effectively the same in that regard, so if you pull a template and send back getworks, how is CGminer going to calculate efficiency or does that just become a redundant metric at that point?
I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it. October 01, 2012, 06:48:37 AM
I have an older cgminer (2.4.1) running on OpenWRT that was working great with EMC until last weekend (which I assume was when the var diff got turned on). Since then I get roughly 50% of my hashing power reported on the workers page.
I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
Try 2.7.5 ...I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
On 2.7.5 now, I'm putting 2GH/s+ in (10x ZTEX singles) and it all looks good on the miner side (apart from a few rejected with high-hash, which is new to me). On EMC, however, the hash rate reported fluctuates between 1~1.4GH/s, avg diff is 1.088. I expected it to fluctuate a bit higher, obviously.
Code:
(5s):2275.3 (avg):2042.6 Mh/s | Q:275 A:1573 R:214 HW:0 E:572% U:16.6/m
October 01, 2012, 04:50:46 AM
I have an older cgminer (2.4.1) running on OpenWRT that was working great with EMC until last weekend (which I assume was when the var diff got turned on). Since then I get roughly 50% of my hashing power reported on the workers page.
I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
Try 2.7.5 ... I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
October 01, 2012, 04:02:22 AM
I have an older cgminer (2.4.1) running on OpenWRT that was working great with EMC until last weekend (which I assume was when the var diff got turned on). Since then I get roughly 50% of my hashing power reported on the workers page.
I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.
What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?
September 30, 2012, 11:24:35 PM
what is the pool software you are using?
please answer
September 30, 2012, 03:51:56 PM
I just saw it. half mhash for 17 blocks now... why?
cgminer 2.4.1 cant upgrade
What he probably means is that cgminers mhash is approx half, in my case from 320 to 160 MH.cgminer 2.4.1 cant upgrade
For me seen also with cgminer 2.4.1 but directly against stratum proxy (tested both) 0.5.0 and 0.8.3, (against btcguild ). Only clue for me yet is that its a 6950, 3 other 5850 same setup, no problem. Maybe you also got a 6950 ?
September 29, 2012, 02:55:33 PM
what is the pool software you are using?
September 29, 2012, 01:06:09 PM
I'm pointing my measly 5g/h here now. So far I like the interface. Note to self, and others, if switching from a pool where the workers were user.miner to eclipse, change it to user_miner if you expect to see anything. Otherwise it happily mines away, presumably to never never land.
Q: are you keeping transaction fees? I assume you need something to pay for this, unless you have some happy donators.
M
Q: are you keeping transaction fees? I assume you need something to pay for this, unless you have some happy donators.
M
September 29, 2012, 09:46:51 AM
US2 is having some trouble, I am investigating it now.
Nevermind US3 seems to work now
EDIT again: both working again for RPCMiner
EDIT 3x: bad luck streak? I switch to Eclipse and no blocks are found? raincloud
September 29, 2012, 09:45:13 AM
US2 is having some trouble, I am investigating it now.
September 29, 2012, 09:42:53 AM
Anyone else have a problem connecting to account? I do. can login but worker not working when was working yesterday
September 28, 2012, 04:08:20 PM
I can readjust all servers to different amounts as well if we want to try that. It's also possible to leave servers at different difficulties for whatever people feel most comfortable with.
Do you see any value of going to 24 or higher to test? My only concern with higher GW/m rate is that when the system gets slammed with 20 TH/s, it starts to overload the back end, but in all honesty, the back end is pretty robust at this point and can handle around 5 TH/s per server at diff1, if not more.
Do you see any value of going to 24 or higher to test? My only concern with higher GW/m rate is that when the system gets slammed with 20 TH/s, it starts to overload the back end, but in all honesty, the back end is pretty robust at this point and can handle around 5 TH/s per server at diff1, if not more.
You might want to keep a minimum diff for each user mining so that once they start mining for the first time, the system will remember a minimum difficulty for that particular miner. That way, if someone with 10Th/s hops on and off the server, they don't start with diff 1 shares everytime.
Just my two bitcents.
Jump to: