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

No moron, coz I've completely rewritten/replaced that retarded serial-USB library and we are working on our code as it stands - we don't want your code, that's why we haven't got much/any of it from you for a very long time.
The last major piece of code in cgminer from you was the piece of shit MMQ code that didn't even fucking work until I rewrote some of it.
Complete pain in the ass that you committed code to cgminer that didn't even work and you hadn't tested it ... or hadn't bothered to send the updates to actually make it work ... not the first time you've done that ...
Will be interesting to see what happens when some ASIC code is actually written and how it compares ... and if you just copy it from me or copy it and pretend you wrote it yourself or write it yourself from scratch

You heard them, they don't want to copy and more updates to the FPGA code because they think not doing so now helps their case for pretending it never happened.

I forgot to respond this. When stratum server detects malformed message, it forcibly closes the connection (one cannot expect that server can read ID of message when message payload is malformed). So cgminer don't receive anything in this case.

kano, what exactly do you expect to see from that tcpdump? We gave you raw data which come to the server software (which is opensource, so you can check there's no obvious bug).

That line is untouched by the server side (except that receiving buffer is parsed by newlines) and you can see that only values in brackets are malformed. The chance that they got corrupted during the transfer or by server side is (comparing to possible bugs on sending side which prepares the message) *really* minimal.

I don't have a chance to take a dump of that communication, because my miner isn't affected by this bug, but I don't think we'll see anything helpful in tcpdump anyway.

I'm not bashing you or ckolivas for a bug in miner, we're just reporting it. That part after ',' wasn't meaningless, I just reminded that the problem may be in the similar area (buffer overflow) like in previous case. Please take a look at recent changes as this didn't happen in previous versions.

As I have already explained in IRC to gigavps - I'll need the raw wire tcpdump, for me to be sure it is cgminer (or the cgminer "Reject" showing it corrupt)
I have not said anywhere that it certainly "isn't" cgminer.
However, that dump is a dump from another piece of software that I don't even have the source code for, so I've no idea if that software was the cause of it or not.
No software is perfect, all code has bugs.
The tcpdump will clearly show which piece of software is the cause and the cgminer "Reject" message will also help to point out 'where' in cgminer it is, if it is cgminer.

As for your last comment (after the ',') that is meaningless.

As I have answered indirectly all over the forum and directly in IRC as well.
I certainly will not be supporting x6500.

Without the hardware, there is no point in writing a new driver, as there are many issues with development and support of hardware that I do not have.

There is also the new issue that many devices will indeed no longer be worth even running shortly with the advent of ASIC ... though there is still no proof of anyone actually releasing any ASIC as yet.

I certainly see no reason at least for me to pour any effort into it.

Actually it is clearly bug in cgminer. That quoted json line is raw wire format and these binary data definitely should not be there. It looks like buffer overflow, there were such problems when stratum support has been introduced in cgminer.


Thank you for looking at this problem.

So... Will there be x6500 support.. or not ?!

That's an easy one to prove is a lie ... and worth brining it up due to the outrageous ridiculousness of the claim.

I was the one who worked out problems with Xiangfu's Icarus driver before it worked ... and helped find the problems to get it working.
Go ask him yourself, you fool.
That's why I was given an Icarus board (and bought one at the same time)
The #cgminer IRC log shows that also ... and that you were in that IRC discussion ... around Feb 13 to Feb 15 2012

Now this leads to a very interesting question ... since Luke-Jr is so adamant about how he is the one and only with regards to all this device driver and FPGA code back when it was first written and anyone else's original involvement in it was next to nothing, why didn't he help Xiangfu fix his FPGA code interfacing with Luke-Jr's all brand new only he wrote it all code?
(I ended up helping Xiangfu coz Luke-Jr stopped helping before Xiangfu got anywhere near the driver/FPGA code ... Luke-Jr only helped Xiangfu make a test nonce and then disappeared for 24 hours ... followed by a reject to help with a question Xiangfu asked when he came back,  then comments about a bin2hex fix and a few OT comments for the following days)

The answer is simple, Luke-Jr's changes were not as all encompassing and self generated as he makes them out to be.
As one (of many) simple examples: his changes included copying ideas from ckolivas' GPU code as he clearly even states here:
https://github.com/ckolivas/cgminer/commit/a4d1fe1e5d116851d45624496327445db9660ff0

Again, as usual, he is copying ideas and claiming them to be his own.
In fact, as a lot of commits show around then, it is true to say that he often copied someone else's code from one place to another (and thus the git gives him credit to writing it) and the amount of code he actually provided to cgminer is less than even the git says it is.
... though I have already proven that: with the code I wrote in a file in his git that says he wrote it all, but indeed I wrote most of it - as is easy to see in the gits

Thanks, I guess 

I see nothing has changed while I was away... not that I expected anything more  . Fortunately, I predicted well that 2.10.4 would be a cracker release and it has lived up to my expectations.

Welcome back. Home sweet home, eh? 

https://www.youtube.com/watch?v=j_oUjMxR0YU

go away!

You have things backward: cgminer is trying to rip off BFGMiner.
From January until the middle of May (2012), I was the only one who had anything to do with device driver or FPGA support, with exception to Xiangfu who contributed a complete Icarus driver (based on my BitForce driver) in Feburary (which I maintained afterward). While Con was copying these improvements back into cgminer, I had no reason to make a separate release under another name - obviously a mistake that in hindsight has allowed Con & Kano to steal credit for it. It wasn't until April that Kano decided to begin forking the code (in the process reverting numerous bugfixes and improvements since he doesn't know how to use git), and Con backed him up on it because of their long history as friends. Shortly after Con got pissed off at ASICs being announced (since they obsolete the GPUs he had only ever worked with), he threw a fit on the forums making accusations that vendors didn't provide him devices (despite his never having been involved with this up to that point), and stopped accepting even bugfixes to the code he maintained from me, forcing me to effectively fork the rest of the codebase as well just to have the bugs fixed.

BFGMiner continues to advance in both core functionality and FPGA (and soon ASIC) support, as should be obvious by now.

Edit: Forgot to mention, nelisky contributed and maintained the Ztex driver from March until May.

Edit: I should perhaps also mention, there have been at least a couple of significant reorganizations delayed due to the cgminer team's aversion to collaboration and cooperation, but BFGMiner will be getting the result of this work very soon, maybe even before ASICs. It's a shame it took this long, though; Con is a great programmer, I don't know why he can't just work as a team.

Edit: Observe for yourselves, the authors of the code in question the moment before Kano forked it (in cgminer's own repository): BitForce and Icarus

Any chance we can see x6500 support in cgminer ?

I really dont want to use rip-off-scumbag-bfgminer just because of this..
I'm currently running them on MPBM but I'm not happy with it.

oc

Firstly, I presume in cgminer you also see a share reject for it?
What was the share reject message? Was it also corrupted?

Normal rejects (the very low % ones) in Stratum mining seem to only be like so
i.e. at the same time as the new block message:
[2013-01-04 07:28:17] Stratum from pool 0 detected new block
[2013-01-04 07:28:17] Rejected 13d41e5e Diff 12/8 BFL 0 pool 0 (Not current block.)
The message in (...) is up to the pool/proxy

Any other Stratum rejects will most likely represent a pool/proxy bug or cgminer problem

Disconnects, of course, should be like so (I get them at midnight coz I forcefully disconnect/reconnect my network)
[2013-01-22 00:00:21] Lost 1 shares due to stratum disconnect on pool 0

It would also be ideal to actually see the dump of the protocol on the wire.

On linux that can be got by:
tcpdump -n -l -i any -s 2000 -XX port 3333 | tee dump.log
 or
tcpdump -n -l -i any -s 2000 -XX port 3333 > dump.log
 if you don't want to watch it

Obviously the port number (3333) would match the Stratum port number you are using.
The log file should not be overwhelmingly large even for a MiniRig since Stratum doesn't need to transfer ridiculous amounts of data
The start of each packet dump includes a timestamp

Basically this will show if indeed cgminer/Curl is corrupting it or if the proxy is.

I have a memory overlay for cgminer that works on linux and windows - but not with GBT coz my overlay uses about 30x the RAM and thus with GBT uses way too much RAM
It's a single *.h that you only need to include in miner.h with no other changes anywhere else,
that does a lot of memory protection and testing (and also reports unfreed memory via the API)
This will find corruptions that happen before or after any malloc'ed data and report the line of code that allocated the data and if the corruption falls under a common subset, also crash cgminer when the corruption actually happens so the traceback shows the code that caused it
It wont find corruptions inside data - but hopefully, if there is a problem, it happens randomly enough to not just land in the middle of data
It's my lazy way for debugging bad pointers - coz reading random code usually doesn't find such errors without a lot more details or knowing the change that caused the bug (e.g. using a git bisect)
But a git bisect isn't always going to work either since code changes can move bad pointers around and thus hide and reveal them independently of the bug still existing.

Anyway, if you could first do the tcpdump and find the matching packet to be sure it is cgminer,
then chase me up in #cgminer and we can work out what to do next

The reason for wanting the tcpdump is as mentioned further up - where he was only seeing it with the proxy, not with direct pool access - and that could be the same problem you are seeing (but of course both could still be cgminer and not the proxy's fault - I've no idea at this point)

I was mining on a local stratum install testing out some stuff when the stratum server ran into this message from cgminer:


Not sure what that is, but cgminer submitted it. All of the mining equipment running at the time was BFL singles or mini rigs.

Hello,

I have a questions about long-polling...

I have a failover script set-up which uses a few different pools mining a few different currencies and depending on what is profitable at the time I switch the connection order to keep the most profitable coin being mined first.

My question is:

Let's say I am mining TRC at Coinotron, but I also have my script setup to failover to mining BTC at BitMinter, LTC at litecoinpool and maybe one or two other pools using different block chains, is the long-polling from the failovers (using different blockchains) going to hurt my mining efficiency at the pool the miner is currently mining on (in this example TRC @ coinotron)...?

Thank you for any and all help and information...

Well at a guess it means one of:
a) the proxy definition of the command and response order is somehow different to what the pools think it is under certain circumstances
b) there is a disconnection problem between Curl and the proxy that doesn't exist between Curl and the pool
c) there is a disconnection problem between the proxy and bitcoind that results in the disconnection with the miner
d) there's some weird bug in cgminer that only shows up when connected to the proxy

I guess it would require a network/protocol log of both connections (miner<->proxy and proxy<->bitcoind) before and when it happens to work out where the problem is.