Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 231. (Read 5806004 times)
September 06, 2013, 04:45:06 AM
On IRC is really nice bot that helps in cases like this, it react on .faq and answer is "READ THE F**N README"
September 06, 2013, 03:54:21 AM
install ..... libudev
September 06, 2013, 01:42:20 AM
Sorry about the dumb question but:
I was running 3.3.1 and decided to upgrade to 3.4.2, Running Ubuntu 12.04, I get this error:
./cgminer: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
Is there an easy way to fix this? Googled around and there were no answers that solved this for me.
Thanks in advance.
I was running 3.3.1 and decided to upgrade to 3.4.2, Running Ubuntu 12.04, I get this error:
./cgminer: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
Is there an easy way to fix this? Googled around and there were no answers that solved this for me.
Thanks in advance.
September 05, 2013, 07:40:32 PM
Can i set the order of the pools directly in the cgminer-command without moving back and forth the pools with user/pass?
java API pools 
Edit: though I should have also mentioned the exact command: poolpriority (API-README)
September 05, 2013, 07:16:02 PM
TYVM for looking into that. Hrmph. Will disable antivirus on that one system and see if it makes a difference; have AV's running on every other system on the network, so I'll take a risk for troubleshooting.
Cheers !
Cheers !
Got a crash report under Windows while running the 3.4.2 debug build.
cgminer.exe caused a Stack Overflow at location 74946ae6 in module mswsock.dll.
Call stack:
74946AE6 mswsock.dll:74946AE6
Thanks very much for doing that. Unfortunately you're not going to like the answer. The crash is in the microsoft DLL provided and not in any of the cgminer code or any DLLs I distribute. It should not be possible for my software to make an operating system provided library crash unless there's a bug in the library. Googling around I can see a few exploits in the past for that particular DLL (so I assume some security update fixed it) and some trojans that have replaced or attached themselves to that DLL. Ironically a stack overflow is precisely the exploit described so the best I can guess is that there is an updated DLL in some software update somewhere.cgminer.exe caused a Stack Overflow at location 74946ae6 in module mswsock.dll.
Call stack:
74946AE6 mswsock.dll:74946AE6
September 05, 2013, 07:00:55 PM
Got a crash report under Windows while running the 3.4.2 debug build.
---
cgminer.exe caused a Stack Overflow at location 74946ae6 in module mswsock.dll.
Registers:
eax=00add5b8 ebx=03ff3098 ecx=ff676980 edx=ffffffff esi=03ff30a8 edi=00000000
eip=74946ae6 esp=03ff3000 ebp=03ff30f8 iopl=0 nv up ei pl zr na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
Call stack:
74946AE6 mswsock.dll:74946AE6
75ED6A28 WS2_32.dll:75ED6A28 select
00424FDF cgminer.exe:00424FDF
004251A8 cgminer.exe:004251A8
00413ED1 cgminer.exe:00413ED1
004B1BAB cgminer.exe:004B1BAB
76BD1287 msvcrt.dll:76BD1287 _itow_s
76BD1328 msvcrt.dll:76BD1328 _endthreadex
750833AA kernel32.dll:750833AA BaseThreadInitThunk
77259F72 ntdll.dll:77259F72 RtlInitializeExceptionChain
77259F45 ntdll.dll:77259F45 RtlInitializeExceptionChain
Thanks very much for doing that. Unfortunately you're not going to like the answer. The crash is in the microsoft DLL provided and not in any of the cgminer code or any DLLs I distribute. It should not be possible for my software to make an operating system provided library crash unless there's a bug in the library. Googling around I can see a few exploits in the past for that particular DLL (so I assume some security update fixed it) and some trojans that have replaced or attached themselves to that DLL. Ironically a stack overflow is precisely the exploit described so the best I can guess is that there is an updated DLL in some software update somewhere. ---
cgminer.exe caused a Stack Overflow at location 74946ae6 in module mswsock.dll.
Registers:
eax=00add5b8 ebx=03ff3098 ecx=ff676980 edx=ffffffff esi=03ff30a8 edi=00000000
eip=74946ae6 esp=03ff3000 ebp=03ff30f8 iopl=0 nv up ei pl zr na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
Call stack:
74946AE6 mswsock.dll:74946AE6
75ED6A28 WS2_32.dll:75ED6A28 select
00424FDF cgminer.exe:00424FDF
004251A8 cgminer.exe:004251A8
00413ED1 cgminer.exe:00413ED1
004B1BAB cgminer.exe:004B1BAB
76BD1287 msvcrt.dll:76BD1287 _itow_s
76BD1328 msvcrt.dll:76BD1328 _endthreadex
750833AA kernel32.dll:750833AA BaseThreadInitThunk
77259F72 ntdll.dll:77259F72 RtlInitializeExceptionChain
77259F45 ntdll.dll:77259F45 RtlInitializeExceptionChain
September 05, 2013, 06:20:30 PM
Any plans to add ASICminer blade support? Brickminer did but only linux at the moment...
i'd love to have that feature for my blade. i wont need the stratum proxy running then. cgminer is running on my pi with 5 usb block errupters and a ztex quad and ztex single anyway. and i dont have to touch brickminer.
September 05, 2013, 05:07:27 PM
I think that people are just saying that they know you guys would do it right and would prefer one stop shopping. Right now Slush's Proxy Server is is it and Slush has been markedly missing from his pool and, to my knowledge, hasn't been providing any kind of visible support. Maybe if you guys redid Slush's software people would be happy because they know they can depend on you guys. The blades are going to be an issue for a while yet.
Right on the money... Mining proxy is only one pool and blade has only 2 pools available. But still at current price it is the best miner that you can get and you get it right now. And if you can manage it to show shares and estimated speed not kb it would be even better...Firstly ... a history of difficulty change:
Code:
Difficulty Delta
11187257.46
12153411.70 8.64%
15605632.68 28.41%
19339258.27 23.92%
21335329.11 10.32%
26162875.68 22.63%
31256960.72 19.47%
37392766.13 19.63%
50810339.04 35.88%
65750060.14 29.40%
86933017.77 32.22%
11187257.46
12153411.70 8.64%
15605632.68 28.41%
19339258.27 23.92%
21335329.11 10.32%
26162875.68 22.63%
31256960.72 19.47%
37392766.13 19.63%
50810339.04 35.88%
65750060.14 29.40%
86933017.77 32.22%
Now ignoring electricity which is far from zero ...
To get your 4BTC back:
Assuming a 20% change each difficulty (last 3 have been ~30%+)
20% = ~ 11.67 days (per diff change)
100days = ~ 3.19740339 BTC
200days = ~ 3.87131435 BTC
300days = ~ 4.01209658 BTC
Assuming a 30% change each difficulty
30% = ~ 10.77 days (per diff change)
100days = ~ 2.46186984 BTC
200days = ~ 2.67882072 BTC
300days = ~ 2.69784551 BTC
So a few things:
1) They are very likely to not break even on BTC i.e. a BTC loss - so I can't see people with blades donating to get a getwork proxy server written
2) So far for all the work I've done with AsicMiner hardware of the past months I've made ... less than 0.15 BTC ... slave labour rates do better than that, so I'm not interested in helping AsicMiner make MILLIONS of dollars by fleecing the Bitcoin community of it's BTC and ensuring almost everyone who buys AsicMiner hardware loses BTC doing that
3) That's my opinion ...
September 05, 2013, 04:55:32 PM
Can i set the order of the pools directly in the cgminer-command without moving back and forth the pools with user/pass?
September 05, 2013, 04:51:09 PM
...
Kano or Ckolivas - any thoughts? Getting a bit desperate here.
Well ... firstly, as mentioned, I'd prefer to see the overall CPU usage not a screen snapshot at one particular time ... as I've explained already how to.Kano or Ckolivas - any thoughts? Getting a bit desperate here.
Run it for 15 minutes and get the top elapsed CPU and elapsed from the API (as I asked before)
Secondly, what is the CPU on that computer and what does cat /proc/cpuinfo | grep MHz say at the same time.
Thirdly, cgminer CPU usage includes the USB CPU usage ... that other miners will not have counted against them when they mine
They all do USB I/O but other miners CPU usage is not correct since the OS doesn't count the USB they all do, USB accounts for quite a lot of the CPU usage ...
September 05, 2013, 04:47:50 PM
I think that people are just saying that they know you guys would do it right and would prefer one stop shopping. Right now Slush's Proxy Server is is it and Slush has been markedly missing from his pool and, to my knowledge, hasn't been providing any kind of visible support. Maybe if you guys redid Slush's software people would be happy because they know they can depend on you guys. The blades are going to be an issue for a while yet.
Right on the money... Mining proxy is only one pool and blade has only 2 pools available. But still at current price it is the best miner that you can get and you get it right now. And if you can manage it to show shares and estimated speed not kb it would be even better... 
September 05, 2013, 04:41:22 PM
There is no point turning cgminer into an ancient getwork mining proxy.
It's a miner, not a mining proxy for some other getwork miner.
The blades have their own (crappy) getwork miner in them.
It's a miner, not a mining proxy for some other getwork miner.
The blades have their own (crappy) getwork miner in them.
I think that people are just saying that they know you guys would do it right and would prefer one stop shopping. Right now Slush's Proxy Server is is it and Slush has been markedly missing from his pool and, to my knowledge, hasn't been providing any kind of visible support. Maybe if you guys redid Slush's software people would be happy because they know they can depend on you guys. The blades are going to be an issue for a while yet.
September 05, 2013, 04:34:36 PM
...
Gotta run it as root.
Or follow one of the *READMEs that tells you how to configure libusb access to USB devices for a non root user. Gotta run it as root.
September 05, 2013, 04:31:16 PM
There is no point turning cgminer into an ancient getwork mining proxy.
It's a miner, not a mining proxy for some other getwork miner.
The blades have their own (crappy) getwork miner in them.
It's a miner, not a mining proxy for some other getwork miner.
The blades have their own (crappy) getwork miner in them.
September 05, 2013, 03:39:12 PM
Any plans to add ASICminer blade support? BFGminer did but only linux at the moment...
i'd love to have that feature for my blade. i wont need the stratum proxy running then. cgminer is running on my pi with 5 usb block errupters and a ztex quad and ztex single anyway. and i dont have to touch brickminer.
September 05, 2013, 03:11:33 PM
Any plans to add ASICminer blade support? BFGminer did but only linux at the moment...
September 05, 2013, 02:54:48 PM
Decided to just use the prebuilt Binaries instead of compiling it for Windows XP 32bit because I ran into too many problems. I can get CGminer to load but it is only recognizing the card in the first PCI-E slot. I have a dual card system with an Invidia gt520 in the first PCI-E slot and the XFX 5870 HD. Cgminer will only mine on the Nvidia card although it gives and error of Multiple OpenCl devices and ADL devices being misdetected/mismatched. I tried to use the -n function in a bat file but I get a brief flash of readout and then the program shuts down. I have been able to mine BTC on OpenCL via GIUminer on the ATI card but for some reason it's giving me errors for scrypt mining with CGminer. Any suggestions?
1. Is there anyway to generate a Log file so I can read the error output message?
2. Is there a command to put in the Bat file to ignore the primary card (nvidia) and only work off the secondary card (ati). Since I can't get -n command to function it I don't even know if it is being detected? It is being detected by cpuz and the system registry and I have been able to mine BTC with it but not Litecoin in scrypt?
1. Is there anyway to generate a Log file so I can read the error output message?
2. Is there a command to put in the Bat file to ignore the primary card (nvidia) and only work off the secondary card (ati). Since I can't get -n command to function it I don't even know if it is being detected? It is being detected by cpuz and the system registry and I have been able to mine BTC with it but not Litecoin in scrypt?
September 05, 2013, 02:19:01 PM
Update: Been testing a few things out, with some very strange behaviour & results.
Using 1 brick of 10 usb's = 3.5% cpu
" 2 " " 10 " = 12% cpu (x4!)
" 3 " " 10 " = 23% cpu (x2)
" 4 " " 10 " = 37% cpu (x0.5)
One would have thought that if 1 brick uses 3.5% cpu, then in theory 4 bricks would use a maximum of 14%, I know that's not how it works but I'm using layman's terms here. The result is the same no matter what order I try the bricks in or what usb port I use, but why the jump from 3.5% to 12% for 1 extra brick? In fact, why is it using so much cpu generally?
Kano or Ckolivas - any thoughts? Getting a bit desperate here.
Using 1 brick of 10 usb's = 3.5% cpu
" 2 " " 10 " = 12% cpu (x4!)
" 3 " " 10 " = 23% cpu (x2)
" 4 " " 10 " = 37% cpu (x0.5)
One would have thought that if 1 brick uses 3.5% cpu, then in theory 4 bricks would use a maximum of 14%, I know that's not how it works but I'm using layman's terms here. The result is the same no matter what order I try the bricks in or what usb port I use, but why the jump from 3.5% to 12% for 1 extra brick? In fact, why is it using so much cpu generally?
Kano or Ckolivas - any thoughts? Getting a bit desperate here.
September 05, 2013, 12:24:22 PM
I know I'm a bit late in menting this, but a few posts back there was a bit of confusion with where 'make clean' should go. I think people may have been getting confused with 'make distclean'. 'make clean' should just remove old object files, etc (things generated AFTER make is executed) leaving the configure file, etc intact. 'make distclean' will do the same as 'make clean' AND it will remove the configuration file, etc too. So 'make clean' should be safe to run after a autogen or configure command, 'make distclean' won't be safe. If you get an error when you type make clean that there is nothing to be done, that usually means that it's already clean.
I would imagine a good thing to do when building a new version is definitely to run 'make distclean' first to clean out old configs as well, especially if the build process has changed. Even better would be to just 'sudo rm -r' and do another git clone of the repo, then you know you are safe and don't have anything lying around if you are having problems with the build process.
I realise this was not the original posters problem in the end, but just though it should be mentioned for when people compile other things.
Alex
The problem is that with cgminer 3.4.1/2 there is a completely new configuration, so yeah anyone upgrading really needs to ensure they aren't skipping the autogen and configure ... so it's easier to say: rename the old directory (so you can get any config files or scripts from the old directory, if needed after you rebuild) and start again with an empty cgminer folder or fresh git clone ... even I made some mistakes with this back about 2 or 3 months ago when I was doing libusb version testing (and failed to switch the versions properly a few times)I would imagine a good thing to do when building a new version is definitely to run 'make distclean' first to clean out old configs as well, especially if the build process has changed. Even better would be to just 'sudo rm -r
I realise this was not the original posters problem in the end, but just though it should be mentioned for when people compile other things.
Alex
I have a build.sh file in my cgminer git working directory that I run every time I want to build cgminer. It looks like this:
Code:
#!/bin/sh
make distclean
CFLAGS="-O2 -Wall -march=native" ./autogen.sh --enable-bflsc --enable-icarus --disable-opencl
make
mv -f cgminer cgminer-nogpu
make distclean
CFLAGS="-O2 -Wall -march=native" ./autogen.sh --enable-bflsc --enable-icarus --disable-opencl
make
mv -f cgminer cgminer-nogpu
The 'make distclean' may not be necessary every time, but it doesn't take long.
Handy to have & a good idea - thanks.
September 05, 2013, 12:23:05 PM
I know I'm a bit late in menting this, but a few posts back there was a bit of confusion with where 'make clean' should go. I think people may have been getting confused with 'make distclean'. 'make clean' should just remove old object files, etc (things generated AFTER make is executed) leaving the configure file, etc intact. 'make distclean' will do the same as 'make clean' AND it will remove the configuration file, etc too. So 'make clean' should be safe to run after a autogen or configure command, 'make distclean' won't be safe. If you get an error when you type make clean that there is nothing to be done, that usually means that it's already clean.
I would imagine a good thing to do when building a new version is definitely to run 'make distclean' first to clean out old configs as well, especially if the build process has changed. Even better would be to just 'sudo rm -r' and do another git clone of the repo, then you know you are safe and don't have anything lying around if you are having problems with the build process.
I realise this was not the original posters problem in the end, but just though it should be mentioned for when people compile other things.
Alex
The problem is that with cgminer 3.4.1/2 there is a completely new configuration, so yeah anyone upgrading really needs to ensure they aren't skipping the autogen and configure ... so it's easier to say: rename the old directory (so you can get any config files or scripts from the old directory, if needed after you rebuild) and start again with an empty cgminer folder or fresh git clone ... even I made some mistakes with this back about 2 or 3 months ago when I was doing libusb version testing (and failed to switch the versions properly a few times)I would imagine a good thing to do when building a new version is definitely to run 'make distclean' first to clean out old configs as well, especially if the build process has changed. Even better would be to just 'sudo rm -r
I realise this was not the original posters problem in the end, but just though it should be mentioned for when people compile other things.
Alex
OK, here's where I'm at. I decided to do an upgrade to 13.04 64bit - fresh install of everything. This time I didn't start my p2pool node, opting to straight forward mine on a pool instead for testing purposes. The result is actually worse than with 12.04 I'm afraid, cgminer is now using 37% cpu:
Not sure what to make of this now, but for sure 37% is way too high for 40 usb sticks, and there's absolutely no chance of a previous build corrupting this one - it's all brand new........
I'm now ready to accept any and all possible solutions, no matter how ridiculous or far fetched they might sound - I really don't want to reduce myself to using the "other" mining software from "he who shall not be named"
Jump to: