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

jjiimm_64

legendary

Activity: 1876

Merit: 1000

Quote from: DeathAndTaxes on April 19, 2012, 10:22:54 AM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

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.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: DeathAndTaxes on April 19, 2012, 07:55:44 AM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: kano on April 19, 2012, 09:34:13 AM

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

...

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

greatwolf

full member

Activity: 230

Merit: 100

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: bitlane on April 19, 2012, 07:42:04 AM

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

bitlane

sr. member

Activity: 462

Merit: 250

I heart thebaron

Quote from: Luke-Jr on April 17, 2012, 10:55:19 PM

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

Chefnet

hero member

Activity: 686

Merit: 500

Quote from: nelisky on April 16, 2012, 01:18:03 PM

Quote from: Chefnet on April 16, 2012, 01:08:06 PM

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.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: kano on April 17, 2012, 11:38:43 PM

Meanwhile, posting about something that might be of use to a rare few people ...

I've updated the sample miner.php script to support multiple rigs.
(I split my rig so of course I needed to change miner.php

...

The new version of miner.php:
https://github.com/kanoi/cgminer/blob/master/miner.php

And just to be a little more useful I updated it to identify with colour some of the obvious warnings/errors:
Any Pool, GPU, PGA with 'Status' not 'Alive' will get a red background in it's 'Status' box.
Any GPU reporting zero for any of the ADL values - those values will get an orange (warning) background.
Any GPU, PGA that isn't enabled will get an orange (warning) background on the 'Enabled' field.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: cuz0882 on April 18, 2012, 03:41:01 AM

One of my gpu's stopped working and causes system crashes if I use it. Someone know a way to have it disabled in the config?

Use the -d option to specify which GPU's to use ...

Edit: So ... in the config file that would be "device" (i.e. from --device)

cuz0882

sr. member

Activity: 392

Merit: 250

One of my gpu's stopped working and causes system crashes if I use it. Someone know a way to have it disabled in the config?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Meanwhile, posting about something that might be of use to a rare few people ...

I've updated the sample miner.php script to support multiple rigs.
(I split my rig so of course I needed to change miner.php

It's of course not a replacement for those big systems like BAMT - but in my case I prefer something simple that only requires the one single php file to be able to see both my rigs summary and details.

If you run it as before with a single rig, it looks and works the same.
If you run it with multiple rigs, it displays a summary page first with buttons to display the same detail page as before for each rig.

The miner.php script explains the options at the top, but just to repeat one new part of that here:

Code:

# Set $rigs to an array of your cgminer rigs that are running
#  format: 'IP:Port' or 'Host:Port'
# If you only have one rig, it will just show the detail of that rig
# If you have more than one rig it will show a summary of all the rigs
#  with buttons to show the details of each rig
# e.g. $rigs = array('127.0.0.1:4028','myrig.com:4028');
$rigs = array('127.0.0.1:4028');

Pull request:
https://github.com/ckolivas/cgminer/pull/164

My git commit:
https://github.com/kanoi/cgminer/commit/3a3912070e6cec353a71ea38da4c832a9db182b2

The new version of miner.php:
https://github.com/kanoi/cgminer/blob/master/miner.php

miscreanity

legendary

Activity: 1316

Merit: 1005

Quote from: cablepair on April 17, 2012, 10:41:03 PM

Quote from: miscreanity on April 17, 2012, 10:30:08 PM

Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalksearch.org/topic/wonder-who-this-solominer-is-8862169-67634
https://bitcointalksearch.org/topic/forgetting-the-forgetful-68396
https://bitcointalksearch.org/topic/miners-that-refuse-to-include-transactions-are-becoming-a-problem-69423

You said Regarding CPU mining there are valid pros and cons
and give us three links about a solominer who isnt accepting transactions

cp is kinda confused here (I understand the botnet reference) but it still does not relate at all to your comment

Looking at it again, I even confused myself a bit

I probably should've said there are pros & cons to CPU mining botnets. There was a lot of discussion on that issue in those threads.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Luke-Jr on April 17, 2012, 10:55:19 PM

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

Regarding gigavps's issue with too many devices ...

ckolivas' commit to resolve that 4 days ago that gigavps is using ...

Disable per-device status lines when there are more than 8 devices since screen output will be corrupted, enumerating them to the log output instead at startup
https://github.com/ckolivas/cgminer/commit/f3e4305620825dbaa61eb26b2a0b6d9f5c924338

...

How about 17 GPU threads ...

LOL I tried 10 threads per GPU on my 2x6950 rig and rather oddly the MH/s went up by 10MH/s each GPU for the first few minutes and then settled back down to the same value after that as with 2 threads per GPU

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Luke-Jr on April 17, 2012, 10:23:42 PM

...

Quote from: kano on April 17, 2012, 10:18:42 PM

The one that we both agreed to abide by the response of the poll I created, but you not only ignored the poll results, but also went ahead and added more code changes to the git pull against the results of the poll ...

No, you agreed to abide by the poll, not me. That was why I let you make it, as biased and misinformative as it was. The results express nothing, since the poll had nothing to do with the actual bugfix we were talking about.

Thu Mar 29 2012 GMT+11

Code:

11:14 < luke-jr> kanoi: hurry up and agree explicitly :P
11:14 < kanoi> I want all the code to say ICA/BFL :)
11:15 < kanoi> (and I'd bet the users do too :)
11:16 < luke-jr> kanoi: stop demanding a bug -.-
11:17 < luke-jr> con_: you pulled kanoi's feature without agreement, why not a bugfix? :p
11:18 < con_> his code has been in use a month, there is a precedent
11:18 < luke-jr> and the only person using it says the bugfix is fine.
11:18 < kanoi> it's also been on the sgminer screen even longer :)
11:18 < luke-jr> also, the bugfix has been in use a month too :P
11:18 < kanoi> cgminer
11:20 < kanoi> again it's simple to just do as my first comment said on the pull request so that extra info is known if there is some use for it (maybe even the API can be simplified a bit with the 'extra' info)
11:21 < luke-jr> I can add the driver name to the API, sure.
11:23 < kanoi> you know I wont respond to anything you say directly coz you try to make silly comments about the meaning of replying to your comments
11:23 < kanoi> I want all the code to say ICA/BFL :)
11:24 < kanoi> (as it does now has in the API for a month and in cgminer for even longer)
11:25 < luke-jr> kanoi: you admit it's broken right now, stop being a stubborn jerk and holding cgminer back
11:25 < kanoi> what's broken - who reported a bug? (other than you)
11:26 < luke-jr> kanoi: the API name is reported inconsistently among FPGAs. You reported the bug, and suggested the solution.
11:27 < luke-jr> shall I dig out the log?
11:27 < kanoi> It's reported in a different way to GPU's - however, seeing that extra information is way better
11:27 < kanoi> yep dig it out - I have it also :)
11:28 < luke-jr> if you want extra information, use the extra info for GPUs too
11:28 < kanoi> it aint there yet :)
11:28 < luke-jr> yes it is
11:29 < luke-jr> has been for a month, you're just holding it back by refusing to let con merge it
11:29 < kanoi> 15 days
11:29 < kanoi> but it doesn't identify the GPU
11:29 < luke-jr> yes it does
11:29 < kanoi> with 3 characters
11:29 < luke-jr> ohnoes
11:29 < kanoi> the API should match the screen
11:30 < kanoi> as it does now
11:30 < luke-jr> and it does with the fix
11:30 < kanoi> the so called fix - removes useful information
11:30 < kanoi> I dont call that a fix
11:31 < luke-jr> it doesn't.
11:31 < kanoi> cows fly (when you throw them out of planes! :)
11:32 < luke-jr> it adds more information.
11:32 < luke-jr> and puts it where it belongs
11:32 < kanoi> ti hides it from the screen user
11:32 < luke-jr> not really.
11:33 < kanoi> OK how about a poll on bitcointalk to see if people want it to say "PGA" or "ICA" and "BFL" and whatever other FPGA's come along :)
11:33 < luke-jr> will you abide by its conclusion?
11:33 < kanoi> yep :) If I write the poll
11:34 < kanoi> and enough people respond
11:34 < luke-jr> so you'll make it biased? -.-
11:34 < kanoi> no I wont make it biased like you always do with everything you say
11:34 < luke-jr> let me know when it's ready so I can vote.
11:34 < kanoi> ...
11:36 < luke-jr> …

My first comment in the pull request

Quote

This changes the name that people will look for the devices in the API
e.g. Icarus instead of ICA (thus it also doesn't match the current cgminer screen)
Better to create new fields if you want to add extra information IMO

The pull request:
https://github.com/ckolivas/cgminer/pull/157

The poll (that was linked in this thread also)
https://bitcointalksearch.org/topic/small-change-of-cgminer-screen-display-and-api-display-74532

cablepair

hero member

Activity: 896

Merit: 1000

Buy this account on March-2019. New Owner here!!

Quote from: miscreanity on April 17, 2012, 10:30:08 PM

Quote from: 01BTC10 on April 17, 2012, 08:34:10 AM

Quote from: DeathAndTaxes on April 17, 2012, 08:13:46 AM

Quote from: TheHarbinger on April 17, 2012, 08:10:30 AM

Yeah, Gigabyte boards don't like to boot from USB with BAMT on them. It's a known problem.

Strangely the behavior of giga boards seems to vary from model to model and even bios version to bios version so you can get "lucky". That being said it is one reason I steer clear of gigabyte (I liked them pre-Bitcoin). I mean bootstrapping is one of those core BIOS functions. If a BIOS can't handle all supported methods of booting it shouldn't be sold. Period.

True but I can't really RMA the board since NCIX specify that I can only exchange it for the same model...

I actually had some success last year booting some Gigabyte boards from USB with Plop. Most of the time, I was able to chainload by booting from a FAT16 Plop USB stick to another that held the OS.

The primary issue with Gigabyte (if I recall properly) is that a USB boot drive cannot have more than one partition and must be formatted with FAT16 - no FAT32. Quite aggravating.

I picked up the cheapest SATA drive I could get and it's been a much nicer experience since. It now acts as a multi-purpose server in addition to mining.

Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalksearch.org/topic/wonder-who-this-solominer-is-8862169-67634
https://bitcointalksearch.org/topic/forgetting-the-forgetful-68396
https://bitcointalksearch.org/topic/miners-that-refuse-to-include-transactions-are-becoming-a-problem-69423

You said Regarding CPU mining there are valid pros and cons
and give us three links about a solominer who isnt accepting transactions

cp is kinda confused here (I understand the botnet reference) but it still does not relate at all to your comment

also Kano I love and respect you brother but I have to comment on this, In my humble opinion public forum polls are not a good method of making decisions and if I was luke-Jr I probably would not respect it either.

miscreanity

legendary

Activity: 1316

Merit: 1005

Quote from: 01BTC10 on April 17, 2012, 08:34:10 AM

Quote from: DeathAndTaxes on April 17, 2012, 08:13:46 AM

Quote from: TheHarbinger on April 17, 2012, 08:10:30 AM

Yeah, Gigabyte boards don't like to boot from USB with BAMT on them. It's a known problem.

Strangely the behavior of giga boards seems to vary from model to model and even bios version to bios version so you can get "lucky". That being said it is one reason I steer clear of gigabyte (I liked them pre-Bitcoin). I mean bootstrapping is one of those core BIOS functions. If a BIOS can't handle all supported methods of booting it shouldn't be sold. Period.

True but I can't really RMA the board since NCIX specify that I can only exchange it for the same model...

I actually had some success last year booting some Gigabyte boards from USB with Plop. Most of the time, I was able to chainload by booting from a FAT16 Plop USB stick to another that held the OS.

The primary issue with Gigabyte (if I recall properly) is that a USB boot drive cannot have more than one partition and must be formatted with FAT16 - no FAT32. Quite aggravating.

I picked up the cheapest SATA drive I could get and it's been a much nicer experience since. It now acts as a multi-purpose server in addition to mining.

Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalksearch.org/topic/wonder-who-this-solominer-is-8862169-67634
https://bitcointalksearch.org/topic/forgetting-the-forgetful-68396
https://bitcointalksearch.org/topic/miners-that-refuse-to-include-transactions-are-becoming-a-problem-69423

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: DeathAndTaxes on April 17, 2012, 10:16:11 PM

As far as needing a test platform wouldn't just using I don't know ... any GPU be a better test platform?

Except then you have to stop mining for real on that GPU.

Quote from: DeathAndTaxes on April 17, 2012, 10:16:11 PM

Given the near universal nature of GPU and their low cost (especially used low end cards) seems silly to test using a code base that 99.9% of your users aren't using.

CPU mining and GPU mining use 99% of the same code, ever since I refactored cgminer to add FPGA support.

Quote from: kano on April 17, 2012, 10:18:42 PM

I presume you aren't referring to the 'bug' regarding device naming?

No, I was referring to other bugs, like the scantime bug.

Quote from: kano on April 17, 2012, 10:18:42 PM

The one that we both agreed to abide by the response of the poll I created, but you not only ignored the poll results, but also went ahead and added more code changes to the git pull against the results of the poll ...

No, you agreed to abide by the poll, not me. That was why I let you make it, as biased and misinformative as it was. The results express nothing, since the poll had nothing to do with the actual bugfix we were talking about.

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