Author

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

full member
Activity: 182
Merit: 100
Aren't most of what people are arguing about code-wise GPL or similar open licenses? If so, copying is a non-issue and is to be applauded. It benefits the greater good.
full member
Activity: 168
Merit: 100
Neither of these two examples have the same, copied solution. They were both solved independently in similar ways as they are both soving the same problem. It's no suprise the timing is also similar as these issue are being found at the same time.
I don't know why you're defending his obvious theft. They do have the same copied solution, even if Kano made a poor effort to obfuscate it; while the first one might have only had one or two ways it could be fixed, this last one has numerous possible solutions (the most obvious being significantly better than the one I ended up taking except for making merging from cgminer harder if cgminer hadn't adopted it too); yet in both cases Kano used the exact same solution - only trivial/non-substantial changes to the syntax/names were made.

Neither of these bugs were in fact found in cgminer: the curlring issue was one I experienced myself personally, spent hours debugging, and finally identified a solution for; the only way Kano would have even known it existed was by reading BFGMiner's commit log; the JSON escaping issue only really affect BFGMiner because its compiled-in prefix on Windows uses backslashes.

you have been told to get the fuck out of this thread several times. i'm no mod here but i have something to complain about... most of BigFuckingCunt miner is based on conmans work...
legendary
Activity: 1795
Merit: 1208
This is not OK.
Neither of these bugs were in fact found in cgminer: the curlring issue was one I experienced myself personally, spent hours debugging, and finally identified a solution for; the only way Kano would have even known it existed was by reading BFGMiner's commit log; the JSON escaping issue only really affect BFGMiner because its compiled-in prefix on Windows uses backslashes.

Maybe Kano is just better than you then?

There were a number of bug reports posted here in this thread pointing to libcurl being the source of locking up. Shortly after that, the fix was made. It's not a giant leap to assume that, in fact, they solved the problem.
legendary
Activity: 2576
Merit: 1186
Neither of these two examples have the same, copied solution. They were both solved independently in similar ways as they are both soving the same problem. It's no suprise the timing is also similar as these issue are being found at the same time.
I don't know why you're defending his obvious theft. They do have the same copied solution, even if Kano made a poor effort to obfuscate it; while the first one might have only had one or two ways it could be fixed, this last one has numerous possible solutions (the most obvious being significantly better than the one I ended up taking except for making merging from cgminer harder if cgminer hadn't adopted it too); yet in both cases Kano used the exact same solution - only trivial/non-substantial changes to the syntax/names were made.

Neither of these bugs were in fact found in cgminer: the curlring issue was one I experienced myself personally, spent hours debugging, and finally identified a solution for; the only way Kano would have even known it existed was by reading BFGMiner's commit log; the JSON escaping issue only really affect BFGMiner because its compiled-in prefix on Windows uses backslashes.
legendary
Activity: 1795
Merit: 1208
This is not OK.
Get over it Luke.

Simple problems are going be solved in the same simple way. There's nothing novel or unique about the code you write. It's all straight forward and intuitive.

Neither of these two examples have the same, copied solution. They were both solved independently in similar ways as they are both soving the same problem. It's no suprise the timing is also similar as these issue are being found at the same time.

You are not a coding god. Anyone can come up with the same ideas as you.
legendary
Activity: 2576
Merit: 1186
The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.
Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:
Code:
commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken
lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)
Is this the first time you expressed your absolute ignorance of how git works in public?
...
Hmm, when was the last one ... oh yeah I remember ... about 2 weeks ago ...
"I'm not a git export" ... Cheesy
https://bitcointalksearch.org/topic/m.1055547
That was sarcasm, since you very well knew you were stealing credit for this fix. Or are you going to claim it's just coincidence that you found it and fixed it a few days after BFGMiner, and did so in practically the same way? Just like you "found and fixed" the JSON string encode error that you just submitted a fix to CGMiner for under your own name only hours after I wrote a nearly identical fix for BFGMiner and mentioned it on the forum?
sr. member
Activity: 477
Merit: 500
Hi!

Testing version 2.6.4 on Ubuntu 12.04, found a (minor) bug, but I think it could be an older one. Yesterday I configured my system to use the onboard GPU (3300) for display and the PCIe card (5770) for mining only. Unfortunately, ADL and CL GPU mapping does not seem to work.

Even when using gpu-map, I cannot see the GPU temp, fan speed etccorrectly. Cgminer gets the values from onboard card and displays them for PCIe card. If I configure gpu-map, the initial *setting* of GPUfreq, voltage etc seems to work,but I still cannot see the measurements. And of course, auto adjustments does not work.
Debug log shows that cgminer sets (or tries to set) the initial values for *both* cards.

Here are my configurations and log files:
cgminer.conf (partially):
-------------
"device" : "0",
"gpu-memclock" : "450",
"gpu-engine" : "600-900",
"gpu-vddc" : "1.025",
"gpu-fan" : "80",
"gpu-dyninterval" : "21",
"failover-only" : true,
"intensity" : "12",
"gpu-map" : "0:1"
-------------

Corresponding debug log:
--------------------------
[2012-08-09 11:49:09] Started cgminer 2.6.4
 [2012-08-09 11:49:09] Loaded configuration file /home/xxxx/.cgminer/cgminer.conf
 [2012-08-09 11:49:09] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2012-08-09 11:49:09] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2012-08-09 11:49:09] CL Platform 0 version: OpenCL 1.2 AMD-APP (937.2)
 [2012-08-09 11:49:09] Platform 0 devices: 1
 [2012-08-09 11:49:09]    0   Juniper
 [2012-08-09 11:49:09] GPU 0 iAdapterIndex 0 strUDID 296:38420:4098:33613:4163 iBusNumber 1 iDeviceNumber 5 iFunctionNumber 0 iVendorID 40
98 strAdapterName  ATI Radeon HD 3300 Graphics
 [2012-08-09 11:49:09] GPU 1 iAdapterIndex 2 strUDID 512:26808:4098:9539:4098 iBusNumber 2 iDeviceNumber 0 iFunctionNumber 0 iVendorID 409
8 strAdapterName  ATI Radeon HD 5700 Series
 [2012-08-09 11:49:09] ADL found more devices than opencl!
 [2012-08-09 11:49:09] There is possibly at least one GPU that doesn't support OpenCL
 [2012-08-09 11:49:09] Use the gpu map feature to reliably map OpenCL to ADL
 [2012-08-09 11:49:09] Mapping OpenCL device 0 to ADL device 1
 [2012-08-09 11:49:09] WARNING: Number of OpenCL and ADL devices did not match!
 [2012-08-09 11:49:09] Hardware monitoring may NOT match up with devices!
 [2012-08-09 11:49:09] GPU 0 ATI Radeon HD 3300 Graphics hardware monitoring enabled
 [2012-08-09 11:49:09] Failed to ADL_Overdrive5_ODPerformanceLevels_Get
 [2012-08-09 11:49:09] Setting GPU 0 engine clock to 900
 [2012-08-09 11:49:09] Setting GPU 0 memory clock to 450
 [2012-08-09 11:49:09] Setting GPU 0 voltage to 1.025
 [2012-08-09 11:49:09] Failed to ADL_Overdrive5_FanSpeedInfo_Get
 [2012-08-09 11:49:09] GPU 0 doesn't support rpm or percent write
 [2012-08-09 11:49:09] GPU 1 ATI Radeon HD 5700 Series hardware monitoring enabled
 [2012-08-09 11:49:09] Setting GPU 1 engine clock to 900
 [2012-08-09 11:49:09] Setting GPU 1 memory clock to 450
 [2012-08-09 11:49:09] Setting GPU 1 voltage to 1.025
------------------------
:::These values are from the on-board card (temp,voltage and rpm not valid), should be PCIe GPU:
 [2012-08-09 11:49:54] [thread 0: 805306368 hashes, 92701.7 khash/sec]
 [2012-08-09 11:49:54] -1.0 C  F: -1%(-1RPM)  E: 497MHz  M: 667Mhz  V: 0.000V  A: 7%  P: 0%
 [2012-08-09 11:49:55] [thread 1: 536870912 hashes, 92702.8 khash/sec]
 [2012-08-09 11:49:55] (5s):203.9 (avg):197.0 Mh/s | Q:3  A:0  R:0  HW:0  E:0%  U:0.0/m
 [2012-08-09 11:49:57] -1.0 C  F: -1%(-1RPM)  E: 497MHz  M: 667Mhz  V: 0.000V  A: 7%  P: 0%
 [2012-08-09 11:50:00] [thread 0: 536870912 hashes, 92704.3 khash/sec]
 [2012-08-09 11:50:00] -1.0 C  F: -1%(-1RPM)  E: 497MHz  M: 667Mhz  V: 0.000V  A: 7%  P: 0%
 [2012-08-09 11:50:01] [thread 1: 536870912 hashes, 92708.9 khash/sec]
 [2012-08-09 11:50:01] (5s):197.1 (avg):195.7 Mh/s | Q:3  A:0  R:0  HW:0  E:0%  U:0.0/m
 [2012-08-09 11:50:03] -1.0 C  F: -1%(-1RPM)  E: 497MHz  M: 667Mhz  V: 0.000V  A: 7%  P: 0%
 [2012-08-09 11:50:06] [thread 0: 536870912 hashes, 92693.9 khash/sec]
 [2012-08-09 11:50:06] -1.0 C  F: -1%(-1RPM)  E: 497MHz  M: 667Mhz  V: 0.000V  A: 7%  P: 0%
 [2012-08-09 11:50:07] [thread 1: 536870912 hashes, 92697.1 khash/sec]
 [2012-08-09 11:50:07] (5s):192.8 (avg):194.7 Mh/s | Q:3  A:0  R:0  HW:0  E:0%  U:0.0/m

Otherwise 2.6.4 seems to work ok. One note thought; I think fan speed setting should have a tolerance for 'target' value also. Optimally, the algorihtm should find a stable speed for the fan RPM and keep it. Currently the temperature and fan speed varies during normal operation (auto-adjustments worked before I started to use onboard card also). Ie. It would be better to have 77 degrees and 61% speed all the time vs temp varying 74-76 and RPM varying 58-62.

If someone is interested, I can make a more detailed instructions on how to configure the system to use onboard card for display and PCIe GPU for mining.

Edit: Versions:
-Ubuntu 12.04
-Some 4 core AMD64 cpu
- Catalyst 12.6 Legacy (not the beta version, which did not support 3300..)
- AMD SDK 2.7
- cgminer 2.6.4

I do not seem to get all the power from 5770, but have not yet been able to optimize it. Actually, even window manager seems to affect the speed, ie Unity vs LXDE.
hero member
Activity: 826
Merit: 500
if someone hasn't announced this cgminer 2.6.4 works great with windows 8 pro RTM build 9200 x64.

I'm testing right now to see if its stable long term.

I'm using driver version drivers 9.00-120612a unofficial beta.

Getting around 7% better Mh/s than win 7 using same configs on a 5770 card.

Anyone working in IT that hasn't used WIN 8 its going to be a nightmare doing end user training.

I'm getting slightly less on my 7970s on win 8.

The UI on win 8 is AWFUL.  I can't believe I had to google how to shut it down because I couldn't find the power button... 

M

I know the UI is designed for tablets and seems out of place on a desktop.

I had the same problem, I was like WTF how do I restart this stupid thing. They are making it so the default is to sleep the machine and not turn it off.

legendary
Activity: 1540
Merit: 1001
if someone hasn't announced this cgminer 2.6.4 works great with windows 8 pro RTM build 9200 x64.

I'm testing right now to see if its stable long term.

I'm using driver version drivers 9.00-120612a unofficial beta.

Getting around 7% better Mh/s than win 7 using same configs on a 5770 card.

Anyone working in IT that hasn't used WIN 8 its going to be a nightmare doing end user training.

I'm getting slightly less on my 7970s on win 8.

The UI on win 8 is AWFUL.  I can't believe I had to google how to shut it down because I couldn't find the power button... 

M
hero member
Activity: 826
Merit: 500
if someone hasn't announced this cgminer 2.6.4 works great with windows 8 pro RTM build 9200 x64.

I'm testing right now to see if its stable long term.

I'm using driver version drivers 9.00-120612a unofficial beta.

Getting around 7% better Mh/s than win 7 using same configs on a 5770 card.

Anyone working in IT that hasn't used WIN 8 its going to be a nightmare doing end user training.

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I compiled 2.6.4 for windows and I've had it running for over 24 hours so far without any problems.
At last  Cheesy
Thanks  Smiley
sr. member
Activity: 344
Merit: 250
I compiled 2.6.4 for windows and I've had it running for over 24 hours so far without any problems.

Code:
 cgminer version 2.6.4 - Started: [2012-08-08 12:21:53]
--------------------------------------------------------------------------------
 (5s):1629.0 (avg):1613.4 Mh/s | Q:4759  A:33041  R:567  HW:0  E:694%  U:22.2/m
 TQ: 0  ST: 4  SS: 0  DW: 1333  NB: 174  LW: 35434  GF: 46  RF: 0
 Connected to http://us2.eclipsemc.com:8337 with LP as user ---
 Block: 000006fde06dc9cde7ab56000892379d...  Started: [13:01:47]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BFL 0:  55.9C         | 811.0/806.7Mh/s | A:16567 R:283 HW:0 U:11.12/m
 BFL 1:  57.4C         | 811.0/806.7Mh/s | A:16476 R:284 HW:0 U:11.06/m
--------------------------------------------------------------------------------
legendary
Activity: 1795
Merit: 1208
This is not OK.
If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.
You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer Tongue

15.3355, in fact Smiley
Yeah that seems to suggest it also.
But was there a 'BUSY' reply as BFL-Engineer said there is?

I don't recall every seeing a 'busy', but then I've not looked for it.
I'll have another poke around...
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.
You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer Tongue
Sorry yes, https://bitcointalksearch.org/topic/m.1018768
Not returning "BUSY" as specified is lame.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.
You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer Tongue

15.3355, in fact Smiley
Yeah that seems to suggest it also.
But was there a 'BUSY' reply as BFL-Engineer said there is?
legendary
Activity: 1795
Merit: 1208
This is not OK.
If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.
You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer Tongue

15.3355, in fact Smiley
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.
You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer Tongue
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Also, I started adding the temp to the log when a unit throttles...
I'm thinking about adding code with slows the unit a bit as it reaches it's individual throttle temp. Like waiting 500ms before sending new work or something. Maybe. Dunno.
When my 2nd FPGA "died" in my BFL I did exactly this.
The result was useless in my case.
Adjusting it up and down (I used a getenv() to set it) appeared to make no difference at all.
(I set it to delay getenv() ms before sending new work - I tried from 100 up to about 1000)
I got the impression that the idle time was doing more bad than good

Though the death was probably something else in it crapping out since:
In my case the final fix was stupid anyway Smiley
I installed the 880 bitstream ... and it's been fine ... 2 weeks and counting ...

tl;dr story follows Smiley
I got it 4-May, but working OK from 5-May then got problems 11-Jul ... as the weather got colder ... it started to throttle and fail Tongue
(It's now the coldest part of winter here)
Then it would only mine on one FPGA.
I'd never touched the firmware coz that meant moving the stupid thing to my kids windows computer and plugging it in there to use the POS EasyMiner program.
So I did this (moved it upstairs to me instead of down in my cold basement garage) and EasyMiner said it was no good (running a test) ... but cgminer would still mine on one FPGA.

I did find a few times that if I pulled the power on it completely it would start up mining normally at 825MH/s for a while and in one case this lasted 2 days (21-Jul to 23-Jul)
After being annoyed at it for 2 weeks (code changes, power cycles etc) I decided to try kill it by putting in the 880 bitstream (26-Jul)
(sending from Aus->USA is not a cheap thing to do, so while it still partially worked I didn't want to do that)
With the 880 bitstream it's been fine ever since, upstairs here next to me, under a chair, reporting 10C higher Tongue
(air coming out is only slightly warm, not hot)
My BFL is the version with the new heatsink but only 1 fan on top so not exceptionally loud

Yeah my opinion of the throttling hardware/design is ... not good Smiley
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
If I had the time/could be bothered I'd put timers around each of the send/receive and find the max/min/avg values. But that ain't gonna happen in the next week or so.

I've done that, get the following:

ID: BFL0   Dev Max: 0.024049   Dev Min: 0.000366   Dev Av: 0.009301
ID: BFL1   Dev Max: 15.335547   Dev Min: 0.000389   Dev Av: 0.012155
ID: BFL2   Dev Max: 15.335506   Dev Min: 3.8E-5   Dev Av: 0.011484
ID: BFL3   Dev Max: 15.33545   Dev Min: 0.00036   Dev Av: 0.027547
ID: BFL4   Dev Max: 0.02345   Dev Min: 0.00036   Dev Av: 0.009153
ID: BFL5   Dev Max: 0.023163   Dev Min: 0.000404   Dev Av: 0.008941

So I put get times immedately before and after the serial port read function inside BFgets.
Dev max is (surpisingly) the max time a read took
Dev min is (surpisingly) the min time a read took
Dev av is (surpisingly) the overall average, that is all the read times summed, then divided my the read count.

So it's pretty apparent that when the single throttles, comms just stop.
Ah well, then that just means BFL is full of shit as usual:
https://bitcointalksearch.org/topic/m.885143
During throttle, the device does respond to temperature read, status read, etc.
A new job, however, cannot be issued, as the unit will respond with 'BUSY'.

Good Luck,

Now to decide a workaround for more BFL design shit that doesn't involve simply saying "a BFL appearing dead for up to 30s is OK" ...

The MiniRig cards are ~twice this speed, and I have one person with 2xMR running 2.6.2 modified and he's had 29 comm errors out of 4,171,889 accepted shares - so no issue at all.

... sigh - I presume this crap is all due to the fscking stupid throttling design done by BFL where their hardware decides and controls the whole process rather than allowing the software to control it (or know about it)
Jump to: