Bitcoin Forum
December 05, 2016, 02:36:07 AM *
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 ... 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 [248] 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4817753 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.
Chefnet
Hero Member
*****
Offline Offline

Activity: 686


View Profile
April 19, 2012, 12:07:18 AM
 #4941

that will be fine, and do you want to insert the quad support too?

"Are you talkin' to me?"

Yes, I've already asked for details on what changes in the API, and will have a look at BTCMiner sources as soon as I can get my hands on them. While I don't plan to own these quads soon, I do want cgminer to have the best possible ztex hardware support.

but it will be fine if it could be because of using cgminer with dd-wrt. Thank you for your work.

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

Posts: 1480905367

View Profile Personal Message (Offline)

Ignore
1480905367
Reply with quote  #2

1480905367
Report to moderator
1480905367
Hero Member
*
Offline Offline

Posts: 1480905367

View Profile Personal Message (Offline)

Ignore
1480905367
Reply with quote  #2

1480905367
Report to moderator
1480905367
Hero Member
*
Offline Offline

Posts: 1480905367

View Profile Personal Message (Offline)

Ignore
1480905367
Reply with quote  #2

1480905367
Report to moderator
bitlane
Internet detective
Sr. Member
****
Offline Offline

Activity: 462


I heart thebaron


View Profile
April 19, 2012, 12:42:04 PM
 #4942

...Though I did still offer to debug and write the fix for Gigavps, at a reasonable per-hour cost; I can't blame him for declining, considering it wouldn't get merged

OH GOD.

I can honestly say that I feel comfortable enough to speak for a good chunk of the community when I say that I am certain that many users would feel alot better if you had NOTHING to do with CGMiner, it's upkeep or it's forward/further development.

Con and Kano are doing an awesome job and every time you post, I can't help but feel you are doing nothing but trying to push them around and bend to YOUR will.....

Adding your name to the program's credits would serve as nothing more than to add a stain on the integrity and future public opinion of CGMiner in general.

Please stay away. For this, I can honestly say that I will pray to help ensure it.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
April 19, 2012, 12:55:44 PM
 #4943

OH GOD.

I can honestly say that I feel comfortable enough to speak for a good chunk of the community when I say that I am certain that many users would feel alot better if you had NOTHING to do with CGMiner, it's upkeep or it's forward/further development.

You don't speak for me, and I am not sure you even speak for a good chunk.

Here you go "detective":
http://rusty.ozlabs.org/?p=196

I want the best possible code, putting a purity test of code (which is pure logic) is just asinine.  Luke has found bugs (and fixes) in cgminer and bitcoind.  Would the community be better served by running buggier software because you dislike him.  As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.

Either the code changes have value or they doesn't.  THAT (and only that) should be the metric.

To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority.  The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward.  Nobody will ever agree on perfect interface.  There is no such thing.  The API allows multiple front ends to be developed independently of cgminer.

It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc

cgminer just needs enough of a native interface to allow low level troubleshooting.   So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).
greatwolf
Full Member
***
Offline Offline

Activity: 231


View Profile
April 19, 2012, 02:24:34 PM
 #4944

I just downloaded cgminer 2.3.3 and I thought I'd give it a try. My initial impressions of it is that it's rather buggy and general usage is complicated by the long list of options displayed from cgminer --help.

Using this system setup:
  Win7
  Intel Q6600 Quad Core
  Nvidia GTS250 w/ Driver 285.62
  Latest cgminer win32-binary available: version 2.3.3 at time of this posting

Here are the list of problems I'm running into:

Code:
cgminer --benchmark

Causes my video driver to crash and restart. I also get the following cgminer output from the console window:

Code:
cgminer version 2.3.3 - Started: [2012-04-19 06:56:33]
--------------------------------------------------------------------------------
 (5s):0.2 (avg):64.5 Mh/s | Q:0  A:0  R:0  HW:0  E:0%  U:0.00/m
 TQ: 2  ST: 0  SS: 0  DW: 0  NB: 0  LW: 0  GF: 0  RF: 0
 Connected to Benchmark without LP as user Benchmark
 Block: (null)...  Started:
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: 169.3/ 64.5Mh/s | A:0 R:0 HW:0 U:0.00/m I:14
--------------------------------------------------------------------------------

[2012-04-19 06:56:33] Started cgminer 2.3.3
[2012-04-19 06:56:35] Disabling extra threads due to dynamic mode.
[2012-04-19 06:56:35] Tune dynamic intensity with --gpu-dyninterval
[2012-04-19 06:56:41] Thread 1 being disabled
[2012-04-19 06:56:56] Error: clEnqueueReadBuffer failed. (clEnqueueReadBuffer)
[2012-04-19 06:56:56] Thread 0 failure, exiting

When this happens, memory usage spikes up to 1.951+ gb and it stays there, like a memory leak has just occurred. Here's a screenshot of it:



I get the same results for all 4 kernels:

Code:
-k diablo
-k diakgcn
-k poclbm
-k phatk

In the case of using cgminer -k poclbm, I can't even get cgminer to quit by pressing 'q' or Ctrl-C. The only way to terminal the process was to kill it from task manager using 'end process'; yuck!

Here's an example output when I try to connect and test mine on a pool. The follow command was used:

Code:
C:\cgminer-2.3.3-win32> cgminer -o http://us.eclipsemc.com:8337 -u username -p password

produces the follow output:

Code:
cgminer version 2.3.3 - Started: [2012-04-19 07:18:53]
--------------------------------------------------------------------------------
 (5s):5.4 (avg):12.3 Mh/s | Q:103  A:0  R:0  HW:0  E:0%  U:0.00/m
 TQ: 2  ST: 0  SS: 0  DW: 0  NB: 1  LW: 1562  GF: 133  RF: 0
 Connected to http://us.eclipsemc.com:8337 with LP as user username
 Block: 000006f95499ba1ca3844065a373e62a...  Started: [07:18:53]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:   0.0/ 12.3Mh/s | A:0 R:0 HW:0 U:0.00/m I:14
--------------------------------------------------------------------------------

[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:11] Pool 0 not providing work fast enough
[2012-04-19 07:19:11] Pool 0 not providing work fast enough

Other miners I've used like phoenix and ufa-soft miner do not exhibit such problems and they work as expected. On the other hand, I can't even get a proper benchmark read out from cgminer. A search on this thread shows someone else with nvidia hardware encountering similar problems and difficulty though they were using an earlier version 2.2.3. Apparently the latest cgminer build hasn't address these problems yet.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
April 19, 2012, 02:34:13 PM
 #4945

...

Luke-jr's name is in the code and the AUTHORS file - he added his name after I did, but 'above' mine coz I guess he felt he was more important Tongue

I've left it in that order but in the hope that one day I could make this comment ... which I just did Cheesy

Anyway, on the subject of accepting code - yep even Luke-jr's code gets accepted.
However, like my code, it gets vetted by ckolivas before it goes in.

The problematic things he seems to like to do are related to changing the way things look because he wants it to look different - and they have been rejected in the past.
Otherwise, I think most of his code changes have gone in.

Anyone who uses a BFL (or even an Icarus) is using the code that Luke-jr wrote.
Icarus code was based on the BFL code, a lot was rewritten due to the different way they work and then other changes have happened to the Icarus code since then (hmm I should add my latest LP Icarus change to the BFL code whenever I get around to sending a pull 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
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
April 19, 2012, 02:39:18 PM
 #4946

The problematic things he seems to like to do are related to changing the way things look because he wants it to look different - and they have been rejected in the past.
Otherwise, I think most of his code changes have gone in.
No, generally I haven't touched (nor have any particular interest in touching) display/output. The only times I've affected it were accidental/secondary from the real code change; the first, refactoring the code to support different drivers (this initially moved the driver-specific information - temperature and fan speed for GPUs - to the end of the device info line), and the second, fixing a bug I introduced with that first change when I used "BFL" to represent "FPGA" in the internal driver API (this was fixed by correcting it to "PGA" which kanoi suggested).

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
April 19, 2012, 02:47:11 PM
 #4947

I want the best possible code, putting a purity test of code (which is pure logic) is just asinine.  Luke has found bugs (and fixes) in cgminer and bitcoind.  Would the community be better served by running buggier software because you dislike him.  As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.

Either the code changes have value or they doesn't.  THAT (and only that) should be the metric.

To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority.  The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward.  Nobody will ever agree on perfect interface.  There is no such thing.  The API allows multiple front ends to be developed independently of cgminer.

It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc

cgminer just needs enough of a native interface to allow low level troubleshooting.   So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).

+1 for maintaining sanity. Also agree with keeping UI development on cgminer minimal. There is great value and benefit keeping the UI decoupled from the 'work' code. It is a good design/implementation practice which manages complexity while adding flexibility. I once wondered why cgminer didn't have a Windows front-end, but it didn't take long to realize that the existing curses-based text UI is more than adequate.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
April 19, 2012, 03:22:54 PM
 #4948

Does cgminer config file have a "comment" symbol?

If not could it be added to next version?  #?

The simplest/easiest method would simply to only support leading charecter comment symbol. 
Code:
#This line is a comment
# "auto-gpu" : true
#The command above has been commented out.

"auto-gpu" : true  #This is invalid because the format only support leading char comment symbols

More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
jjiimm_64
Legendary
*
Offline Offline

Activity: 1680


View Profile
April 19, 2012, 04:54:16 PM
 #4949

Does cgminer config file have a "comment" symbol?

If not could it be added to next version?  #?

The simplest/easiest method would simply to only support leading charecter comment symbol. 
Code:
#This line is a comment
# "auto-gpu" : true
#The command above has been commented out.

"auto-gpu" : true  #This is invalid because the format only support leading char comment symbols

More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.


this works:
Code:
"__auto-gpu" : true

precede any attribute with underscores will prevent that attribute from loading.

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
jddebug
Sr. Member
****
Offline Offline

Activity: 420



View Profile
April 19, 2012, 05:01:26 PM
 #4950

I want the best possible code, putting a purity test of code (which is pure logic) is just asinine.  Luke has found bugs (and fixes) in cgminer and bitcoind.  Would the community be better served by running buggier software because you dislike him.  As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.

Either the code changes have value or they doesn't.  THAT (and only that) should be the metric.

To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority.  The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward.  Nobody will ever agree on perfect interface.  There is no such thing.  The API allows multiple front ends to be developed independently of cgminer.

It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc

cgminer just needs enough of a native interface to allow low level troubleshooting.   So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).

+1 for maintaining sanity. Also agree with keeping UI development on cgminer minimal. There is great value and benefit keeping the UI decoupled from the 'work' code. It is a good design/implementation practice which manages complexity while adding flexibility. I once wondered why cgminer didn't have a Windows front-end, but it didn't take long to realize that the existing curses-based text UI is more than adequate.

While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.

I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.

I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
April 19, 2012, 05:21:57 PM
 #4951

While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.

I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.

I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Valid concern, yes. I haven't tried this, but if you had 16 devices (as an example) could you run 2 instances of cgminer on the same machine, each servicing 8 devices?

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
jddebug
Sr. Member
****
Offline Offline

Activity: 420



View Profile
April 19, 2012, 05:41:08 PM
 #4952

While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.

I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.

I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Valid concern, yes. I haven't tried this, but if you had 16 devices (as an example) could you run 2 instances of cgminer on the same machine, each servicing 8 devices?

That is kind of what i am thinking. Not nearly as slick but doable. I'll be testing that later today.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
April 19, 2012, 06:14:48 PM
 #4953

Does cgminer config file have a "comment" symbol?

If not could it be added to next version?  #?

The simplest/easiest method would simply to only support leading charecter comment symbol. 
Code:
#This line is a comment
# "auto-gpu" : true
#The command above has been commented out.

"auto-gpu" : true  #This is invalid because the format only support leading char comment symbols

More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.


this works:
Code:
"__auto-gpu" : true

precede any attribute with underscores will prevent that attribute from loading.
It's the issue of using a 'standard' that doesn't have what you want ...
Thus the answer to the first question is no.
Of course jjiimm_64's solution works to comment out an option.
Just be sure to never save the config ...

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
April 19, 2012, 06:22:51 PM
 #4954

While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.

I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.

I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Valid concern, yes. I haven't tried this, but if you had 16 devices (as an example) could you run 2 instances of cgminer on the same machine, each servicing 8 devices?

That is kind of what i am thinking. Not nearly as slick but doable. I'll be testing that later today.
Um ... the sample miner.php now allows you to show multiple rigs with a single script
(that can run anywhere on your network you like - however you'd need the latest miner.php version from my git until it's committed)
Just add an auto refresh to the page and it can even act just like the cgminer screen ...

And of course there are much more expansive monitoring tools for cgminer.

As for the limit - well, crashing cgminer or messing up the display completely sounds like a good idea to have a limit ...

... and yes you can run 10 copies of cgminer if you really want to and don't have a very small memory limit - one for each GPU/PGA if you really want to.

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

Activity: 1680


View Profile
April 19, 2012, 06:27:36 PM
 #4955

Just be sure to never save the config ...


speaking of saving the config..  i finally got around to trying this thru the api.  when I did the voltages were all 0.00 Sad

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
April 19, 2012, 10:47:31 PM
 #4956

I just downloaded cgminer 2.3.3 and I thought I'd give it a try. My initial impressions of it is that it's rather buggy and general usage is complicated by the long list of options displayed from cgminer --help.

Other miners I've used like phoenix and ufa-soft miner do not exhibit such problems and they work as expected. On the other hand, I can't even get a proper benchmark read out from cgminer. A search on this thread shows someone else with nvidia hardware encountering similar problems and difficulty though they were using an earlier version 2.2.3. Apparently the latest cgminer build hasn't address these problems yet.
You can't have your cake and eat it too. You either have lots of power and lots of features and with that, ways to set up and use all those features. It doesn't look like you ever actually managed to get it working at all and blaming the software is a great way to sort out the problem. At the very least start the program with -D --verbose -T and then give us the output, the way the documentation in the readme says when you have a problem. Didn't read the readme? Of course not, it's too long. Why is it too long? Because cgminer has 100 times as many features as other miners so the documentation needs to be extensive. It's a catch 22. cgminer is extensive machinery, it is NOT a fancy gui app. For that, use guiminer.

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

Activity: 1988


Ruu \o/


View Profile WWW
April 19, 2012, 10:58:20 PM
 #4957

By the way, another example to demonstrate multiple points that have come up tonight...

Gigavps recently came in the #CGMiner channel to report a bug about the "semi-graphical" command line display malfunctioning with more than 16 devices - he had just turned on a total of 17+ FPGAs.

How did I confirm this bug? Not with 17 FPGAs - can't expect every developer to have that kind of equipment handy for testing - but by using CPUmining to generate 17 CPU threads. So yet another thing CPUmining helps test is CGMiner's basic frameworks themselves.

Unfortunately, ckolivas expressed that he would refuse to merge a fix for this issue even if I wrote it. Pretty much defeats the point. (Though I did still offer to debug and write the fix for Gigavps, at a reasonable per-hour cost; I can't blame him for declining, considering it wouldn't get merged)

P.S. Kanoi, thanks for digging out the logs which show you alone agreed to abide by your poll, but #CGMiner is a private channel and posting logs publicly is technically forbidden.
Yes, I'm a real bad guy, I don't accept code, and I keep the cgminer channel private. Playing on words makes this whole discussion look ridiculous. There is no rule about posting IRC logs publicly. It is not even remotely a private channel, and I happily accept code when it's good, useful, and not controversial. The code in question, Kano had a reasonable objection to in an area that affected him and his code, and I don't have an opinion regarding it, so I wasn't going to make the decision (unlike other times). I don't care how you spin this, but unless you and Kano can agree on it, I will continue to refuse to accept it.

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

Activity: 2086



View Profile
April 19, 2012, 11:07:46 PM
 #4958

By the way, another example to demonstrate multiple points that have come up tonight...

Gigavps recently came in the #CGMiner channel to report a bug about the "semi-graphical" command line display malfunctioning with more than 16 devices - he had just turned on a total of 17+ FPGAs.

How did I confirm this bug? Not with 17 FPGAs - can't expect every developer to have that kind of equipment handy for testing - but by using CPUmining to generate 17 CPU threads. So yet another thing CPUmining helps test is CGMiner's basic frameworks themselves.

Unfortunately, ckolivas expressed that he would refuse to merge a fix for this issue even if I wrote it. Pretty much defeats the point. (Though I did still offer to debug and write the fix for Gigavps, at a reasonable per-hour cost; I can't blame him for declining, considering it wouldn't get merged)

P.S. Kanoi, thanks for digging out the logs which show you alone agreed to abide by your poll, but #CGMiner is a private channel and posting logs publicly is technically forbidden.
Yes, I'm a real bad guy, I don't accept code, and I keep the cgminer channel private. Playing on words makes this whole discussion look ridiculous. There is no rule about posting IRC logs publicly. It is not even remotely a private channel, and I happily accept code when it's good, useful, and not controversial. The code in question, Kano had a reasonable objection to in an area that affected him and his code, and I don't have an opinion regarding it, so I wasn't going to make the decision (unlike other times). I don't care how you spin this, but unless you and Kano can agree on it, I will continue to refuse to accept it.
No, there was no objection to this fix. You're thinking of something else, where Kano admitted his objection was unreasonable.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
April 19, 2012, 11:19:27 PM
 #4959

No, there was no objection to this fix. You're thinking of something else, where Kano admitted his objection was unreasonable.
The land of the pedants, this be, where I must be proven wrong. What a fun game. This is starting to feel like the linux kernel mailing list and I will start ignoring people if it continues. Yes there were 3 different code issues in question. One was the PGA display thing, one was the hidden CPU mining bugs, and one was to make cgminer's display work with more than 14 devices. I refused all of them. Your debate was over the first. My issue is you muddied the water and somehow made this discussion about me being a tyrant and not accepting obvious fixes. The display thing was pretty much unrelated. Stretch this out any further, and I'll ignore you.

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

Activity: 1260



View Profile WWW
April 20, 2012, 02:45:08 AM
 #4960

Ok, so I haven't been following the cgminer thread... but I stopped in here because of this horrible commit that removes the display of more than 8 devices.  This basically makes cgminer useless for large farms.  I was just getting to the point where I was digging cgminer and getting comfortable with it, so I cranked it up on one of my larger boxes and low and behold it becomes a useless brick.  

Ugh.  I can't really fathom how the thought process went in removing this.  Why would you want to remove literally the most important information from cgminer?  Every other bit of information cgminer provides is less relevant than the current hashrate and temps of the units that are connected.  You can literally take every single other piece of information and do away with it and cgminer will retain value.  However, removing that information makes cgminer less functional than every other mining program out there.  So... what was the thought process behind that?

Before someone mentions the API for a different front end, the API does not work on all machines.  I have 3 machines in my farm that, if the api is enabled, will crash the machine.   Disabling the API is the only thing that will allow cgminer to run on those machines.  The API is not the solution.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Pages: « 1 ... 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 [248] 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 ... 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!