[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[kano]

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 ...

[1713592253]

1713592253

[1713592253]

1713592253

[1713592253]

1713592253

[1713592253]

1713592253

[nelisky]

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 ...

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

[-ck]

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.

Making it halfway through the stratum protocol, I've decided that each mining notify message will be counted as the equivalent of a getwork. Of course efficiency is increasingly becoming a figure that is of not much use to miners and pool ops alike, but perhaps a target efficiency will be the endpoint of tuning what variable diff to set it to.

[vitruvio]

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 ...

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

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?.

[kano]

...

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

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

[vitruvio]

...

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

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

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

[eleuthria]

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.

Making it halfway through the stratum protocol, I've decided that each mining notify message will be counted as the equivalent of a getwork. Of course efficiency is increasingly becoming a figure that is of not much use to miners and pool ops alike, but perhaps a target efficiency will be the endpoint of tuning what variable diff to set it to.

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).

[Luke-Jr]

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?

[-ck]

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.

Making it halfway through the stratum protocol, I've decided that each mining notify message will be counted as the equivalent of a getwork. Of course efficiency is increasingly becoming a figure that is of not much use to miners and pool ops alike, but perhaps a target efficiency will be the endpoint of tuning what variable diff to set it to.

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).

Indeed efficiency is already confusing enough in the light of rolltime and vardiff, and not even defined in any meaningful fashion for stratum. It looks like it might be time to retire it as a metric.

[vitruvio]

I've noticed the change of bfg by cow.

Huh?

...
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

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

[demkd]

Sopped miners two days ago and still have fixed amount of unconfirmed BTC and NMC
Bug?
Account: cls

[FLHippy]

Sopped miners two days ago and still have fixed amount of unconfirmed BTC and NMC
Bug?
Account: cls

Not a bug, shit luck. really shit luck!
The confirmed number won't change until they solve a block and some block solves recently have been 8 hours, 6 hours...

Luck is shit for 5 days now.. Inaba needs to put a rabbits foot on the servers

How many days of bad luck do we have to have before you accept my offer to send a rabbits foot?

I'm willing to compromise. A horseshoe... an Oosik, a 4 leaf clover, a found penny, you choose. I'm stopping just short of a blood sacrifice though.

[stevegee58]

Eligius is in the middle of a 75 hour block right now.  That's gotta be frustrating.

[chrcoe01]

I am wondering if EMC will make use of stratum at any point in the future, anyone know?  Perhaps I am just a silly newb  and I missed something, but I did not see anything about it on the site currently. 

[Inaba]

We use GBT, which doesn't require any funky proxies or anything on your end now.  It just works magically behind the scenes if you're using BFGminer 2.8.0 or later.

[kano]

We use GBT, which doesn't require any funky proxies or anything on your end now.  It just works magically behind the scenes if you're using BFGminer 2.8.0 or later.

What level of implementation?

Since at full implementation, a miner using GBT isn't just talking to the pool, it's also talking to the bitcoin network and thus that also affects your mining performance: crap connection, low bandwith, busy connection has a bigger negative impact on mining than the other pool protocols since it also needs to track transactions and blocks ...
... and handle orphans and txn verification and invalid txns ... and other guff in bitcoind related to txns and blocks

[mufa23]

Inaba,
For the past day or so I have noticed I have more unconfirmed BTC then blocks that are unconformed. I think a day or two ago when I helped solve a couple of blocks, it stayed in my unconfirmed balance even though the blocks already got confirmed. It seems that the only way to get the BTC is to "Cash Out".

My account is "mufa23" if you can fix/take a look at the glitch. Thanks

EDIT: Also my NMC seems to be stuck in Unconfirmed as well.

[ocminer]

I really wonder if luck ever comes back to EMC..

Bad luck since ~5 days... :-(

[Badonkadonk]

I really wonder if luck ever comes back to EMC..

Bad luck since ~5 days... :-(

gogo PPS

[ocminer]

Will be switching for sure after this weekend if luck doesnt come back...

I really wonder if luck ever comes back to EMC..

Bad luck since ~5 days... :-(

gogo PPS