README last FAQ.

Stratum

Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon.

Normal, with new blocks you don't keep working on it, you throw it out to not create shares from stale work.

Sure their first post is "unprofessional", but they're not asking you to send millions of dollars before there's any proof the hardware exists...

Well it's nice they decided to use me as their primary software developer if something ever goes ahead... but given conman is my IRC nickname and it holds certain "connotations", it would probably have been better to use my real name 

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

The story so far after a few hours:
Reject ratio is a little higher than my regular pool, but that pool is also in my local city so a 50ms ping time whereas mtred is 240ms. However I used to get up to 2% rejects on mtred, which stopped me mining here, so this is a ludicrous improvement. Note there is one "Unable to get work from server occasions". That would have been a disconnect which would then have dropped some shares as mentioned in the previous post. At the moment the stats don't show how many of those shares were lost.

I'm sure current miners moving over to stratum would dramatically lower the server load. Now if higher diff share submission was added, the load on the server would drop even more and be able to tolerate even asic hashrate submissions.

A message saying:

Why would you use aticonfig when you can change the clocks directly with cgminer?

It all has to be implemented on the pool side, be it higher difficulty or variable difficulty, so it's up to redditorrex.

As a followup, the stale rate is markedly lower than it used to be, which is great news since that was the main thing keeping me from mining here. Many stratum disconnects would also be a new problem since shares are lost on each disconnect, but so far there have been no disconnects.

Unfortunately the forum does not block what luke-jr writes when someone quotes him even if I do have him on ignore .

How I feel about FPGAs and ASICs has nothing to do with your claims. If I were to call it, I'd say you were upset because I was planning to exit the scene with FPGAs but ASICs changed the scene and I indeed changed my mind so you didn't get to take over.

The internet now has a vast history of the events yet you continue to dispute it as though you actually believe it. I used to joke about it, but I'm really becoming convinced you have a personality disorder now. As a doctor, I do diagnose these conditions in the real world. If over time you end up having a problem with the rest of the world, perhaps it's not the rest of the world at fault.

Show something about the code.
Prove something useful.
Respond about objective things.
Show some humility.

Look at what he wrote in response and see for yourselves how much it precisely matches the pattern I, and many others, described, and try and find the evidence in his response to support his outlandish claims that aren't just baseless attacks.

This is precisely why I avoid these discussions in the first place and ignore his posts. Responding is just troll feed. I shall stop monitoring this thread.

Excellent I'll give it a go and see if it has nailed the high reject problem. Next stop, vardiff!

Forks I don't have a problem with.

I do not for a second deny that the "device API", as luke-jr calls it, was first written by him, as was the first BFL driver for cgminer. However this was all code for cgminer at the time, and the code has been heavily rewritten since then.

Calling cgminer a fork of luke-jr's version has got to be one of the most ridiculous lies I have ever heard regarding code.

Initial revision of cpuminer (Nov 25 2010) https://bitcointalk.org/index.php?topic=1925.0 :
https://github.com/ckolivas/cgminer/commit/9599867d8b9ddd909ea3dc37679b34cab5de5674
Jeff Garzik committed 2 years ago
Version 1.0 of cpuminer: May 09, 2011 Jeff Garzik authored 2 years ago

First commit by me to cpuminer: Jun 08, 2011
https://github.com/ckolivas/cgminer/commit/8a832eeab524bbad160adb7c27acb370d6adedff

First GPU mining code added to cpuminer code by me: June 23, 2011,
https://bitcointalk.org/index.php?topic=1925.msg264355#msg264355

First release by me under cgminer name superceding cpuminer: July 13, 2011
https://bitcointalk.org/index.php?topic=1925.msg357421#msg357421

etc...

First release of bfgminer as fork of cgminer: Apr 26, 2012
https://github.com/luke-jr/bfgminer/commits/bfgminer-2.3.4

Luckily history on the internet is there to make any such claims truly absurd. Simply reading the changelog and timeline of each is enough to show it would be absurd to think that bfgminer somehow predated cgminer when bfgminer didn't even exist for the first 9 months of development that cpuminer became cgminer. Yes, luke-jr contributed code to cgminer... this was when cgminer was the only maintained code around based on Jeff Garzik's original cpuminer.

The "reason" luke-jr created the fork to cgminer was that he contributed code to cgminer that was rejected by me based on evidence provided by Kanoi that it was buggy, but he just wanted the code out despite the issues with the code which I refused to accept as the concerns were valid. Creating a fork because you want to get new code out that introduces many regressions is not an unusual practice on the internet, and is unfortunately only counter productive to the development process, especially when the original code source is still being actively maintained. Once he had forked his version, 99% of the cgminer code continues to go to his fork, and 1% of the cgminer code came from his fork. One unfortunate thing is that the git source control management system tells you who committed code to a source tree (such as bfgminer), but not who actually wrote the code. Follow the parent of the code tree on github on bfgminer and you'll see it was basically mostly code pulled from cgminer that I and kanoi have written. On the other hand, I have gone out of my way to avoid taking almost any code from luke-jr's fork unless it is actually a bugfix or -in the case of the bfl flash code for linux- a feature I will never bother coding myself. That means that since the fork, 99% of the code in cgminer has nothing to do with luke-jr. I even went to the extent of developing my own GBT implementation, which is the communication protocol invented by luke-jr (that I dislike immensely compared to stratum) from scratch rather than use his already existing "reference implementation" because his code was python and it would be more efficient coded by myself in c instead.

It is very easy to side with a camp that you happened to start using first, and even harder to consider you might have sided with the wrong camp if you came on the scene late in the development process. Look at the history of luke-jr throughout bitcoin history and across this forum and you'll find an amazing record of behaviour you wouldn't trust as far as you could throw him. Whenever questioned about something he either simply says "it's not true" or "I don't lie" or doesn't respond, or appeals to a forum moderator to have the post deleted as a troll. He has also never been known to back down on an argument, say he's wrong or accept any form of leadership, constantly trying to take charge - so far as leading to a huge battle between the lead bitcoin maintainer, Gavin Andresen, and himself on one of the BIP issues. Kano is an annoying prick, but he produces evidence to support everything he says on the forum and will graciously say when he's wrong.

I try very hard to keep out of these discussions because I believe code and data speaks louder than words, and am primarily a coder and totally utterly flabbergasted by this whole ridiculous discussion and when one compares the hostile fork to cgminer I can only shake my head. Once upon a time I thought that code speaks louder than words and the truth shows its face over time. However I have come to realise that if you don't go to at least some effort to defend yourself, you get desperately misrepresented.

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation. This is why I have luke-jr on ignore. What astounds me more than anything else, in light of this evolution of events, is his persistence in the face of all logic and reason.

That is all.

At last, so at least the goddamn conspiracy noise will drop to only the most paranoid who don't believe any amount of evidence.

Try a different driver version.

I thought I'd have to write a driver for it, but now I have to find a rider for it.

That ought to teach all those non-believers!

The windows and linux output is meant to look the same. Usually when something doesn't work on the windows version, like the text user interface, your virus software has been silently fucking you over by deleting files without you knowing - mining software is often falsely accused of being viruses.

Hardware errors are not uncommon at high overclocks or high temps. Just bump the clocks down a little or drop temps further. If you haven't overclocked, it may be a sign of some hardware instability but likely is harmless.