Bitcoin Forum
August 20, 2018, 07:05:33 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 [616] 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5761180 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
kano
Legendary
*
Offline Offline

Activity: 2548
Merit: 1052


Linux since 1997 RedHat 4


View Profile
September 05, 2013, 01:17:02 AM
 #12301

...
Right, now that I've done embarrassing myself, I'm still stuck with this 30% cpu usage problem - any ideas on that one?

Be gentle with me.......


Do that at the same time as the output of java API summary

I run 2 AMU erupters on a tiny RPi Raspbian and it uses only 1.8% CPU

Code:
23464 root      20   0  202m  59m 2868 S   1.6 16.0  47:03.55 cgminer-3.4.2a

[Elapsed] => 159427
(47*60+3.55)/159427 = 1.77...%

I note that you are also running bitcoind and possibly even p2pool (python) on that at the same time ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
1534791933
Hero Member
*
Offline Offline

Posts: 1534791933

View Profile Personal Message (Offline)

Ignore
1534791933
Reply with quote  #2

1534791933
Report to moderator
1534791933
Hero Member
*
Offline Offline

Posts: 1534791933

View Profile Personal Message (Offline)

Ignore
1534791933
Reply with quote  #2

1534791933
Report to moderator
1534791933
Hero Member
*
Offline Offline

Posts: 1534791933

View Profile Personal Message (Offline)

Ignore
1534791933
Reply with quote  #2

1534791933
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534791933
Hero Member
*
Offline Offline

Posts: 1534791933

View Profile Personal Message (Offline)

Ignore
1534791933
Reply with quote  #2

1534791933
Report to moderator
Rant2112
Jr. Member
*
Offline Offline

Activity: 70
Merit: 0



View Profile
September 05, 2013, 02:25:33 AM
 #12302

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://bitcointalk.org/index.php?topic=28402.msg2817682#msg2817682

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.
kano
Legendary
*
Offline Offline

Activity: 2548
Merit: 1052


Linux since 1997 RedHat 4


View Profile
September 05, 2013, 02:32:14 AM
 #12303

3.4.2 uses libusb-1.0.16-rc10
If you build it yourself, start with an empty directory.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2618
Merit: 1123


Ruu \o/


View Profile WWW
September 05, 2013, 02:40:25 AM
 #12304

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://bitcointalk.org/index.php?topic=28402.msg2817682#msg2817682

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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


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


View Profile WWW
September 05, 2013, 11:12:28 AM
 #12305

...
Right, now that I've done embarrassing myself, I'm still stuck with this 30% cpu usage problem - any ideas on that one?

Be gentle with me.......


Do that at the same time as the output of java API summary

I run 2 AMU erupters on a tiny RPi Raspbian and it uses only 1.8% CPU

Code:
23464 root      20   0  202m  59m 2868 S   1.6 16.0  47:03.55 cgminer-3.4.2a

[Elapsed] => 159427
(47*60+3.55)/159427 = 1.77...%

I note that you are also running bitcoind and possibly even p2pool (python) on that at the same time ...

Hey Kano,

Yes, this box is used solely as a p2pool node, all my other mining is done separately on other PC's. When compiling, does the make clean command empty the libusb directory? if not, can you give me a pointer as to where it is so I can empty it manually?  I'm not familiar with the java api summary I'm afraid, is there a command line string?

I have a feeling that the usb is the cause of the problem, it's just how to fix it I'm a little lost with. I've ran this box for months previously with very little cpu usage up until the latest update.

Thanks bro.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
-Redacted-
Hero Member
*****
Offline Offline

Activity: 574
Merit: 501


View Profile
September 05, 2013, 11:22:03 AM
 #12306

"java api summary" IS the command line.
kano
Legendary
*
Offline Offline

Activity: 2548
Merit: 1052


Linux since 1997 RedHat 4


View Profile
September 05, 2013, 12:14:29 PM
 #12307

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

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
ajw107
Jr. Member
*
Offline Offline

Activity: 40
Merit: 0



View Profile
September 05, 2013, 12:53:18 PM
 #12308

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 <cgminer directory>' 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
Zanatos666
Sr. Member
****
Offline Offline

Activity: 280
Merit: 250


Sometimes man, just sometimes.....


View Profile
September 05, 2013, 01:14:38 PM
 #12309

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 <cgminer directory>' 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.

Squiggly letters, written really fast, with a couple of dots for good measure.
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


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


View Profile WWW
September 05, 2013, 01:25:16 PM
 #12310

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.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
Xian01
Legendary
*
Offline Offline

Activity: 1400
Merit: 1016


Christian Antkow


View Profile
September 05, 2013, 01:28:59 PM
 #12311

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
ProfMac
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
September 05, 2013, 02:30:55 PM
 #12312

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

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 Smiley

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

I try to be respectful and informed.
kano
Legendary
*
Offline Offline

Activity: 2548
Merit: 1052


Linux since 1997 RedHat 4


View Profile
September 05, 2013, 02:51:59 PM
 #12313

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 <cgminer directory>' 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)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Rant2112
Jr. Member
*
Offline Offline

Activity: 70
Merit: 0



View Profile
September 05, 2013, 03:33:40 PM
 #12314

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://bitcointalk.org/index.php?topic=28402.msg2817682#msg2817682

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.
twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
September 05, 2013, 04:12:13 PM
 #12315

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 <cgminer directory>' 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.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
Wolf0
Legendary
*
Offline Offline

Activity: 1876
Merit: 1002


Miner Developer


View Profile
September 05, 2013, 04:53:50 PM
 #12316

I'm trying to mine with a USB Block Erupter on Arch Linux, and I get this:

Code:
[2013-09-05 11:50:11] Error -1001: clGetPlatformsIDs failed (no OpenCL SDK installed?)                    
 [2013-09-05 11:50:11] clDevicesNum returned error, no GPUs usable                    
 [2013-09-05 11:50:11] 0 GPU devices max detected                    
 [2013-09-05 11:50:11] USB all: found 9 devices - listing known devices
.USB dev 0: Bus 6 Device 2 ID: 10c4:ea60
  ** dev 0: Failed to open, err -3                    
 [2013-09-05 11:50:11] 1 known USB devices

Scratch that, I'm a dumbass. Gotta run it as root.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


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


View Profile WWW
September 05, 2013, 05:23:05 PM
 #12317

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 <cgminer directory>' 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

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


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


View Profile WWW
September 05, 2013, 05:24:22 PM
 #12318

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 <cgminer directory>' 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.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


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


View Profile WWW
September 05, 2013, 07:19:01 PM
 #12319

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

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
gristlelump
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile
September 05, 2013, 07:54:48 PM
 #12320

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?

Pages: « 1 ... 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 [616] 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 ... 847 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!