Bitcoin Forum
December 06, 2016, 02:19:05 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 [145] 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4819616 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.
jjiimm_64
Legendary
*
Offline Offline

Activity: 1680


View Profile
January 14, 2012, 08:25:41 AM
 #2881


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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Fiyasko
Legendary
*
Offline Offline

Activity: 1428


Okey Dokey Lokey


View Profile
January 14, 2012, 09:02:33 AM
 #2882


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

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
P4man
Hero Member
*****
Offline Offline

Activity: 504



View Profile
January 14, 2012, 10:18:32 AM
 #2883

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"

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 14, 2012, 03:34:42 PM
 #2884

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.

wndrbr3d
Sr. Member
****
Offline Offline

Activity: 295


View Profile
January 14, 2012, 03:43:25 PM
 #2885

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 Tongue

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! Smiley
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 14, 2012, 04:15:48 PM
 #2886

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
Newbie
*
Offline Offline

Activity: 17


View Profile
January 14, 2012, 04:42:00 PM
 #2887

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

Activity: 1680


View Profile
January 14, 2012, 05:17:44 PM
 #2888

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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Fiyasko
Legendary
*
Offline Offline

Activity: 1428


Okey Dokey Lokey


View Profile
January 14, 2012, 07:30:48 PM
 #2889

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

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
jjiimm_64
Legendary
*
Offline Offline

Activity: 1680


View Profile
January 14, 2012, 07:48:27 PM
 #2890


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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Fiyasko
Legendary
*
Offline Offline

Activity: 1428


Okey Dokey Lokey


View Profile
January 14, 2012, 08:36:40 PM
 #2891


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

(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

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
January 14, 2012, 09:32:40 PM
 #2892

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 Smiley
(and explain it a bit more as stated this time)
Though, apparently almost no one reads the FAQ in the README file Cheesy

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
January 14, 2012, 10:47:21 PM
 #2893

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 Smiley
(and explain it a bit more as stated this time)
Though, apparently almost no one reads the FAQ in the README file Cheesy
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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jjiimm_64
Legendary
*
Offline Offline

Activity: 1680


View Profile
January 14, 2012, 11:29:44 PM
 #2894



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 Smiley
quote myself...
Quote
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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
BFL
Full Member
***
Offline Offline

Activity: 217



View Profile WWW
January 15, 2012, 12:05:09 AM
 #2895

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



Butterfly Labs  -  www.butterflylabs.com  -  Bitcoin Mining Hardware
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
January 15, 2012, 12:39:44 AM
 #2896

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?

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
jake262144
Full Member
***
Offline Offline

Activity: 210


View Profile
January 15, 2012, 01:09:43 AM
 #2897

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
January 15, 2012, 02:03:34 AM
 #2898

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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784


firstbits:1MinerQ


View Profile WWW
January 15, 2012, 02:24:09 AM
 #2899

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

Activity: 504



View Profile
January 15, 2012, 09:19:35 AM
 #2900

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.

Pages: « 1 ... 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 [145] 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 ... 830 »
  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!