Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 489. (Read 5806057 times)

legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
New release - Version 2.7.6, 24th September 2012
Looks like wrong count of Q is not only LTC error.
While mining BTC:
Code:
 cgminer version 2.7.6 - Started: [2012-09-24 11:51:45]
--------------------------------------------------------------------------------
 (5s):13.1 (avg):13.6 Mh/s | Q:3  A:10  R:0  HW:0  E:333%  U:0.3/m
 TQ: 0  ST: 1  SS: 0  DW: 2  NB: 7  LW: 512  GF: 0  RF: 0  WU: 0.3
 Connected to http://rav3n.dtdns.net:9332 with LP as user 14BRrqqjWtdVNp9LEe12zG
 Block: 00000571e5eb37aaa182b06b14cfcc43...  Started: [12:16:13]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  63.0C  52%    |  13.1/ 13.6Mh/s | A:10 R:0 HW:0 U:0.25/m I: 3
--------------------------------------------------------------------------------

 [2012-09-24 12:29:53] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:29:57] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:06] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:13] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:19] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:29] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:32] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:37] LONGPOLL from pool 0 requested work restart
 [2012-09-24 12:30:40] LONGPOLL from pool 0 requested work restart
So many longpools, 7 NB and Q is still 3.
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
It looks normal to me, after a while it should start spamming accepted shares and longpool messages.
member
Activity: 81
Merit: 10
I run 2.7.6 in LTC p2pool:
cgminer --scrypt --worksize 256 --lookup-gap 2 --thread-concurrency 7200 -g 1 -I 12 -o http://127.0.0.1:9327 -u abc -p 123

it returns:


what's the matter?
LTC-qt and p2pool run successfully, because pooler-cpuminer is mining normally.

the VGAcard is HD4650
full member
Activity: 168
Merit: 100
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



*** 2.7.6 is displaying those errors now and is counting them under HW:   Cheesy
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Firstly a short explanation of some of the 2.7.6 additions, then the 2.7.6a download link for anyone still using Xubuntu 11.04

Hardware errors are now identified (the same way) for the devices: GPU/ICA/BFL/MMQ
ZTX code is however unchanged since it has it's own method and I can't test it

WorkTime debug - a rather detailed message that can be enabled on the end of each Accept/Reject line
displaying timing and other details about the work, from request, to process, to submit
See the [ D]isplay screen in cgminer and the API debug command for enabling it

cgminer now internally has all the work difficulty information calculated and available via the API
(and ckolivas has added the difficulty to the share display line also)

You can now specify a proxy for each pool. It's a little different to the --socks-proxy option
since you also specify the proxy type in front of the proxy (--socks-proxy is unchanged)

BFL now has the option to flash the led via the API - so you can identify which BFL is which
N.B. this introduces a 4 second delay into share processing - so only use it when necessary
The API now also reports a count of the number of times your BFL throttles with the 'notify' command

When forcefully identifying FPGA's you can now also use the abbreviated 3 character FPGA name
e.g. either Icarus:/dev/ttyUSB0 or ICA:/dev/ttyUSB0 is now valid (the identifier is not case sensitive)

miner.php - now uses the correct difficulty for the display highlighting tests

---

cut/paste ...

2.7.6
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.7.6a
https://github.com/kanoi/cgminer/downloads
(oh and it also works on Fedora 16 and 17)

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far on my BFL or my '2xGPU+2xIcarus'

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt

---

No more windows FPGA binaries needed from me for now, since ckolivas now has cgminer-fpga.exe in his 2.7.6 windows 7zip file
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New release - Version 2.7.6, 24th September 2012

In anticipation of more instability once I start implementing the stratum protocol, I have released this updated version with only safe changes that can be relied upon to be stable.


Human readable changelog:

Should have finally fixed the "dynamic intensity gets stuck at a low value" bug.
Build will detect default SDK installation on linux now that AMD SDK 2.7 exports variables defining it.
Fixed the disabled/enabled/disabled thread when changing to dynamic intensity
The share hash display has been compacted further and the difficulty is now shown in anticipation of many pools moving to variable difficulty shares.
If a pool's server was alive but not returning work cgminer could have bombarded it with requests instead of failing.
Lots of goodies thanks to Kano who was working hard while I was away; I'll let him elaborate next post Smiley


Full changelog:

- Display share difficulty on log with a shortened hash display on submission.
- API stats add some pool getwork difficulty stats
- Ignore any pings pushed to the worker threads if the thread is still paused to
prevent it being enabled and disabled repeatedly.
- README - FAQ - usermod group - shouldn't remove other groups
- Test for sequential getwork failures on a pool that might actually be up but
failing to deliver work as we may end up hammering it repeatedly by mistake.
- reduce windows compile warnings
- util.c - bug - proxy - no data end condition
- As we average gpu time over 5 work intervals for dynamic GPU intensity, there
is no need to maintain a rolling average and it avoids the potential long term
corruption of a single overflow value.
- Test for the now-automatically exported variable AMDAPPSDKROOT when looking
for the presence of the OpenCL headers.
- API don't change 'Diff1 Shares' - backward compatability FTW
- miner.php highlighting correctly handling difficulty
- API - Add last share difficulty for devices and pool
- Store and report Accepted,Rejected,Stale difficulty in the summary and API
- WorkTime - display prevblock for scrypt
- api.c remove compile warnings
- Calculate work difficulty for each getwork and display with WorkTime debug
- remove MMQ unused variable warning
- FPGA - allow long or short device names in detect code + style police
- WorkTime - multiple nonce per work and identify the work source
- Optional WorkTime details with each Accepted/Rejected work item
- Icarus - ignore hardware errors in timing mode
- miner.php oops - mistype
- miner.php by default don't display IP/Port numbers in error messages
- api.c all STATUS messages automatically escaped
- api.c add missing escape for comma in MSG_PGAUNW
- API add display of and setting queue,scantime,expiry
- HW: dont submit bad shares
- save individual pool proxy settings to config
- --default-config - allow command line to define the default configuration file
for loading and saving
- API-README update for pools proxy info
- README URL proxy must use quote so show in the example
- bug: remove proxy: from the front of the proxy used
- CURL support for individual proxy per pool and all proxy types
- README spelling/etc
- README - FPGA device FAQ
- HW: error counter auto for all devices - ztex code not fixed
- API pgaidentify - unsupported message should be a warning
- API/BFL identify a device - currently only BFL to flash the led
- BFL add throttle count to internal stats + API
- BFL: missing device id in log message
- miner.php correct to new Diff1 Work field names
- API add device diff1 work
- API-README update
- api.c Correct diff1 field name
- count device diff1 shares
- API-README more debug parameter information
- API allow full debug settings control
legendary
Activity: 2576
Merit: 1186
Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
cgminer can't mine on them
...
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)
Unfortunately, when you pulled that change from my git into your git - you didn't fix it then either.
Your README still says that also.
You'll need the commit in my git that's been pulled into cgminer to fix it ..
No, I just forgot to push when I fixed it in BFGMiner - though I'll probably overwrite it with yours before the next release.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
cgminer can't mine on them
...
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)
Unfortunately, when you pulled that change from my git into your git - you didn't fix it then either.
Your README still says that also.
You'll need the commit in my git that's been pulled into cgminer to fix it ..
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
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:

...

btw Ver is 2.7.4

Thanks.
Current git (i.e. after 2.7.5)
full member
Activity: 168
Merit: 100
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.
sr. member
Activity: 294
Merit: 250
Never mind, I'm an idiot. I just needed to wait a few minutes...
sr. member
Activity: 294
Merit: 250
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!
full member
Activity: 210
Merit: 100
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.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
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.
legendary
Activity: 2576
Merit: 1186
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)
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
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. 
legendary
Activity: 2576
Merit: 1186
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.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
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
hero member
Activity: 626
Merit: 500
Mining since May 2011.
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
legendary
Activity: 1153
Merit: 1000
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!
Jump to: