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

Alas I don't believe that for a second 

That shut someone up.

Seriously, get a life and get out of this thread.
Go pretend you are god in your own thread, you are not welcome here and you have alrady been warned by a mod about posting this sort of shit here over and over again.

If anyone is interested ... how I helped find the curl bug:
(and debunk the douche's FUD)

I was helping someone with a double MiniRig and they had it exiting without any reason - so we switched versions and that solved it
(wasn't sure why it was exiting)

Earlier that night I created my 2.6.3a download and had been running that
That night cgminer crashed ONLY on my Icarus rig (at exactly 2012-08-05 14:51:31 UTC - or 6-Aug 00:51:31 my time)
I run 3 instances of cgminer: a) 1x6950 b) 1xBFL c) 2xIcarus
Why did it crash?
I had no idea, it just seg faulted after almost 5.5 hours running 2.6.3a (and I didn't have ulimit set so no core dump)
The other two were still OK

I then turned on ulimit and restarted it so as to get a core dump if it happened again
Got a seg fault again about 10 hours later, went into gdb and a total WTF - it had cashed in curl_easy_setopt()
but since I hadn't compiled it with -g I couldn't tell the code line
My timezone is UTC+10

This next one I called 2.6.3c

(the WOOT was coz it happened so soon afterwards)

I changed all the curl DEBUG to ERR so they would always show and added a 5s sleep before the crash line to ensure the logs would clear before it crashed

That night I also setup 3 LTC CPU miners to see if that would help track down the bug running 6 cgminers instead of only 3
... no point CPU mining BTC so I setup LTC so that it could possibly actually find something

I didn't spot the obvious straight away (until much later)
#1  0x0000000000418b13 in json_rpc_call (curl=0x0,
i.e. curl was NULL in that pastebin one and 0x4 (even worse ) in later crashes

Next morning after spending some time looking at the code, but about to be busy with work, I posted a pull request that I hadn't tested and had no idea if it was correct and was there just for ckolivas (conman) to see (he wasn't around IRC at the time) and consider if that might be the issue
https://github.com/ckolivas/cgminer/pull/289


Anyway, with help from all the info and crash dumps I had found, and one later commit that didn't fix it and had to be rolled back, ckolivas found the bug and fixed it with a small change:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1

The original cause of only my Icarus crashing was that Icarus gets work faster than any other device due to the fact that it requires work as soon as it finds a share, it doesn't complete the nonce range.

I had NFI originally why it happened and traced it to curl directly via core dumps - nothing to do with Jesus Troll at all.

----------------------

Now for the JSON change

I saw his post in his Abortion Miner thread that said he was going to have a fix in his next release, and realised of course that would be an issue for things like the pool passwords and the api description, so I went a wrote and tested a change and put up a pull request.
About 6 hours later, Jesus Troll posts a stupid comment on my pull request:
https://github.com/ckolivas/cgminer/pull/292


Reading that comment, I then went and looked as his code and made the comment I made there in my pull request.

My code is actually very different so as to ensure it's easy to pass ALL strings through the escape function, and thus in my case, since I am escaping every string, I didn't miss the one that also obviously matters: pool password

That config save function is not in any way time critical, so I wrote a function that was simple to use and used it on all strings.

But making it a simple code change as I did (rather than a mess of 2 extra lines of code each time that I later saw Jesus Troll did) means that I've applied it to all strings no matter what, and anyone who adds new strings in there in the future, can do it just as easily
i.e. that was the reasoning behind my reply in the pull request

yes, it is the highest. without running taskmgr as administrator it only lets the priority to be set to high

Does anyone know if BIOS flashing to the overclock settings of 5000 series gets better or more stable hashrate?

Is realtime the highest priority in Windows? I set mine to high priority in Ubuntu (niceness value of -5), but I haven't noticed much of a difference.

I'm convinced that setting CGMINER.exe priority to Realtime DOES significantly improve Mhash/s (on windows 7 64-Bit at least)
To do that, after opening, open taskmgr as ADMINISTRATOR right click the process and Set Priority->Realtime

using CGMINER 2.6.4, I didn't set priority to realtime, kept at normal
after over an hour of mining, average mhash is 2239
Then I reopened, set priority to realtime
after over an hour of mining, average mhash is 2272 and rising (eventually rose to 2276 6-8 hours later)

SETTINGS for 3x5970's:
Intensity: 8
GPU clock: 851
Memory Clock: 284
Voltage: 1.1v (had to use Sapphire Trixx, Cgminer wasn't setting my voltages)
Kernel: Diablo
vectors 2, worksize 256, these two settings I placed in the BAT file used to open cgminer, the rest are in the .conf file. [BAT FILE: cgminer.exe -v 2 -w 256 --failover-only]
Fan auto, temp target 80 thought it goes way over and even hits 87 which is my temp overheat and I don't think CG is doing anything at that point, temp overheat is 90 it has also hit that very rarely but doesn't seem to shutoff my cards!

All older versions here:
http://ck.kolivas.org/apps/cgminer/

http://ck.kolivas.org/apps/cgminer/cgminer-2.5/

Is there a place to get older version of cgminer?  I need 2.5.0, I think 2.6.x is the problem I'm facing right now...

People seem to not understand it is entirely possible 2 people arrive at the same solution to the same bug at different times. This complaint is now about something like a one line bugfix with exactly those circumstances. Paranoid delusions indeed.

Detraction and trolling me is their apparent motive.

Maybe also related to this:

It was a fork of the original CGMiner. I rewrote a lot of code to make it possible to have other drivers (the original was CPU and GPU as mostly separate code), and added support for FPGAs. Con took that code back into CGMiner, and eventually forked his copy of it.

So in short, cpu-miner was forked to CGMiner for GPU support. CGMiner was forked to BFGMiner for FPGA support. BFGMiner was then forked back into CGMiner for political reasons.

Also, I make sure to attribute even Con and Kano's (indirect) contributions to BFGMiner.

Isn't BFG a fork of cgminer?  So he came in, added a few lines, and then now HE'S complaining about stolen code?

ignoring the ginger now. because gingers are scary!

At the end of the day it's just your paranoid (delusional?) opinon that they took your code, changed it then submitted it themselves.

Since all this code is GPL, would the easier solution for them not simply be submit your commit, which would involve almost zero effort, rather then re-arrange your code? What is to gain? What's their motive?

Ah, an accrediting issue. As I know nothing about who did what I'll bow out.

Please don't make implied accusations that aren't true, kthx.

A bit like taking some header files and removing the author/copywrite info?

Go troll elsewhere. CGMiner was based on Garzik's work in the same way: Con added GPU support, and I added FPGA support. Until ASICs were announced, Con had nothing to do with FPGA support.

Copying is not the issue. The issue is Con and Kano passing off others' work as their own.