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

Krak

hero member

Activity: 591

Merit: 500

Quote from: af_newbie on May 01, 2012, 01:31:52 PM

The detection of PGAs is something that should be fixed. Users should be able to say, I want these com ports to use BFLs, and the other ones to use
ZTEX or Icarus.

I think that might be something luke_jr can add to bfgminer as it looks like cgminer is blindly trying to guess what is connected to COM ports.
(and failing). Putting device type in the config file for each COM port would speed up detection and hopefully eliminate these issues.

Doing ZTEX detection on BFL or Icarus is just asking for it. Users know what they have connected to each port, so let them add that in the config file.

Here you go.

Quote from: kano on April 29, 2012, 05:52:02 PM

The detection code is quite straight forward for each FPGA.

If you wish to force it to be specifically BFL or ICA you can e.g. "-S bitforce:COM6" or "-S icarus:COM6"
ZTX detection is completely different so there is no real overlap (you don't specify the ztex devices, it always directly detects them)

It checks for BFL first:
It sends it a command (ZGX) which the BFL replies and is checked for the string "SHA256" in it - part of the reply is also where the "Model" in the API command 'devdetails' comes from

Next it checks for Icarus:
It simply just sends it some work and waits 0.1s for the answer
(I checked the block chain for a low nonce and found Ozcoin block 171874 nonce = (0xa2870100) = 0x000187a2 takes ~0.53ms on Rev3 Icarus to be the lowest nonce in the thousands I got a script to look at until the script bugged out)
This is mandatory for ICA since there is no identification anywhere other than the USB device identification
(which course could be used by other non Icarus devices since it's not unique)

Thus with that code (above) the ordering naturally should be BFL first and ICA 2nd if you don't specify "-S bitforce:COM6" or "-S icarus:COM6"

ZTX is detect third since that was added 3rd (though I might consider moving it up to first since it's very direct how it works and unlikely to ever affect any other device)
You don't specify -S for ZTX

Edit: for auto detection of course ZTX is always auto
ICA doesn't ever do auto
BFL does auto only in linux and only when you specify -S auto - however it has 2 methods:
1) where it looks in /dev/serial/by-id (which can sometimes only show 1 BFL on some linux versions if you have more than 1 BFL)
2) by libudev checking the USB Model when libudev is compiled in

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: check_status on May 01, 2012, 12:04:13 PM

Using cgminer 2.3.2
Cgminer hangs or freezes, the curl display is unresponsive not accepting any keyboard commands, mining has stopped, system is not frozen or locked up.
What is the recommended method to start up mining again?
Is it OK to 'kill ' before starting a new session?

APIs work? Send "quit" command.

Sounds like a deadlock somewhere. If nothing works, just kill it and reboot.

Tinua

hero member

Activity: 871

Merit: 1000

Quote from: af_newbie on May 01, 2012, 12:05:46 PM

Quote from: Tinua on May 01, 2012, 11:56:34 AM

Hi folks

If I connect more then 10 BFL's....cgminer crash down after 2 second? Huh

If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

Post more details. Are you mining on GPUs or just BFLs? What crashes?
Do you have an exception? What is the exception offset?

Hi
1. Starting cgminer.bat

Code:

cgminer1 -o http://pool1:8332 -u worker -p pass -o http://pool2:8332 -u name -p pass --disable-gpu -S COM5 -S COM6 -S COM7 -S COM8 -S \\.\COM9 -S \\.\COM10 -S \\.\COM11 -S \\.\COM12 -S \\.\COM13 -S \\.\COM54 -S \\.\COM55 -S \\.\COM56 -S \\.\COM57 -S \\.\COM58 -S \\.\COM59

2. cgminer starting:

Code:

[2012-05-01 19:41:05] Started cgminer 2.3.6
[2012-05-01 19:41:07] Found 0 ztex board(s)

3. Windowsbox coming:

Code:

cgminer1.exe not working anymore.....blablabla

Means....cgminer crashing

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: check_status on April 30, 2012, 05:58:02 AM

/**FPGA's will not take over once I release my Zero-Point Energy Generator. The enrergy it produces will be free, but the device is gonna cost you. Cool

The environmentalist nut cases will never allow that.

phorensic

hero member

Activity: 630

Merit: 500

Quote from: Tinua on May 01, 2012, 11:56:34 AM

Quote from: Epoch on April 29, 2012, 05:53:55 PM

Quote from: bombo999 on April 29, 2012, 05:44:57 PM

cgminer does not seem to detect my connected bfl single ... is there a setting that i'm missing?

If you are in Windows, your basic command line should look something like this:

Code:

cgminer -o  -u  -p  --disable-gpu -S COM6

The '-S COM6' is the relevant part for your Single. It happens to be COM6 for me, but it will likely be something else for you.

You'll need to open up Device Manager, go to the Ports section, and you should see an entry that looks like 'USB Serial Port (COMx)'. Whatever 'COMx' is in your case, that's what you put into cgminer's '-S COMx' setting. Then your Single should be detected.

edit: I should add that if your COM port is greater than 9, you need to use the 'longhand' form for cgminer. So if, for example, your assigned COM port for your Single was COM12, your command line would need to look like this:

Code:

cgminer -o  -u  -p  --disable-gpu -S \\.\COM12

Hi folks

If I connect more then 10 BFL's....cgminer crash by starting? Huh

If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

Before anyone bashes him on using Windows 8, I would like to say I'm using Windows 8 to mine, with cgminer, and it's working flawlessly. Mind you I don't have FPGA's or 10+ devices, though.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: Tinua on May 01, 2012, 11:56:34 AM

Hi folks

If I connect more then 10 BFL's....cgminer crash down after 2 second? Huh

If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

Post more details. Are you mining on GPUs or just BFLs? What crashes?
Do you have an exception? What is the exception offset?

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

Using cgminer 2.3.2
Cgminer hangs or freezes, the curl display is unresponsive not accepting any keyboard commands, mining has stopped, system is not frozen or locked up.
What is the recommended method to start up mining again?
Is it OK to 'kill ' before starting a new session?

Tinua

hero member

Activity: 871

Merit: 1000

Quote from: Epoch on April 29, 2012, 05:53:55 PM

Quote from: bombo999 on April 29, 2012, 05:44:57 PM

cgminer does not seem to detect my connected bfl single ... is there a setting that i'm missing?

If you are in Windows, your basic command line should look something like this:

Code:

cgminer -o  -u  -p  --disable-gpu -S COM6

The '-S COM6' is the relevant part for your Single. It happens to be COM6 for me, but it will likely be something else for you.

You'll need to open up Device Manager, go to the Ports section, and you should see an entry that looks like 'USB Serial Port (COMx)'. Whatever 'COMx' is in your case, that's what you put into cgminer's '-S COMx' setting. Then your Single should be detected.

edit: I should add that if your COM port is greater than 9, you need to use the 'longhand' form for cgminer. So if, for example, your assigned COM port for your Single was COM12, your command line would need to look like this:

Code:

cgminer -o  -u  -p  --disable-gpu -S \\.\COM12

Hi folks

If I connect more then 10 BFL's....cgminer crash by starting? Huh

If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

ancow

full member

Activity: 373

Merit: 100

Quote from: Zenitur on May 01, 2012, 07:31:22 AM

I have not used GIT to get the latest copy of CGMINER. I've downloaded all archives of 2.3.x versions of it, and tried to compile in Debian 5.0 "Lenny". All versions before 2.3.4 compiled successfully.

In case Inaba's suggestion doesn't work, could you try the latest git pull to see if that compiles? And if not, do a git bisect to trace the commit that is causing your problems?

Inaba

legendary

Activity: 1260

Merit: 1000

I've run into that problem. Try:

make clean
./autogen.sh
./configure
make

Zenitur

sr. member

Activity: 362

Merit: 250

Quote from: kano on May 01, 2012, 05:09:58 AM

Well all I can guess is there must be something wrong with your compiler or something messed up about your git pull/clone or some issue with the ./configure options you used.

The "die:" label has been there since 2011-11-24 (go to https://github.com/ckolivas/cgminer/blame/master/api.c to check for yourself)
Also the code compiles fine on quite a few architectures including xubuntu, fedora 16, debian, MinGW on windows
I've even just done another git pull and compiled it.

What git pull/clone command did you use and what ./configure command did you use?

If you pulled on top of an old version, make sure you './autogen.sh' './configure --xxx' and 'make clean' again before compiling.

I have not used GIT to get the latest copy of CGMINER. I've downloaded all archives of 2.3.x versions of it, and tried to compile in Debian 5.0 "Lenny". All versions before 2.3.4 compiled successfully.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Zenitur on May 01, 2012, 03:50:03 AM

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.

Code:

  CC     usage.o
  AR     libccan.a
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6/ccan'
make[2]: Entering directory `/home/kanotix/cgminer-2.3.6'
  CC     cgminer-cgminer.o
  CC     cgminer-util.o
  CC     cgminer-sha2.o
  CC     cgminer-api.o
api.c: In function ‘api’:
api.c:2409: error: label at end of compound statement
make[2]: *** [cgminer-api.o] Error 1
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make: *** [all] Error 2

Tested with NVIDIA and ATi/AMD OpenCL's. OS: Linux x86. GCC: 4.3.

Well all I can guess is there must be something wrong with your compiler or something messed up about your git pull/clone or some issue with the ./configure options you used.

The "die:" label has been there since 2011-11-24 (go to https://github.com/ckolivas/cgminer/blame/master/api.c to check for yourself)
Also the code compiles fine on quite a few architectures including xubuntu, fedora 16, debian, MinGW on windows
I've even just done another git pull and compiled it.

What git pull/clone command did you use and what ./configure command did you use?

If you pulled on top of an old version, make sure you './autogen.sh' './configure --xxx' and 'make clean' again before compiling.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: phorensic on April 30, 2012, 05:01:25 PM

ckolivas, any chance you can take a look at the possibility of churning some code out to take advantage of the Intel HD GPU's integrated into Sandy Bridge CPU's (and now Ivy Bridge)? Apparently they just released OpenCL SDK to allow access to the GPU portion of the CPU instead of just the CPU itself. See post #22 here - https://bitcointalksearch.org/topic/m.870723

If it's opencl then they should already work. Performance, on the other hand, is likely to be shit. Not because of my opencl code, but because they are pissweak.

Zenitur

sr. member

Activity: 362

Merit: 250

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.

Code:

  CC     usage.o
  AR     libccan.a
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6/ccan'
make[2]: Entering directory `/home/kanotix/cgminer-2.3.6'
  CC     cgminer-cgminer.o
  CC     cgminer-util.o
  CC     cgminer-sha2.o
  CC     cgminer-api.o
api.c: In function ‘api’:
api.c:2409: error: label at end of compound statement
make[2]: *** [cgminer-api.o] Error 1
make[2]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kanotix/cgminer-2.3.6'
make: *** [all] Error 2

Tested with NVIDIA and ATi/AMD OpenCL's. OS: Linux x86. GCC: 4.3.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: kano on April 30, 2012, 11:29:41 AM

Firstly, why do I need to mention what small parts of api.c you wrote?

You should attribute things like that, because it sure did look like you were trying to claim credit for it.

Quote from: kano on April 30, 2012, 11:29:41 AM

Hmm - so (as can be seen above) I told you to move the extra info to it's own command rather than have it the way that you designed to send that extra static never changing info EVERY time you request 'devs', 'gpu|N' or 'pga|N' - and that was less efficient?

I'm talking about the implementation. As you noted, I did move it to a new command, as you requested.

Quote from: kano on April 30, 2012, 11:29:41 AM

Hmm - and you send your "get_extra_device_detail(cgpu)" both with the 'devs' command and the 'devdetail' command - i.e. duplicating it.

No, 'devs' uses get_extra_device_status, and 'devdetail' uses get_extra_device_detail. Different methods for different purposes.

phorensic

hero member

Activity: 630

Merit: 500

ckolivas, any chance you can take a look at the possibility of churning some code out to take advantage of the Intel HD GPU's integrated into Sandy Bridge CPU's (and now Ivy Bridge)? Apparently they just released OpenCL SDK to allow access to the GPU portion of the CPU instead of just the CPU itself. See post #22 here - https://bitcointalksearch.org/topic/m.870723

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: The00Dustin on April 30, 2012, 09:38:28 AM

Quote from: -ck on April 27, 2012, 11:28:23 PM

- Use longpolls from backup pools with failover-only enabled just to check for
block changes, but don't use them as work.

I don't have enough data or it to be definitive yet, but I'm wondering if this didn't slightly lower my Utility. I am mining on a a merged pool that sometimes uses submitold, but have a backup pool that doesn't. Both use merged mining, and I am using --failover-only. So, I'm wondering, when a pool other than 0 sends an LP before pool 0, is pool 0's work discarded even though it might still be good? It seems to me like it would be, and then for the time between the LP on the backup pool and the LP on the primary pool, work wouldn't be done. This may not be true, because it may immediately request new work that may then also be discarded when my pool does LP (I have seen this take 20 seconds with no share submitted, but sometimes it takes significantly longer than that to find a share at ~318 MH/s). That having been said, I am asking because my U is at 4.35 (which rounds to 4.4 in the main stats, over only 6125 shares) where it was at 4.41 before (over tens of thousands of shares over weeks of work). Obviously we are only talking about a difference of .06 in my U, which may be statistically insignificant, but it is still potentially 1.5% less shares being submitted over >12 hours.

That difference is surely enough to be accounted by in variance which in U is usually +/-10%, but the full discussion of its effects is here:
https://bitcointalksearch.org/topic/m.873742
Theoretically you might be losing a *tiny* bit of work across longpolls with --failover-only but in my experience it is less than 2 seconds' worth of work every 10 minutes.

cmdr001

newbie

Activity: 20

Merit: 0

I have come up with an issue on CG Miner which I'm not being quite able to sort through, so if any help would be possible.
I tried searching on the thread, and while some mentions to adjusting engine clock were around it didn't quite fit my situation.

For a while now I had been using CG Miner 2.3.1 without any issues, but last night came up a problem where I couldn't seem to be able to adjust the clock speed below a certain value on neither of both cards (2x 6870). Wondering if it could be some odd bug I had struck on, I checked the thread, updated CG Miner, took the chance to update the video drivers, and on a new attempt I'm now able to adjust the speed of one of the cards to about any value, but not the other one.

I saw a mention that this could be driver related, but these cards are twins, worked always well before, but suddenly this came up even before I updated the drivers.

Any help?

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

Do you guys argue like this only to keep CGMiner as the top thread posting? You guys sound like either side of a Miller Lite commercial; crowd A: Great Taste! Crowd B: Less Filling!, then begin to look like a fight is about to occur over different perspectives for the same beer. Roll Eyes

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Luke-Jr on April 30, 2012, 08:18:09 AM

Quote from: kano on April 30, 2012, 07:49:46 AM

... and if anyone didn't realise:
If you use the api command "devdetails" it will tell you which "Kernel" it is using and the "Model" for each gpu

You forget to mention that I wrote this, both the back-end code shared by CGMiner and BFGMiner, and the original implementation of "devdetail" which you rejected so you could rewrite it less efficiently...

Firstly, why do I need to mention what small parts of api.c you wrote?
(Especially after you did the back-end refactor of cgminer but didn't bother to fix the problems that caused in api.c - and you still have one I can see - line 917, see below)

Secondly:

22:55 < luke-jr> kanoi: in other words, you want to be able to pull api.c out and put it with any other cgminer version?
22:56 < kanoi> sort of - but the reverse of that - I want cgmine version changes to mininise any affect onthe api
22:56 < kanoi> (the reports)
22:57 < kanoi> also fo ryour new info - that should be it's own 'report'
22:57 < kanoi> since it never changes, resending it every time is a waste
22:57 < kanoi> like the 'notify' - not always needed (but notify does change)
22:58 < kanoi> but in the case of the extra info - not needed more than once (unless the target forgets it)
22:58 < luke-jr> I suppose.
22:58 < kanoi> so that would be a new devs style command that just returns that extra new info
22:59 < luke-jr> what do you propose?
22:59 < luke-jr> "devdetail" ?
23:00 < kanoi> probably - sounds OK I guess

Hmm - so (as can be seen above) I told you to move the extra info to it's own command rather than have it the way that you designed to send that extra static never changing info EVERY time you request 'devs', 'gpu|N' or 'pga|N' - and that was less efficient?
Which - you did make that change as I said to.

The main differences I can see in the code is that you moved the GPU specific information OUT of api.c and instead call append_kv over and over again to append that data on the end instead of where it was before (miner.php looks crap in your version now) and instead of using a single (faster) print command
Also, the devdetails command removes fields that are blank so the external code processing the API output has to check for missing fields
You should correct line 917 the way I said it should be (and is in my version)
Hmm - and you send your "get_extra_device_detail(cgpu)" both with the 'devs' command and the 'devdetail' command - i.e. duplicating it.

The git "blame" page for api.c ... well anyway

Please stop trying to make it seem like there is some advantage to your clone (with not many changes) in this thread - especially when you've given an example that's not even true.
Go praise your miner in your own thread where your acolytes are less discerning than the folk here

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