OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[kano]

...
Yes unfortunately I do, I have 9 rigs, 2 with 2 GPU's and the rest with only 1.

I know what efficiency means, was just wondering why it is so different for different people.
I have no idea what influences efficiency

Using mainly 5800's 2 6950's

I am using default settings, no overclocking, intensity 8

I am not worried about the Performance, was just wondering about the low efficiency

Ah they're not your computers?
No one would run an extra 120+W per card on purpose
Maybe work owns them?

A work request represents 2^32 hash attempts (without using rollntime)
For a good quality 6950 on default settings (e.g. GB HD 6950 900Mhz/775Mhz = ~365Mh/s) it should take about 11.77 seconds to complete the full 2^32 hash tests.
However, if it should get any LP messages during that 11.77 seconds then (by supposed definition) all the work requests queued and being worked on will be thrown away and give no more results than what has already been submitted - thus reducing your efficiency.

A higher intensity will make that worse also since it increases how long the GPU is working without replying.
A lower hash rate will also decrease efficiency for the same reason.

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.

[1715429579]

1715429579

[1715429579]

1715429579

[1715429579]

1715429579

[1715429579]

1715429579

[-ck]

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.

This is the most likely reason.

If you want to increase efficiency (for the pool's sake, not yours), decrease thread count to 1 and increase scan time to say 115 seconds.

[Remember remember the 5th of November]

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.

This is the most likely reason.

If you want to increase efficiency (for the pool's sake, not yours), decrease thread count to 1 and increase scan time to say 115 seconds.

This sounds a bit wrong. The scantime would be understandable for a slower card that cannot do 2^32 in 60 seconds, but, for a fast card it takes seconds to test them all.

[-ck]

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.

This is the most likely reason.

If you want to increase efficiency (for the pool's sake, not yours), decrease thread count to 1 and increase scan time to say 115 seconds.

This sounds a bit wrong. The scantime would be understandable for a slower card that cannot do 2^32 in 60 seconds, but, for a fast card it takes seconds to test them all.

Increasing scantime will allow cgminer to roll the work for longer. Scantime affects rolltime expiration as well.

[gnar1ta$]

On the scantime and intensity topic.  Should scantime be increased and intensity decreased when mining on p2pool? I know it works a bit different than regular pools and on my 6950 rig where I usually have an E of 140% and U of 29.xx I now have an E of 4% and U of 3.45.  Am I overworking or underworking the cards?

[kano]

On the scantime and intensity topic.  Should scantime be increased and intensity decreased when mining on p2pool? I know it works a bit different than regular pools and on my 6950 rig where I usually have an E of 140% and U of 29.xx I now have an E of 4% and U of 3.45.  Am I overworking or underworking the cards?

U is proportional to income ... directly ...
If it is now 1/10 over a long period of time - that's bad.
Edit: assuming a share is still worth the same amount ...

[-ck]

On the scantime and intensity topic.  Should scantime be increased and intensity decreased when mining on p2pool? I know it works a bit different than regular pools and on my 6950 rig where I usually have an E of 140% and U of 29.xx I now have an E of 4% and U of 3.45.  Am I overworking or underworking the cards?

U is proportional to income ... directly ...
If it is now 1/10 over a long period of time - that's bad.

No, changing to p2pool changes the meaning of everything. I can't directly equate the numbers changing from one to the other, but this is not bad. I don't know enough about p2pool to suggest how to tune it, but I suspect the cgminer defaults are best still.

Also note I wasn't suggesting people try to improve their efficiency since it usually adversely affects the miner... I was just explaining how you might go about it.

[gnar1ta$]

I'll buy your suspected defaults theory.  I've only been running it constant for 24 hrs (on defaults) but it looks like the reject ratio and payout are the same - short time to make that assumption though.  Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.

[-ck]

Increasing scantime will allow cgminer to roll the work for longer. Scantime affects rolltime expiration as well.

This is assuming you are on a pool that supports rolltime and allows it for cgminer by the way...

edit: Oh and decreasing -q would also "help" efficiency.

[The00Dustin]

I will also add that the detection explanation seems extremely strange.
Whenever you plug a USB device into a linux system you see messages in dmesg about the identity of the device.
That information (however you get access to it) should be enough to know what it is shouldn't it?
Or are they not handling the USB connection with identity information like every other USB device on the planet I've plugged into a linux box?

It may already be obvious to you, but since no one else responded to this, and it seems rather obvious to me (granted, I only have a guess as they didn't state this in their post), I will.  The reason you have to query the device is because it is communicating through an emulated serial port (hence the /dev/tty# in *nix and COM# in Windows).  The benefit to that is there is no driver to maintain, dmesg will detect a new serial port for which most OSes already have a native driver.  If I am correct, they could have manufactured the device with a real serial port instead, but I'm not sure there would be much to gain from that.  One downside I just thought of, if I am correct, is that the usb devices per port/hub limit may not matter if the operating systems in question have a lower limit on the number of com ports they will support.

[kano]

I'll buy your suspected defaults theory.  I've only been running it constant for 24 hrs (on defaults) but it looks like the reject ratio and payout are the same - short time to make that assumption though.  Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.

Yeah merged mining sux doesn't it ...
Edit: or is p2pool using that same bad design?

[-ck]

I'll buy your suspected defaults theory.  I've only been running it constant for 24 hrs (on defaults) but it looks like the reject ratio and payout are the same - short time to make that assumption though.  Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.

Yeah merged mining sux doesn't it ...

Actually he was on p2pool...

[gnar1ta$]

p2pool with merged mining for 24hrs and bitcoin only for 24 hrs...numbers were the same, but maybe too short timeframe for real comparison.  Why does merged mining suck? Doesn't the miner just hash what it's given?

[jake262144]

... Why does merged mining suck? ...

You answered that yourself:

...Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.

A NMC block is much easier to find than a BTC block. Each time a NMC block is found, your work is being interrupted by a LP message. The current work and queue needs to be dumped and new work needs to be fetched. If your miner is slow, you might be interrupted relatively often.

[The00Dustin]

p2pool with merged mining for 24hrs and bitcoin only for 24 hrs...numbers were the same, but maybe too short timeframe for real comparison.  Why does merged mining suck? Doesn't the miner just hash what it's given?

Merged mining increases longpolling frequency due to multiple chains experiencing changes, especially when the difficulty of one of those chains is significantly lower.  The negative effect on your mining is a bit of lost work per change.  It would actually potentially be a lot more negative it weren't for longpolling.

[DeathAndTaxes]

A NMC block is much easier to find than a BTC block. Each time a NMC block is found, your work is being interrupted by a LP message. The current work and queue needs to be dumped and new work needs to be fetched. If your miner is slow, you might be interrupted relatively often.

Relatively often is all relative.  NMC block is roughly 2.4x as easy.  That is an extra 1 to 2 LP per block.  When NMC merge mining was new it was more of an issue with 20 to 30 LP per block.

The LP gnar1ta$ was refering to (5 per share) had nothing to do w/ merge mining.  p2pool uses larger shares.  1 p2pool share ~= 150 difficulty 1 shares.  It also builds a share chain to continually recalculate reward split and roughly every 10 seconds a new share will be found by someone on the p2pool network and thus requires an LP.

[gnar1ta$]

The LP gnar1ta$ was refering to (5 per share) had nothing to do w/ merge mining.  p2pool uses larger shares.  1 p2pool share ~= 150 difficulty 1 shares.  It also builds a share chain to continually recalculate reward split and roughly every 10 seconds a new share will be found by the network and thus an LP.

Right, so if my work is being discarded roughly every 10 seconds due to an LP, shouldn't my scantime roughly match that to not waste so much work?

[-ck]

The LP gnar1ta$ was refering to (5 per share) had nothing to do w/ merge mining.  p2pool uses larger shares.  1 p2pool share ~= 150 difficulty 1 shares.  It also builds a share chain to continually recalculate reward split and roughly every 10 seconds a new share will be found by the network and thus an LP.

Right, so if my work is being discarded roughly every 10 seconds due to an LP, shouldn't my scantime roughly match that to not waste so much work?

Exactly the opposite. If you're already forced to throw out work every 10 seconds, the last thing you want to do is throw out any more work than necessary.

[jake262144]

Relatively often is all relative.

***I was hopelessly, utterly, and pathetically wrong, disregard***

His hardware solves 3.45 shares per minute, taking on average 17.3 seconds to find each share.
Statistically, that's just over 34 solved shares per BTC block.
Let's for the sake of clarity of argument (ease of calculations) assume 2 NMC blocks per 1 BTC block.
It translates to over 17 seconds of his work being lost, on average, during each BTC block.
That's nearly 3% performance hit due to merged mining right there.

[DeathAndTaxes]

Relatively often is all relative.

Roger that, here's how I see it from my POV:

His hardware solves 3.45 shares per minute, taking on average 17.3 seconds to find each share.
Statistically, that's just over 34 solved shares per BTC block.

Let's for the sake of clarity of argument (ease of calculations) assume 2 NMC blocks per 1 BTC block.

It translates to over 17 seconds of his work being lost, on average, during each BTC block.
That's nearly 3% performance hit due to merged mining right there.
There's no escaping that, it's just the nature of the beast.

That isn't how it works.  That assumes that the GPU will hash an entire nonce range at one time (2^32 hashes) but it does't.  The number of hashes performed is a fraction of that.  It depends on difficulty, maybe ckolivas can give us the formula.  So when an LP occurs the amount of work lost is much less.

Another way to look at it is the hypothetical miner above processes 34 shares.  If your analysis was right it would have 1 stale out of 34 even when not merged mining and thus could never have a stale rate of <3%.