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

[c4n10]

C4n10, is long polling working properly? This looks like LP issue.

Not sure... I have two other miners that are cpu miners running different software and their stale rates are about 1.2% so I'm pretty sure it's not the pool if that's what you are asking...

CPU mining is not only most likely the cause but also a complete waste of time.
As per the README, it's not supported.

I never said the miner in question was a cpu miner.

And yes, I know cpu's are pointless for BTC mining. That's why my cpu miners are mining litecoins right now. The one using cgminer, (the one I am having a problem with and the focus of this thread) is a gpu miner.

[1713415541]

1713415541

[1713415541]

1713415541

[1713415541]

1713415541

[kano]

C4n10, is long polling working properly? This looks like LP issue.

Not sure... I have two other miners that are cpu miners running different software and their stale rates are about 1.2% so I'm pretty sure it's not the pool if that's what you are asking...

CPU mining is not only most likely the cause but also a complete waste of time.
As per the README, it's not supported.

I never said the miner in question was a cpu miner.

And yes, I know cpu's are pointless for BTC mining. That's why my cpu miners are mining litecoins right now. The one using cgminer, (the one I am having a problem with and the focus of this thread) is a gpu miner.

Then you need to provide a lot more information than 'I get high stales' ...........

Compare mining on 2 different pools.

What does the screen show during an LP?

Provide some actual numbers and the pool name from the cgminer screen.

GPU? OS? Cgminer version?

Is it P2Pool so you may as well expect high rejects?

Did you turn on --no-submit-stale?
(You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)

[c4n10]

C4n10, is long polling working properly? This looks like LP issue.

Not sure... I have two other miners that are cpu miners running different software and their stale rates are about 1.2% so I'm pretty sure it's not the pool if that's what you are asking...

CPU mining is not only most likely the cause but also a complete waste of time.
As per the README, it's not supported.

I never said the miner in question was a cpu miner.

And yes, I know cpu's are pointless for BTC mining. That's why my cpu miners are mining litecoins right now. The one using cgminer, (the one I am having a problem with and the focus of this thread) is a gpu miner.

Then you need to provide a lot more information than 'I get high stales' ...........

Compare mining on 2 different pools.

What does the screen show during an LP?

Provide some actual numbers and the pool name from the cgminer screen.

GPU? OS? Cgminer version?

Is it P2Pool so you may as well expect high rejects?

Did you turn on --no-submit-stale?
(You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)

I don't really think I need to compare my mining on two different pools to know that a 10% - 12% stale ratio is high...

I also don't see why the pool name is relevant being that my cpu miners in the exact same pool have a stale rate of less than 1.5% but if you insist, I am on OzCoin.

During an LP the screen shows what it is supposed to show, it tells me when the long polling has detected a new block, it tells me when a share has been accepted or when a share has been rejected.

What numbers would you like me to provide you other than the ratio of stales I am getting? Are there other numbers which would be relevant to the number of stales I am getting?

GPU - Geforce gt 520 (yes, I am aware that it is a piece of crap in relation to mining)
OS - Windows 7 64-bit
cgminer version - 2.7.5

I am not using the --no-submit-stale flag (i'm not using ANY flags actually) and yes, I AM getting stales as opposed to rejects. cgminer specifically says that they are stales ("prevhash submitted" or something along those lines).

[kano]

...
Then you need to provide a lot more information than 'I get high stales' ...........

Compare mining on 2 different pools.

What does the screen show during an LP?

Provide some actual numbers and the pool name from the cgminer screen.

GPU? OS? Cgminer version?

Is it P2Pool so you may as well expect high rejects?

Did you turn on --no-submit-stale?
(You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)

I don't really think I need to compare my mining on two different pools to know that a 10% - 12% stale ratio is high...

I also don't see why the pool name is relevant being that my cpu miners in the exact same pool have a stale rate of less than 1.5% but if you insist, I am on OzCoin.

During an LP the screen shows what it is supposed to show, it tells me when the long polling has detected a new block, it tells me when a share has been accepted or when a share has been rejected.

What numbers would you like me to provide you other than the ratio of stales I am getting? Are there other numbers which would be relevant to the number of stales I am getting?

GPU - Geforce gt 520 (yes, I am aware that it is a piece of crap in relation to mining)
OS - Windows 7 64-bit
cgminer version - 2.7.5

I am not using the --no-submit-stale flag (i'm not using ANY flags actually) and yes, I AM getting stales as opposed to rejects. cgminer specifically says that they are stales ("prevhash submitted" or something along those lines).

Well according to you everything is as it should be except you get a high number of 'stales'
(and I've no idea even when you get these 'stales')
If you don't need help and wont supply the info I've requested - then why are you asking (for free help)?

[c4n10]

...
Then you need to provide a lot more information than 'I get high stales' ...........

Compare mining on 2 different pools.

What does the screen show during an LP?

Provide some actual numbers and the pool name from the cgminer screen.

GPU? OS? Cgminer version?

Is it P2Pool so you may as well expect high rejects?

Did you turn on --no-submit-stale?
(You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)

I don't really think I need to compare my mining on two different pools to know that a 10% - 12% stale ratio is high...

I also don't see why the pool name is relevant being that my cpu miners in the exact same pool have a stale rate of less than 1.5% but if you insist, I am on OzCoin.

During an LP the screen shows what it is supposed to show, it tells me when the long polling has detected a new block, it tells me when a share has been accepted or when a share has been rejected.

What numbers would you like me to provide you other than the ratio of stales I am getting? Are there other numbers which would be relevant to the number of stales I am getting?

GPU - Geforce gt 520 (yes, I am aware that it is a piece of crap in relation to mining)
OS - Windows 7 64-bit
cgminer version - 2.7.5

I am not using the --no-submit-stale flag (i'm not using ANY flags actually) and yes, I AM getting stales as opposed to rejects. cgminer specifically says that they are stales ("prevhash submitted" or something along those lines).

Well according to you everything is as it should be except you get a high number of 'stales'
(and I've no idea even when you get these 'stales')
If you don't need help and wont supply the info I've requested - then why are you asking (for free help)?

What information did you request that I did not supply other than comparing the mining between two different pools (which is useless because I am 99.99% sure that the problem is not with the pool, otherwise my cpuminers would be affected as well)?

I have supplied all the information you asked me for with the exception of the "actual numbers" from the cgminer screen which I asked you for clarification on because I can't provide you with numbers unless I know which numbers you need, especially when I can not find a relative correlation between the other numbers output by the miner and my stale ratio...

When do I get the stales...? I get the stales when my miner attempts to submit a solved share and is answered by the server with a message that reads something like:

Code:

"Stale share detected, submitting as user requested"

Then it prints something like:

Code:

"Rejected crazyblock.numbershere GPU 0 (prevhash-stale)"

[rocks]

Change this

Code:

$ CFLAGS="-O2 -Wall -march=native" ./configure

to this.

Code:

$ CFLAGS="-O2 -Wall -march=native" ./configure --enable-bitforce

Thanks Krak,

That got it to compile (it might be helpful to add to the FPGA-README file).

But cgminer still can not seem to find the bfl single. I've tried both auto-detect and specifiying various /dev/xxx paths, but nothing seems to work.

Code:

$ ./cgminer -o [pool] -u name -p pw
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)

All return

Code:

All devices disabled, cannot mine!

1) In Ubuntu does anyone know how to find the correct /dev/xxx device for a specific single?
2) I have x6500s running on the same machine (with MPBM) perfectly fine, could this be causing a conflict?
3) Is there any way to test the connection to a bfl single to see if the issue is an incorrectly configured miner, connection issue, or a problem with the single itself.

Any suggestions would be great, I managed to get a x6500 with no issues, but have not been able to get the single running for some reason.

Thanks!

[Krak]

Thanks Krak,

That got it to compile (it might be helpful to add to the FPGA-README file).

But cgminer still can not seem to find the bfl single. I've tried both auto-detect and specifiying various /dev/xxx paths, but nothing seems to work.

Code:

$ ./cgminer -o [pool] -u name -p pw
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)

All return

Code:

All devices disabled, cannot mine!

1) In Ubuntu does anyone know how to find the correct /dev/xxx device for a specific single?
2) I have x6500s running on the same machine (with MPBM) perfectly fine, could this be causing a conflict?
3) Is there any way to test the connection to a bfl single to see if the issue is an incorrectly configured miner, connection issue, or a problem with the single itself.

Any suggestions would be great, I managed to get a x6500 with no issues, but have not been able to get the single running for some reason.

Thanks!

According to the readme, you have to use --scan-serial /dev/ttyUSBn (where n is the device ID).

[-ck]

Probably haven't loaded the module for the bitforce devices.

[The00Dustin]

What information did you request that I did not supply other than comparing the mining between two different pools (which is useless because I am 99.99% sure that the problem is not with the pool, otherwise my cpuminers would be affected as well)?

FYI, if you are mining LTC wit the CPUs and BTC with the GPU, you are mining on different pools.  With the same name (ozcain), and even if they are at the same IP, they are not the same pool, because they are running on different daemons.  Also, with a GPU with a hash speed that slow, you aren't going to find a lot of shares, so that rate might not be so high.  Trying a different pool will confirm the problem is or isn't with ozcoin.  Then, either additional information can be used to find the problem or the GPU can be blamed.  Incidentally, if you try another pool and get less rejects, but the same U: (which might take weeks to normalize depending on how low your hashrate is), then these shares being submitted and rejected don't matter.  I'm sure the hashrate would be helpful in determining whether or not the higher reject rate is related.  When the shares occur might also be, for instance, do you see an LP or new block detected and then rejects, or are they random without LPs or new blocks detected?  If the problem is in the software, I'm guessing it's very likely to be related to the fact that you're using an nVidia card, so that information might have been useful much earlier on.

[rocks]

According to the readme, you have to use --scan-serial /dev/ttyUSBn (where n is the device ID).

Yes, sorry I had tried /dev/ttyUSBx before as well (just forgot to add it to the list), but it did not work either.

Code:

$ ./cgminer -o [pool] -u name -p pw
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/ttyUSB0
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)

All return

Code:

All devices disabled, cannot mine!

/dev/ttyUSB0 is the right device because it appears and disappears when I plug/unplug the single. But cgminer still does not recognize it.

Is there anyway to debug the connection and where the issue is? Ubuntu sees the new USB device when it's plugged in, so I'm not sure where the issue is...

Thanks!

[BitMinerN8]

According to the readme, you have to use --scan-serial /dev/ttyUSBn (where n is the device ID).

Yes, sorry I had tried /dev/ttyUSBx before as well (just forgot to add it to the list), but it did not work either.

Code:

$ ./cgminer -o [pool] -u name -p pw
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/ttyUSB0
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0
$ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)

All return

Code:

All devices disabled, cannot mine!

/dev/ttyUSB0 is the right device because it appears and disappears when I plug/unplug the single. But cgminer still does not recognize it.

Is there anyway to debug the connection and where the issue is? Ubuntu sees the new USB device when it's plugged in, so I'm not sure where the issue is...

Thanks!

I don't know if this will work for you or not, but when I built my Debian box to run all my BFL's I was running into the same type of issue. I am a linux novice but I like to learn and take a lot of notes. I ran across this command on some obscure post on the forums. I don't know exactly what this does, but it worked for me anyway. I eventually added as the last line in the /etc/rc.local file so it would start automatically on boot. Hope it works for you.

Code:

modprobe ftdi_sio vendor=0x0403 product=0x6014

[kano]

...
Is there anyway to debug the connection and where the issue is? Ubuntu sees the new USB device when it's plugged in, so I'm not sure where the issue is...

Thanks!

As per the README FAQ that no one ever reads:
Q: I'm having an issue. What debugging information should I provide?
A: Start cgminer with your regular commands and add -D -T --verbose and provide
the full startup output and a summary of your hardware, operating system, ATI
driver version and ATI stream version.

And the additions I've added recently that are in git:
Q: How do I get my BFL/Icarus/Lancelot/Cairnsmore device to auto-recognise?
A: On linux, if the /dev/ttyUSB* devices don't automatically appear, the only
thing that needs to be done is to load the driver for them:
BFL: sudo modprobe ftdi_sio vendor=0x0403 product=0x6014
Icarus: sudo modprobe pl2303 vendor=0x067b product=0x230
Lancelot: sudo modprobe ftdi_sio vendor=0x0403 product=0x6001
Cairnsmore: sudo modprobe ftdi_sio product=0x8350 vendor=0x0403
On windows you must install the pl2303 or ftdi driver required for the device
pl2303: http://prolificusa.com/pl-2303hx-drivers/
ftdi: http://www.ftdichip.com/Drivers/VCP.htm

Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
cgminer can't mine on them
A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
 sudo ls -las /dev/ttyUSB*
will give output like:
 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
This means your account must have the group 'dialout' or root priviledges
To permanently give your account the 'dialout' group:
 sudo usermod -G dialout -a `whoami`
Then logout and back in again

Edit: yes the above has been fixed

[Luke-Jr]

Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
cgminer can't mine on them
A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
 sudo ls -las /dev/ttyUSB*
will give output like:
 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
This means your account must have the group 'dialout' or root priviledges
To permanently give your account the 'dialout' group:
 sudo usermod -G dialout `whoami`
Then logout and back in again

FYI, this is bad advice and is likely to screw up your system.

[TheHarbinger]

Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
cgminer can't mine on them
A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
 sudo ls -las /dev/ttyUSB*
will give output like:
 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
This means your account must have the group 'dialout' or root priviledges
To permanently give your account the 'dialout' group:
 sudo usermod -G dialout `whoami`
Then logout and back in again

FYI, this is bad advice and is likely to screw up your system.

Well, no.  Adding your current user to the "dialout" group is not going to screw up anything. 

[Luke-Jr]

Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
cgminer can't mine on them
A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
 sudo ls -las /dev/ttyUSB*
will give output like:
 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
This means your account must have the group 'dialout' or root priviledges
To permanently give your account the 'dialout' group:
 sudo usermod -G dialout `whoami`
Then logout and back in again

FYI, this is bad advice and is likely to screw up your system.

Well, no.  Adding your current user to the "dialout" group is not going to screw up anything.

Indeed that wouldn't, but the commands Kano suggests also removes you from every other group. Including sudo. (BFGMiner has suggested almost idential but with the -a option for a few releases now)

[kano]

...

FYI, this is bad advice and is likely to screw up your system.

quoted for lulz

Fix in my posts and in the docs - lulz
https://github.com/ckolivas/cgminer/pull/312

Though I'm wondering if it was the green colour in my post that could cause GPU damage?

Edit: Oh and  if you did do it as I said without the '-a' then:
 whoami
 su -
 usermod -G adm,admin,cdrom,plugdev,lpadmin,sambashare -a username
Where username is the result of 'whoami'

That should cover most of what groups you lost.
On my Xubu 11.04 the above is the full list.

[EnergyVampire]

Hello,

I've been testing Windows 8 Consumer Preview but I am having a few issues getting cgminer 2.7.4 working properly.

Main problem: While running cgminer, I get spammed with "New block detected on network before longpoll" ( 1000s of these displaying the same exact time) and the hashrate begin to slowly decrease over time (drops from 550 Mh/s to 350 Mh/s per GPU after about an hour or so).

Minor problem: I am unable to get cgminer running with 5 GPUs, it doesn't even work with "cgminer -n". The OS, catalyst, MSI Afterburner, GPU-Z all recognize the 5 GPUs.

Thanks in advance for your reply.

[c4n10]

I recently switched to a geforce 9600 gt and I am having a problem using the scrypt algorithm in cgminer or any other miner for that matter.

In cgminer everything seems to work fine and then the application seems to hang immediately after "Long-polling activated for http://web.site" and does not progress any further. Please help!

[c4n10]

Never mind, I'm an idiot. I just needed to wait a few minutes...

[Fefox]

I have been doing some testing of CGMINER with my BFL Mini Rigs with the Bitminter Pool and noticed that CGMINER was not reporting Hardware Errors or what I think should be showing under HW:


Under the bitminter client I have one board in a Minirig that fails about 1 out of 15 proofs  (in the minter client it uses CPU to double-check the work from GPUs and FPGAs and if their work isn't valid, it gets flagged with a BOMB"

on the two minirigs, I tried running two concurrent copies of CGMINER one on a good board and one on the bad board, nothing really stands out between them stats wise, altho the bad does show up slower in the bitminter pool stats.

bad board has a U:18.8 and the good U:20.1 but other boards in the rigs are in that range..

should these errors be showing up under HW: ?

it seems the bad proofs don't get submitted to the pool, so it looks like CGMINER is checking them, finding them bad, throwing them away but forgets to count them.

not sure if this is some type of bug or im just doing something wrong?

btw Ver is 2.7.4

Thanks.