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

[twmz]

Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

[Lantis]

erm.. bump?

...

No answer clearly means you have to sort it out yourself.

The GPU code is written to work with ATI library supported cards with specific drivers.

If you want to it work with others, you'll be modifying the CL and/or GPU driver.
However, it is a complete waste of time, since it will be a complete waste of electricity.

well with all the other replies I thought it was missed, having this kind of answer is better since now I know I need to proceed with a different approach in solving it.

[martinm]

Hello ck,
Hello Kano,

I've a question related to the identification of a device in cgminer and the a hardware device. As I'm currently about to develop a application that creates statistics for every device, it's essential to have a clear mapping between hardware device and the related device in cgminer for that. Previously I thought that the combination of the Device Type (GPU/BAS/AVA/....) and ID provided from cgminer could achieve that task, I had the hope it works as long the devices are connected to the same Port(USB/PCE...). Unfortunately I discovered that's not right. During the run of CGMiner I unplugged an Avalon from the USBPort and reconnected after a short time. After the reconnect the Id changed from AVA0 to AVA1. Now I'm questioning myself, how I can achieve the unique identification of a hardware device by reported data from CGMiner. I hope you can give me some advice!

Thany you very much in advance 

Avalon has no information in the device at all - I think that's something those guys like doing Icarus has nothing useful either.

Any device that has an iSerial that isn't constant would be one way to detect 2 devices being the same one that hotplugged later.

But with Avalon it's not possible - so if you unplug 2 and then plug them back in, there's no USB information to say which was which before.
The devices that don't have an iSerial, or have the same iSerial, are: AVA, AMU, BFL FPGA, MMQ
AsicMiner USBs can be reprogrammed to fix it
I've no idea what the ATI library supplies for GPUs but I'd guess nothing useful either.

These devices don't have this stupid problem: BFL SC, BLT, BTB

Thank you for the clear answer!

[vekt0r7]

Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

I would like to point out that there is A BUG ASSOCIATED WITH THAT FEATURE.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.

Is there an "official" way to report bugs or is ckolivas going to read this?

[Oldminer]

Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares.

[kano]

Hello ck,
Hello Kano,

I've a question related to the identification of a device in cgminer and the a hardware device. As I'm currently about to develop a application that creates statistics for every device, it's essential to have a clear mapping between hardware device and the related device in cgminer for that. Previously I thought that the combination of the Device Type (GPU/BAS/AVA/....) and ID provided from cgminer could achieve that task, I had the hope it works as long the devices are connected to the same Port(USB/PCE...). Unfortunately I discovered that's not right. During the run of CGMiner I unplugged an Avalon from the USBPort and reconnected after a short time. After the reconnect the Id changed from AVA0 to AVA1. Now I'm questioning myself, how I can achieve the unique identification of a hardware device by reported data from CGMiner. I hope you can give me some advice!

Thany you very much in advance 

Avalon has no information in the device at all - I think that's something those guys like doing Icarus has nothing useful either.

Any device that has an iSerial that isn't constant would be one way to detect 2 devices being the same one that hotplugged later.

But with Avalon it's not possible - so if you unplug 2 and then plug them back in, there's no USB information to say which was which before.
The devices that don't have an iSerial, or have the same iSerial, are: AVA, AMU, BFL FPGA, MMQ
AsicMiner USBs can be reprogrammed to fix it
I've no idea what the ATI library supplies for GPUs but I'd guess nothing useful either.

These devices don't have this stupid problem: BFL SC, BLT, BTB

Thank you for the clear answer!

Oh lol - I just realised I made a rather silly comment there
You can't unplug a GPU while it's mining so GPUs would not be relevant to your comment.

[-ck]

Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares.

It's accepted blocks * the difficulty at the time of solving them, not shares.

[martinm]

Hello Kano,

the comment wasn't so silly, the major objective was related to the identification of a device in cgminer, so it also counts if the ID's are the same after a restart of cgminer. Means for GPU's it would depend if the ATI Lib provides the GPU's in the same order. I will just assume the lib would provide the GPU's in the same order, at least as long there is no additional GPU added/removed.
Another issue I'm facing is the mapping of ID's provided from cgminer between different API command. For "DEV" and "DEVDETAILS" cgminer provides an ID, but once with a detail type (BAS,BFL,ICA,AVA,....) and once with a generic type (GPU,PGA,ASC,....). Are the ID generated for each group separately or are they related. As example, I run an instance of cgminer with 2 ICA, 2 AVA and 2 BAS devices. If the ID's are related, I would expect following result:

DEV command:
Name=PGA,ID=0
Name=PGA,ID=1
Name=ASC,ID=2
Name=ASC,ID=3
Name=ASC,ID=4
Name=ASC,ID=5

DEVDETAILS command:
Name=ICA,ID=0
Name=ICA,ID=1
Name=AVA,ID=2
Name=AVA,ID=3
Name=BAS,ID=4
Name=BAS,ID=5

By this it would be easy to generate a mapping between these devices, as the ID is program wide unique. But if the ID is just unique for each group, I would expect following result.

DEV command:
Name=PGA,ID=0
Name=PGA,ID=1
Name=ASC,ID=0
Name=ASC,ID=1
Name=ASC,ID=2
Name=ASC,ID=3

DEVDETAILS command:
Name=ICA,ID=0
Name=ICA,ID=1
Name=AVA,ID=0
Name=AVA,ID=1
Name=BAS,ID=0
Name=BAS,ID=1

In this case I could just assume that I have to rely on the order of the devices in the Json. Unfortunately I cant test the case (and also don't have the appropiate C++ skills to analyze the source), I hope you can help me and explain how cgminer is handling the ID's, so that I can do the right mapping.

Many thanks in advance!

[kano]

I'm not sure what the confusion is but ...
DEV
 PGA=0,Name=AMU,ID=0

DEVDETAILS
 DEVDETAILS=0,Name=AMU,ID=0

There is no trick to the association ... Name+ID from one to the other

... except ... missing from DEVS for a GPU, is it has no Name or ID

In miner.php I generate it easily enough:

Code:

function joinsections($sections, $results, $errors)
{
 global $sectionmap;

 // GPU's don't have Name,ID fields - so create them
 foreach ($results as $section => $res)
.
.
.

The names GPU, PGA, ASC in the API are to allow for device selection in the API via a number.
So if you want to affect the first PGA, with a PGA command, it is PGA=0, for the 10th one it is PGA=9
i.e. independent of the screen display - the screen display is Name,ID

I was planning once to also allow selection via the Name,ID but ... as is common I got side tracked ... and since most of the development I do in cgminer is for myself (I get very few donations) I usually do what I feel needs to be done.
I do of course appreciate the donations I get from a few people indeed - but they are not as common for me ... as others

Edit: though of course I get hardware donations and indeed work on the drivers for them as required

[Acejam]

Anyone ever get a crash with cgminer? I'm using Windows 7 x64. This happened after about 24 hours.

[kano]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

[Acejam]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts?

[-ck]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts?

Unfortunately we have no solution for a microsoft provided dll crashing. It should not be possible for our software to crash the dll unless there's a bug in the dll. The only suggestions are checking you have the latest dll and there are no virus/trojans that have attached to it.

[twmz]

Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares.

When solo mining, the job difficulty is just = the the network difficulty.  So a share = a block, and the counter is going to increment by the difficulty of each block found.  I still don't think that is a bug.  ckolivas can clarify, but I don't think there was an intention of a "block found counter".  You're in a somewhat unique situation, and if you need a block found counter, I would suggest using the API (in which shares = blocks, when solo mining).

[kano]

Yes A: is a 1diff share difficulty counter
If you are mining on a pool at 16 diff, each pool share accepted will be 16 x 1diff
If you are mining BTC solo then you are mining (currently) at 112,628,548.66635 diff - so each block you find will increment A by that (until the next diff change)
In the API this is "Difficulty Accepted"
Since pools can change your difficulty, it makes no sense to report shares as a counter of number of shares.
If you want that, it's in the API as "Accepted"
If you want to know how many blocks you found then that's in the API as "Found Blocks"
It's certainly no bug ... as has been stated here before ... it's by design and will stay that way.

[kentt]

100% CPU problem.  I'm using Xubuntu 12.04, scrypt mining with 6x7950s cgminer 3.4.2.  The causes the rig to lock up after a few hours.
top gives me

Code:

top - 01:59:25 up 11 min,  3 users,  load average: 9.02, 8.21, 4.75
Tasks: 149 total,   2 running, 147 sleeping,   0 stopped,   0 zombie
Cpu(s): 50.0%us, 50.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  24642564k total,  1488724k used, 23153840k free,    26608k buffers
Swap:  4882428k total,        0k used,  4882428k free,   246960k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                            
 1791 xxx  20   0 1485m 119m  56m S   92  0.5  10:16.21 cgminer                                                                                            
   10 root      20   0     0    0    0 S   54  0.0   6:06.87 ksoftirqd/1                                                                                        
    3 root      20   0     0    0    0 R   54  0.0   5:56.12 ksoftirqd/0  

Code:

$ cat /proc/interrupts
           CPU0       CPU1       
  0:         47          0   IO-APIC-edge      timer
  1:          1          2   IO-APIC-edge      i8042
  8:          0          1   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          4          0   IO-APIC-edge      i8042
 16:         13         15   IO-APIC-fasteoi   ehci_hcd:usb1
 23:         29          3   IO-APIC-fasteoi   ehci_hcd:usb2
 42:       6807        208   PCI-MSI-edge      ahci
 43:          0          0   PCI-MSI-edge      xhci_hcd
 44:       9506         12   PCI-MSI-edge      eth0
 45:         14          0   PCI-MSI-edge      mei
 46:        508          1   PCI-MSI-edge      snd_hda_intel
 48:       1843          0   PCI-MSI-edge      fglrx[0]@PCI:1:0:0
 49:       1949          0   PCI-MSI-edge      fglrx[1]@PCI:2:0:0
 50:       1968          3   PCI-MSI-edge      fglrx[2]@PCI:4:0:0
 51:       1798          4   PCI-MSI-edge      fglrx[3]@PCI:5:0:0
 52:       2085          1   PCI-MSI-edge      fglrx[4]@PCI:6:0:0
 53:       2098          1   PCI-MSI-edge      fglrx[5]@PCI:7:0:0
NMI:        616        612   Non-maskable interrupts
LOC:      26042      58249   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:        616        612   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:      23149      17583   Rescheduling interrupts
CAL:        270        201   Function call interrupts
TLB:       1521       9791   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:          3          3   Machine check polls
ERR:          0
MIS:    

Any ideas as to how to get the CPU load down.

[kentt]

Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

I would like to point out that there is A BUG ASSOCIATED WITH THAT FEATURE.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.

Is there an "official" way to report bugs or is ckolivas going to read this?

Not totally a solution, but zero the stats would be easier than restarting.

[The00Dustin]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts?

Unfortunately we have no solution for a microsoft provided dll crashing. It should not be possible for our software to crash the dll unless there's a bug in the dll. The only suggestions are checking you have the latest dll and there are no virus/trojans that have attached to it.

Not that I think the cgminer devs should in any way be responsible for taking this action, but it is possible to open a ticket with Microsoft.  I don't believe per incident support is actually as expensive as one would expect, and I think the fee is refunded when a problem is proved to be a problem in their OS.  Getting high enough up the chain on the ticket might be tricky and might require reproducing the issue over and over again, so it could be easier for a dev, but I just thought I'd point out that it's more of an option than anyone might realize.  However, I don't use cgminer with Windows (I don't even have Win7 at home), so I can't really offer to help beyond the suggestion in this case, so this is just information for those more vested (either because they are effected or because someone offers them a donation for taking action).

[Askit2]

100% CPU problem.  I'm using Xubuntu 12.04, scrypt mining with 6x7950s cgminer 3.4.2.  The causes the rig to lock up after a few hours.
top gives me

Code:

top - 01:59:25 up 11 min,  3 users,  load average: 9.02, 8.21, 4.75
Tasks: 149 total,   2 running, 147 sleeping,   0 stopped,   0 zombie
Cpu(s): 50.0%us, 50.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  24642564k total,  1488724k used, 23153840k free,    26608k buffers
Swap:  4882428k total,        0k used,  4882428k free,   246960k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                            
 1791 xxx  20   0 1485m 119m  56m S   92  0.5  10:16.21 cgminer                                                                                            
   10 root      20   0     0    0    0 S   54  0.0   6:06.87 ksoftirqd/1                                                                                        
    3 root      20   0     0    0    0 R   54  0.0   5:56.12 ksoftirqd/0  

Code:

$ cat /proc/interrupts
           CPU0       CPU1       
  0:         47          0   IO-APIC-edge      timer
  1:          1          2   IO-APIC-edge      i8042
  8:          0          1   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          4          0   IO-APIC-edge      i8042
 16:         13         15   IO-APIC-fasteoi   ehci_hcd:usb1
 23:         29          3   IO-APIC-fasteoi   ehci_hcd:usb2
 42:       6807        208   PCI-MSI-edge      ahci
 43:          0          0   PCI-MSI-edge      xhci_hcd
 44:       9506         12   PCI-MSI-edge      eth0
 45:         14          0   PCI-MSI-edge      mei
 46:        508          1   PCI-MSI-edge      snd_hda_intel
 48:       1843          0   PCI-MSI-edge      fglrx[0]@PCI:1:0:0
 49:       1949          0   PCI-MSI-edge      fglrx[1]@PCI:2:0:0
 50:       1968          3   PCI-MSI-edge      fglrx[2]@PCI:4:0:0
 51:       1798          4   PCI-MSI-edge      fglrx[3]@PCI:5:0:0
 52:       2085          1   PCI-MSI-edge      fglrx[4]@PCI:6:0:0
 53:       2098          1   PCI-MSI-edge      fglrx[5]@PCI:7:0:0
NMI:        616        612   Non-maskable interrupts
LOC:      26042      58249   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:        616        612   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:      23149      17583   Rescheduling interrupts
CAL:        270        201   Function call interrupts
TLB:       1521       9791   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:          3          3   Machine check polls
ERR:          0
MIS:    

Any ideas as to how to get the CPU load down.

When I had that problem or at least a similar problem I was building from GIT while the files where in flux. This happened on a raspberry pi with raspbian not Ubuntu but the high irqd and very high processor seem like that. Any chance you built from GIT?

[-ck]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts?

Unfortunately we have no solution for a microsoft provided dll crashing. It should not be possible for our software to crash the dll unless there's a bug in the dll. The only suggestions are checking you have the latest dll and there are no virus/trojans that have attached to it.

Not that I think the cgminer devs should in any way be responsible for taking this action, but it is possible to open a ticket with Microsoft.  I don't believe per incident support is actually as expensive as one would expect, and I think the fee is refunded when a problem is proved to be a problem in their OS.  Getting high enough up the chain on the ticket might be tricky and might require reproducing the issue over and over again, so it could be easier for a dev, but I just thought I'd point out that it's more of an option than anyone might realize.  However, I don't use cgminer with Windows (I don't even have Win7 at home), so I can't really offer to help beyond the suggestion in this case, so this is just information for those more vested (either because they are effected or because someone offers them a donation for taking action).

Further to this discussion, I've seen quite a few bug reports quite recently about this same dll in combination with firefox. While I do believe the bug is in the dll itself, I wonder if there's a common variable bringing it on? Are those who are having problems with the dll using IPV6 by any chance?