OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 232.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: PatMan on September 05, 2013, 03:19:01 PM

...
Kano or Ckolivas - any thoughts? Getting a bit desperate here. Wink

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.
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 ...

Lucko

hero member

Activity: 826

Merit: 1000

Quote from: Trongersoll on September 05, 2013, 05:41:22 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...

Trongersoll

hero member

Activity: 490

Merit: 501

Quote from: kano on September 05, 2013, 05: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.

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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Wolf0 on September 05, 2013, 12:53:50 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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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.

streetuff

full member

Activity: 168

Merit: 100

Quote from: Lucko on September 05, 2013, 04:11:33 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.

Lucko

hero member

Activity: 826

Merit: 1000

Any plans to add ASICminer blade support? BFGminer did but only linux at the moment...

gristlelump

member

Activity: 110

Merit: 10

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?

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

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!) Shocked

" 3 " " 10 " = 23% cpu (x2)
" 4 " " 10 " = 37% cpu (x0.5) Shocked

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. Wink

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

Quote from: twmz on September 05, 2013, 12:12:13 PM

Quote from: kano on September 05, 2013, 10:51:59 AM

Quote from: ajw107 on September 05, 2013, 08:53:18 AM

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 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

The 'make distclean' may not be necessary every time, but it doesn't take long.

Handy to have & a good idea - thanks.

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

Quote from: kano on September 05, 2013, 10:51:59 AM

Quote from: ajw107 on September 05, 2013, 08:53:18 AM

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)

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" Wink

twmz

hero member

Activity: 737

Merit: 500

Quote from: kano on September 05, 2013, 10:51:59 AM

Quote from: ajw107 on September 05, 2013, 08:53:18 AM

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 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

The 'make distclean' may not be necessary every time, but it doesn't take long.

Rant2112

newbie

Activity: 70

Merit: 0

Quote from: -ck on September 04, 2013, 10:40:25 PM

Quote from: Rant2112 on September 04, 2013, 10:25:33 PM

I'm having trouble getting 3.4.2 working with my ASICMiner USB Block Erupter. I'm still using 3.1.1. 8(

I've looked at the usbfail post
https://bitcointalksearch.org/topic/m.2817682

I've built a local version of libusb-1.0.16-rc10

But, when I try to run cgminer's configure to use it it looks like it is still using the cgminer*/compat/libusb* version.

FYI - I only use this machine for mining so I would be happy to change libusb to whatever version works for cgminer if that's easier than pointing the cgminer make to my local libusb...

Thanks.

I wanted to make it easier for everyone so I modified the entire build tree to use the optimal libusb automatically, that's why it's now included in the cgminer release tarballs/git tree (it is 1.0.16-rc10) and is built into the cgminer binary statically. No need to do anything with libusb from the user side.

I am getting the timeout messages with my ASICMiner USB Block Erupter when I use 3.4.2.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ajw107 on September 05, 2013, 08:53:18 AM

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)

ProfMac

legendary

Activity: 1246

Merit: 1002

Quote from: kano on September 05, 2013, 03:56:47 AM

FYI - and I'd not be surprised at all if he didn't want me to say this - but when has that stopped me before ...

ckolivas isn't making any more firmware releases for now.
His OpenWRT thingy (whatever it is) died - he's mining over the USB connection.

So I'd suggest if someone wants more firmware releases, they should band together and send him the hardware needed to replace whatever it is that has a reset switch on it that broke.

Now the reason being the obvious one, that Team Avalon fucked you all over when it comes to support, ckolivas has been supporting you all very well, even though in my Kano vs GitSyncom thread, Team Avalon said I was wrongs suggesting that hardware was required to support them ... yet they pretty much didn't at all ... yeah clearly yet another thing to add the the list of crap from GitSyncom ...

So, yeah, get him a replacement OpenWRT board (I think that's what needed) if you want more firmware releases

I have a backup TP-Link 703n. I can also drop a public SSH key into dropbear on my Avalon.

Xian01

legendary

Activity: 1652

Merit: 1067

Christian Antkow

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

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

Yeah, thanks indeed. I actually deleted the cgminer folder a few times in an effort to ensure a completely "fresh" install, but still had the 30% cpu problem. I'm sure it's a usb issue, my usb controllers are nvidia (ugh!) so I'm currently searching for the latest linux driver for them in the hope that they're newer/better than the ones incorporated in Xubuntu 12.04 64bit (for kano) which I'm using. Failing that, I think it might be worth upgrading to Xubuntu 13.04 - maybe the usb controller drivers are better in that distro? I dunno, I'm grabbing at straws a little here.

Zanatos666

sr. member

Activity: 280

Merit: 250

Sometimes man, just sometimes.....

Quote from: ajw107 on September 05, 2013, 08:53:18 AM

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

Thanks for the clear up on this, I appreciate it.

ajw107

newbie

Activity: 40

Merit: 0

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

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

echo -n summary | nc -4 localhost 4028 | tr "|," "\n"

If you don't have nc ... I've no idea what package it is in coz I have no idea what linux you are using

As for building cgminer, if your cgminer is in /home/me/cgminer/ then:

cd /home/me
mv cgminer cgminer-old
git clone git://github.com/ckolivas/cgminer.git
cd cgminer

... and start autogen/configure all over again then make
Since I have no idea what is in your old cgminer folder (e.g. libusb from before or what)
this will ensure you are using a fresh 3.4.2 and the correct libusb which is part of 3.4.2 and you can't 'make' until you have successfully run autogen and configure and thus have updated all the makefiles

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