OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[DeathAndTaxes]

Who wants to jump in, Thats fucked

I suspect you already gave the reason: "Loving this miner Because it compiled a SDK2.5 .bin, Making itself run off SDK 2.5 Whilst i have 2.6 installed"

This.

It is the craptastic beyond all belief SDK 2.6 (worst release by AMD yet).

DONT USE 2.6 DONT USE 2.6 DONT USE 2.6 DONT USE 2.6 DONT USE 2.6 (<- maybe that should be my signature)

You may say "why does the old cgminer not have an issue"?  cgminer "caches" kernel binary data as .bin files.  So since they were already created the old version won't create new ones and use the fucked to all hell SDK 2.6

An experiment.
1) Look in old cgminer dir. You should see some files with .bin extension.  Copy them somewhere safe.
2) Now delete the copy in old cgminer dir.  launch cgminer - likely you have the same poor performance.
3) Look in old cgminer dir.  You will notice it recreated the .bin files.  These are the crappy ones (built w/ sdk 2.6).  Delete them
4) Copy your safe copy (step #1) of the .bin files back to old cgminer.  launch it.  you should have good performance again
5) Now delete the .bin files in NEW VERSION of cgminer dir.  Copy the "old" .bin files from your safe directory (step #1).
6) Launch new cgminer.  You should have same performance as the old cgminer.

Please post your results as it will confirm P4man hypothesis.

[1714771578]

1714771578

[1714771578]

1714771578

[wndrbr3d]

I tried searching but my terms were a bit generic, so I thought I'd ask and face the wrath of the "zomg, search" guys

Is there a way to have cgminer restore the pre-execution engine/memory clock values upon exit? I use two of my mining rigs as gaming computers and I always have to go into afterburner after I quit cgminer to put my clocks back to default.

Any help is appreciated! Thanks!

[cablepair]

Who wants to jump in, Thats fucked

I suspect you already gave the reason: "Loving this miner Because it compiled a SDK2.5 .bin, Making itself run off SDK 2.5 Whilst i have 2.6 installed"

This.

It is the craptastic beyond all belief SDK 2.6 (worst release by AMD yet).

DONT USE 2.6 DONT USE 2.6 DONT USE 2.6 DONT USE 2.6 DONT USE 2.6 (<- maybe that should be my signature)

You may say "why does the old cgminer not have an issue"?  cgminer "caches" kernel binary data as .bin files.  So since they were already created the old version won't create new ones and use the fucked to all hell SDK 2.6

An experiment.
1) Look in old cgminer dir. You should see some files with .bin extension.  Copy them somewhere safe.
2) Now delete the copy in old cgminer dir.  launch cgminer - likely you have the same poor performance.
3) Look in old cgminer dir.  You will notice it recreated the .bin files.  These are the crappy ones (built w/ sdk 2.6).  Delete them
4) Copy your safe copy (step #1) of the .bin files back to old cgminer.  launch it.  you should have good performance again
5) Now delete the .bin files in NEW VERSION of cgminer dir.  Copy the "old" .bin files from your safe directory (step #1).
6) Launch new cgminer.  You should have same performance as the old cgminer.

Please post your results as it will confirm P4man hypothesis.

hes right. I posted awhile back that even if you uninstall and reinstall your drivers you still have to delete cgminer and unzip a fresh copy, I never took the time to figure out why  , but this is obviously the reason  thanks!

[swapper]

Hi.

I have a problem with cgminer when I try to fix gpu or memory frequency with cgminer and quit the program.

I have an ATI 6990 watercooled, without fan, with overclock switch activated, in Windows 7 enterprise X64 with Catalyst 11.12

If I fix the gpu frequency to 900 Mhz and memory frequency to 775 Mhz with MSI Afterburner and launch cgminer with: "cgminer.exe -o http://de.btcguild.com:8332 -u xxx -p xxx --donation 1.0 --temp-cutoff 85 --temp-overheat 80 --temp-target 60 -I 5" it works OK: http://img221.imageshack.us/img221/9568/91104914.png

But if I specify the frequencies in cgminer with: "cgminer.exe -o http://de.btcguild.com:8332 -u xxx -p xxx --donation 1.0 --temp-cutoff 85 --temp-overheat 80 --temp-target 60 -I 5 --gpu-engine 900 --gpu-memclock 775" : http://img715.imageshack.us/img715/158/bsodt.png, it works OK until I quit the program. When exiting, just after printing "Summary of per device statistics" line, it appears a BSOD: http://img16.imageshack.us/img16/9703/bsod1.png

Any idea?

Thanks.

I reply to myself:

I have returned the ATI 6990 switch to it's default position. I use MSI Afterburner to monitor the card, not to overclock it. Launched cgminer with: "cgminer.exe -o http://de.btcguild.com:8332 -u xxx -p xxx --donation 1.0 --temp-cutoff 80 --temp-overheat 70 --temp-target 60 -I 5 --auto-gpu --gpu-engine 830-920 --gpu-memclock 795 --gpu-memdiff -125 --gpu-powertune 20" and the BSOD after quitting cgminer is gone.

Now the problem is the GPU and memory clocks are not returned to it's original values after quitting cgminer. After quitting cgminer, If I execute FurMark the clocks return to the values specified when I executed cgminer (920/795), not the card's default (830/1250).

[jjiimm_64]

Please post your results as it will confirm P4man hypothesis.

DAT:  this is awsome.....
 all I have to do is copy the old bin to the new cgminer and launch.....  brb


edit:
  wow:  I can tell instantly that it is working as before.  2bits for DeathAndTaxes...  whats your addy

[Fiyasko]

Please post your results as it will confirm P4man hypothesis.

DAT:  this is awsome.....
 all I have to do is copy the old bin to the new cgminer and launch.....  brb


edit:
  wow:  I can tell instantly that it is working as before.  2bits for DeathAndTaxes...  whats your addy

(lol) Awww c'mon I gave the solution first(lol kinda) D&T just elaborated and made it a step by step guide (snickers) I want those coins! c'mon he's got 6gh/s i've got 1 xD

[jjiimm_64]

Lets get the obvious questions out of the way
Could your drivers have updated recently?
Your Obviously talking about the newer version of CGminer right? If not, SDK2.6 is your problem.

yes, i updated the ccc a month ago to get rid of the 100% bug.  i have 11-12_vista64_win7_64_dd_ccc_ocl.exe

if I run the older version of cgminer, i get the normal hashrates.  This did not affect the other 14 rigs running linuxcoin

Who wants to jump in, Thats fucked

then, after DAT 'jumped in'.

(lol) Awww c'mon I gave the solution first(lol kinda) D&T just elaborated and made it a step by step guide (snickers) I want those coins! c'mon he's got 6gh/s i've got 1 xD

JackRabbit:

1.    All you said was the SDK 2.6 is my problem. So was your solution to roll back my drivers, reintroducing the 100% cpu bug? not to mention that with the old drivers you need dummy plugs .  (btw i have about 10, anyone need one?)

2.  You mentioned nothing about switching bin files in the cgminer install. which by the way is an elegant and quick solution, took literally 1 minute

do you still think you deserve the coins with "If not, SDK2.6 is your problem." ?

[Fiyasko]

Lets get the obvious questions out of the way
Could your drivers have updated recently?
Your Obviously talking about the newer version of CGminer right? If not, SDK2.6 is your problem.

yes, i updated the ccc a month ago to get rid of the 100% bug.  i have 11-12_vista64_win7_64_dd_ccc_ocl.exe

if I run the older version of cgminer, i get the normal hashrates.  This did not affect the other 14 rigs running linuxcoin

Who wants to jump in, Thats fucked

then, after DAT 'jumped in'.

lol i dont deserve them atall, Im screwing around

(lol) Awww c'mon I gave the solution first(lol kinda) D&T just elaborated and made it a step by step guide (snickers) I want those coins! c'mon he's got 6gh/s i've got 1 xD

JackRabbit:

1.    All you said was the SDK 2.6 is my problem. So was your solution to roll back my drivers, reintroducing the 100% cpu bug? not to mention that with the old drivers you need dummy plugs .  (btw i have about 10, anyone need one?)

2.  You mentioned nothing about switching bin files in the cgminer install. which by the way is an elegant and quick solution, took literally 1 minute

do you still think you deserve the coins with "If not, SDK2.6 is your problem." ?

No, Ofcourse i do not deserve the coins, Send them to D&T I was messing around in a vain attempt to get a coin, But cleary the joke was not projected properly

[kano]

Actually this issue has been discussed quite a few times.
The last time recently was:
https://bitcointalk.org/index.php?topic=28402.msg671582#msg671582

I guess if ckolivas doesn't put it in, I'll add an FAQ about the bin files when I do my next changes - hopefully soon
(and explain it a bit more as stated this time)
Though, apparently almost no one reads the FAQ in the README file

[-ck]

Actually this issue has been discussed quite a few times.
The last time recently was:
https://bitcointalk.org/index.php?topic=28402.msg671582#msg671582

I guess if ckolivas doesn't put it in, I'll add an FAQ about the bin files when I do my next changes - hopefully soon
(and explain it a bit more as stated this time)
Though, apparently almost no one reads the FAQ in the README file

Yeah I even tried explaining but I didn't spell it out, so even if I put it into the readme, it would have been "too hard dunno wtf you're  talking about" or wouldn't have been read.

[jjiimm_64]

But yeah - state exactly what you want with those 2 commands and once the CPU changes happen I'll put those 2 on first priority (for 5 BTC

quote myself...

Kano,
  What I am looking for is basically exactly what you would do if you went thru the apps interface to:

1.  switch pool
   P ->  S -> pool number

2.  change engine clock
   G -> C -> GPU# -> E  -> newValue

3. change mem clock
   G -> C -> GPU# -> M  -> newValue


I guess just about any one of the gpu changes would be good, but the 3 above I think are critical.  Even if you can control the fan (I usually have on auto)  you can always lower the Eclock down to try and kool it..  or disable the card which you have already implimented.

I would like to revise the above list with this one.

1. ability to switch pools (i think setting a pools priority to 0 would work?)
2.  setting any of the following, for 1 or all gpus's:

• "intensity" : "newValue",
• "gpu-engine" : "newValue",
• "gpu-memclock" : "newValue",
• "gpu-fan":      "newValue",  ex(50-85)

I realize the 'all gpus' could get tricky, because most of these takes possible a comma delim list. and i have no idea how it is implimented  so just one at a time is good


also just wanted to bump this up again.  i know we are waiting to resolve the code/trunk issues.

here is a sample of the single php page summary of all cgminers in farm no database needed..
http://cgminerweb.com/example.miner.php.html  (html snapshot)

I ment to write new post but apparently edited the old one...  bump

[BFL]

Hi guys, please excuse the intrusion...

I know many of our customers use CGMiner and that there has been some work on your code base to support our units.  In furtherance of that effort, I thought you might like to have our protocol spec for communicating with BitForce devices.

Please let me know if you have any questions or if you need remote access to a unit for code testing.

Kind Regards,
BFL


BitForce communication protocol:

1) Detection
-----------------------------------
BitFORCE on linux will be recognized as a ttyUSB device in /dev/ folder (i.e. ttyUSB0 or ttyUSB1, etc).
In order to find our device, one must test all the ttyUSB devices found in /dev/ folder, open them
and send them the ID request command (string: 'ZAX'). After the command is sent, if a response is
received  (will resemble '>>>ID: BitFORCE SHA256 Version X.Y>>>'), then a BitFORCE device has been
detected. (X and Y represent a numerical version)

On windows, one must perform the same on all COM and VCOM devices (COM1, COM2, etc...).


2) Information
----------------------------------
Once a device is detected, an information request command 'ZGX' can be sent to the device.
BitFORCE will respond by sending detailed data regarding its firmware version, hash and so on.
Please note that no carriage-return must be appended to the end of any command identifiers.


2) Sending a job request
----------------------------------
To send a bitcoin job request, first the command ID must be sent (string: 'ZDX'). The device will respond
with an 'OK' (followed by a carriage return). At this point, device is ready to accept a Bitcoin job.  (Note: If 'BUSY' was returned, it means either the device is not intialized yet, or is processing another job)

Next is to send a bitcoin job. A job-packet must have the following format:

   1) Starts with '>>>>>>>>'
   2) Following is 256bits of MIDSTATE
   3) Next is our last 12 bytes of block-header (Block header is 86 Bytes, the last 12 is needed here)
   4) Packet ends with '>>>>>>>>'

Please note that the byte-ordering is identical to what is received on JSON data. No conversion is therefore needed.

Once this is done, the device will send back an 'OK' (followed by carriage return). System starts
processing the bitcoin hash from this point.


3) Checking for results
-------------------------------
After the sent job, driver must keep asking the device for status (10ms is preferred polling interval).
Status command is 'ZFX'. Once sent, the unit may respond with one of the predefined responses:
  
    * BUSY
    (Device is busy processing a block. You can still issue a job, but the previous process will be
     discarded and new process will start)

    * IDLE
    (Device is not processing anything)

    * NONCE-FOUND:<8 Hexadecimal characters defining the found Nonce>, <8 Hexa decimal of the second found nonce>...
    Note: The last nonce will not be terminated by a comma. The byte-ordering is Little-Endian
    Example: NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB   (3 valid nonces are discovered in this process)

    * NO-NONCE
    Processing has been finished, no valid nonce was detected.
   
Note that all responses from BitFORCE units are followed by a carriage-return.

End...

[rjk]

After the sent job, driver must keep asking the device for status (10ms is preferred polling interval).

Is it not easily possible to modify the firmware to push a result back, instead of needing to be polled continuously?

[jake262144]

Is it not easily possible to modify the firmware to push a result back, instead of needing to be polled continuously?

THAT. Busy-waiting is a horribly inelegant approach.

[kano]

Is it not easily possible to modify the firmware to push a result back, instead of needing to be polled continuously?

THAT. Busy-waiting is a horribly inelegant approach.

Hmm I wonder how that response protocol compares to the ATI card procedure.
(I have no idea and have never delved closely into that part of the code)
But it does seem rather surprising for the design to have a possibility that the device can be idle for an entire busy-wait period ...
So on average it will be idle for half the busy-wait period per work request.

[BkkCoins]

If the FPGA has a micro controller attached then the smart way to do this would be to have a job queued ready for it to start new work as soon as finished. The micro controller should store the next job. Then the polling could be much reduced.

Also, as far as I know the USB interface will buffer data so the miner could just send finished work data and the PC just has to check it's buffer for finished work, and issue a new job. Or the PC could be set to interrupt on USB data ready.

A 10mS polling time isn't terrible but the more units hanging off USB cables the more work required to poll many of them. I don't know where the limit is but it's a lot of work for nothing. If a poll takes 1mS then you'd be limited to 10 units. I suspect it may be faster but maybe not, given it has to go thru all the USB protocol stuff, talk to the FPGA and get back a result. With so much wonderful tech in play it seems like a butchers approach to queuing work.

[P4man]

ms? No way. To give you an idea, USB2.0 has a latency of ~100 picoseconds nanoseconds.
That is 0.000 000 1 seconds or 0.0001 ms.
If the latency is anywhere within a few orders of magnitude of a full ms, than it has nothing to do with USB.

Not saying its an elegant solution, but its not likely to cause any trouble either IMO.

[-ck]

Nonetheless, most interfaces that need polling lead to significant busy-waiting loops in the code to make sure they don't miss an opportunity to give out more work. This is *exactly* the sort of shit that led to high CPU usage in many iterations of the ATI driver. Now I haven't looked at that part of Luke-jr's code to see how he manages it, but you can minimise the effect somewhat by not simply polling indefinitely, and he has said he went to some effort to work around it. Even well coded around, it's still an inefficient means of communicating and I'm disappointed to see it in a new device in this day and age.

[jake262144]

... Even well coded around, it's still an inefficient means of communicating and I'm disappointed to see it in a new device in this day and age.

Well said, con.

*chanting* BFL toaster, BFL toaster, BFL toaster...
 

[kano]

I will also add that the detection explanation seems extremely strange.
Whenever you plug a USB device into a linux system you see messages in dmesg about the identity of the device.
That information (however you get access to it) should be enough to know what it is shouldn't it?
Or are they not handling the USB connection with identity information like every other USB device on the planet I've plugged into a linux box?