Upgraded, but had to turn stratum off on p2pool as my DOA/Stale rate went through the roof, even after lowering my intensity on both Linux & windoze rigs. Anyone else had this problem?
Same problem here.
M
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 417. (Read 5805537 times)
December 31, 2012, 08:11:51 PM
Same problem here.
M
December 31, 2012, 08:00:06 PM
Hello.
Anyone who knows and knows how to use the command cgminer --gpu-map?
I got a problem:
OpenCl number corresponds to the number of devices is not ADL and the decision - is to use this command.
In the map units, the last card is marked as
....
6. 09:00
7. 0a: 00
8. 0b: 00
I do not understand how to use it and how to write config. Help, who can ....
Anyone who knows and knows how to use the command cgminer --gpu-map?
I got a problem:
OpenCl number corresponds to the number of devices is not ADL and the decision - is to use this command.
In the map units, the last card is marked as
....
6. 09:00
7. 0a: 00
8. 0b: 00
I do not understand how to use it and how to write config. Help, who can ....
December 31, 2012, 12:49:05 PM
Upgraded, but had to turn stratum off on p2pool as my DOA/Stale rate went through the roof, even after lowering my intensity on both Linux & windoze rigs. Anyone else had this problem?
Same problem here.
M
December 31, 2012, 11:26:34 AM
no DoA/Orphans here
December 31, 2012, 11:12:10 AM
Upgraded, but had to turn stratum off on p2pool as my DOA/Stale rate went through the roof, even after lowering my intensity on both Linux & windoze rigs. Anyone else had this problem?
December 31, 2012, 10:09:29 AM
Lucky you! Have a great time!!
December 31, 2012, 05:05:04 AM
Thought I'd give you all a heads up warning.
I'll be away overseas, enjoying Japan from the 5th to the 23rd of January.... While this is the time frame that perhaps one of the first ASICs comes into existence, the fact is that I really couldn't care less while travelling. Thus I wish to inform you that my right hand man, Kano(i), will be the only person around who will be producing officially sanctioned cgminer code while I'm away. So if and when the hardware does appear, and you wish to use cgminer to mine on that hardware, please use source and/or binaries provided by him.
enjoy ur holiday I'll be away overseas, enjoying Japan from the 5th to the 23rd of January.... While this is the time frame that perhaps one of the first ASICs comes into existence, the fact is that I really couldn't care less while travelling. Thus I wish to inform you that my right hand man, Kano(i), will be the only person around who will be producing officially sanctioned cgminer code while I'm away. So if and when the hardware does appear, and you wish to use cgminer to mine on that hardware, please use source and/or binaries provided by him.
December 31, 2012, 05:02:01 AM
Thought I'd give you all a heads up warning.
I'll be away overseas, enjoying Japan from the 5th to the 23rd of January.... While this is the time frame that perhaps one of the first ASICs comes into existence, the fact is that I really couldn't care less while travelling. Thus I wish to inform you that my right hand man, Kano(i), will be the only person around who will be producing officially sanctioned cgminer code while I'm away. So if and when the hardware does appear, and you wish to use cgminer to mine on that hardware, please use source and/or binaries provided by him.
I'll be away overseas, enjoying Japan from the 5th to the 23rd of January.... While this is the time frame that perhaps one of the first ASICs comes into existence, the fact is that I really couldn't care less while travelling. Thus I wish to inform you that my right hand man, Kano(i), will be the only person around who will be producing officially sanctioned cgminer code while I'm away. So if and when the hardware does appear, and you wish to use cgminer to mine on that hardware, please use source and/or binaries provided by him.
December 30, 2012, 09:42:38 PM
Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.
How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
I first assumed this which is why I upgraded. However after upgrading it would not mine on coinlab and will not on Ozcoin either unless it is on the Stratum pool. Maybe its something with the way BAMT talks to cgminer?
December 30, 2012, 09:38:45 PM
Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.
How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
I first assumed this which is why I upgraded. However after upgrading it would not mine on coinlab and will not on Ozcoin either unless it is on the Stratum pool. Maybe its something with the way BAMT talks to cgminer?
December 30, 2012, 09:37:25 PM
Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.
How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
I first assumed this which is why I upgraded. However after upgrading it would not mine on coinlab and will not on Ozcoin either unless it is on the Stratum pool. Maybe its something with the way BAMT talks to cgminer?
December 30, 2012, 09:32:47 PM
Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.
How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork. How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
December 30, 2012, 09:29:47 PM
Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.
How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.
December 30, 2012, 08:52:31 PM
Is anyone else having difficulties with the reliability of using a raspberry pi with cgminer (and bfgminer) to manage fpga miners (in my case bitforce and icarus). I've found that cgminer 2.10.4 gives out comm errors on bitforce miners (at random). Bfgminer has problems as well outlined in this thread: https://bitcointalksearch.org/topic/m.1426976
The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.
I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?
I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.
The usb on rpi is known to be really flaky. The addition of a powered usb hub usually fixes most problems as it acts as a usb filter as well as running more usb devices better.The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.
I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?
I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.
Well that's the thing. I am of course using a powered usb hub, and it gave me no troubles when connected to a windows box.
One thing that I noticed is that the pi powered itself up when I plugged in the usb hub to it so it's drawing from the usb hub (as it should/can) but I still have the power brick plugged in on the pi as well. Should I shutdown the pi and power it up with it's own power brick first and THEN connect the USB hub? Does this order make any difference? I have doubts whether it will resolve the flaky usb issues but it's worth a try, no?
December 30, 2012, 08:39:47 PM
Is anyone else having difficulties with the reliability of using a raspberry pi with cgminer (and bfgminer) to manage fpga miners (in my case bitforce and icarus). I've found that cgminer 2.10.4 gives out comm errors on bitforce miners (at random). Bfgminer has problems as well outlined in this thread: https://bitcointalksearch.org/topic/m.1426976
The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.
I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?
I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.
The usb on rpi is known to be really flaky. The addition of a powered usb hub usually fixes most problems as it acts as a usb filter as well as running more usb devices better. The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.
I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?
I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.
December 30, 2012, 08:35:23 PM
Is anyone else having difficulties with the reliability of using a raspberry pi with cgminer (and bfgminer) to manage fpga miners (in my case bitforce and icarus). I've found that cgminer 2.10.4 gives out comm errors on bitforce miners (at random). Bfgminer has problems as well outlined in this thread: https://bitcointalksearch.org/topic/m.1426976
The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.
I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?
I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.
The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.
I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?
I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.
December 30, 2012, 08:02:26 PM
I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Returns the following:
Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Code:
CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev
Code:
curses.TUI...........: FOUND: -lncurses
Code:
util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)
That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.
That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.
I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev
Code:
Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...
Thank you for your time.
December 30, 2012, 07:56:57 PM
I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Returns the following:
Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Code:
CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev
Code:
curses.TUI...........: FOUND: -lncurses
Code:
util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)
That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.
That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.
I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev
Code:
Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...
Thank you for your time.
December 30, 2012, 07:28:48 PM
I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Returns the following:
Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Code:
CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev
Code:
curses.TUI...........: FOUND: -lncurses
Code:
util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)
That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.
That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.
December 30, 2012, 07:21:09 PM
I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Returns the following:
Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)
I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.
Code:
CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev
Code:
------------------------------------------------------------------------
cgminer 2.10.4
------------------------------------------------------------------------
Configuration Options Summary:
curses.TUI...........: FOUND: -lncurses
OpenCL...............: NOT FOUND. GPU mining support DISABLED
scrypt...............: Disabled (needs OpenCL)
ADL..................: SDK NOT found, GPU monitoring support DISABLED
BitForce.FPGAs.......: Enabled
Icarus.FPGAs.........: Disabled
ModMiner.FPGAs.......: Disabled
Ztex.FPGAs...........: Disabled
libudev.detection....: yes
Compilation............: make (or gmake)
CPPFLAGS.............:
CFLAGS...............: -g -O2 -W -Wall
LDFLAGS..............: -lpthread
LDADD................: -L/usr/lib -lcurl compat/jansson/libjansson.a -lpthread -lm -ludev
Installation...........: make install (as root if needed, with 'su' or 'sudo')
prefix...............: /usr/local
Code:
make[2]: Leaving directory `/opt/miners/ckolivas-cgminer-b53372b/ccan'
make[2]: Entering directory `/opt/miners/ckolivas-cgminer-b53372b'
CC cgminer-cgminer.o
CC cgminer-util.o
util.c: In function âkeep_curlaliveâ:
util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)
util.c:207: error: (Each undeclared identifier is reported only once
util.c:207: error: for each function it appears in.)
util.c:207: warning: type defaults to âintâ in declaration of â_curl_optâ
util.c:208: error: âCURLOPT_TCP_KEEPIDLEâ undeclared (first use in this function)
util.c:208: warning: type defaults to âintâ in declaration of â_curl_optâ
util.c:209: error: âCURLOPT_TCP_KEEPINTVLâ undeclared (first use in this function)
util.c:209: warning: type defaults to âintâ in declaration of â_curl_optâ
make[2]: *** [cgminer-util.o] Error 1
make[2]: Leaving directory `/opt/miners/ckolivas-cgminer-b53372b'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/miners/ckolivas-cgminer-b53372b'
make: *** [all] Error 2
Jump to: