Author

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

newbie
Activity: 50
Merit: 0
In view of the "Flak" thats flying here, I post this with some trepidation.

Really I don't know where is appropriate to post this, either here or on the Stratum Topic.
I have been watching this issue for several weeks waiting for somebody else to bring up the problem. No body has, so it seems that maybe I am the only one who is seeing this.
I have the 1.3.0 Stratum Proxy running and two Miners Xubuntu 11.04 64bit - CGMiner-2.10.4 with 6 GPU's on each.
The problem is the miners intermittently lose connection with the Local Proxy, drop a few shares and then reconnect again. Both Miners do it, but not simultaneously. There is no apparent pattern it's just random. Sometime you will get a burst of it and then it will settle down again. There is no difference in frequency of disconnects between the Miner connected on localhost or the Miner connect on the LAN. Each disconnect gets the same error message as shown below from the Proxy. I am fairly sure this is not a WAN problem.  Assuming, if the WAN went down both would show as disconnected within seconds of each other.
If I use the CGMiner Stratum and connect to the pool directly I get virtually no disconnections.
I have tried installing and running the Proxy on either one of the Miners, I have tried installing on a separate machine- with Proxy running on WinXP 32bit or Ubuntu 11.04 32bit, I get the same, - disconnects with the same error message from the Proxy.
If I use the CGMiner Stratum and connect both miners to the pool directly without the local Proxy I get virtually no disconnections.
If I run a single GPU it seems like the problem goes away.

Is anybody else getting this? if so, have I missed something?

(Xubuntu 11.04 64bit with identical hardware on both miners.)

_______________________________________________________________________________ _____________________________

2013-01-20 22:00:01,851 INFO proxy client_service.handle_event # New job 1ea8 for prevhash ae4d869f, clean_jobs=False
Unhandled Error
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/python/log.py", line 88, in callWithLogger
    return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/python/log.py", line 73, in callWithContext
    return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/python/context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/python/context.py", line 81, in callWithContext
    return func(*args,**kw)
--- ---
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
    why = selectable.doRead()
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
    return self._dataReceived(data)
  File "/usr/local/lib/python2.7/dist-packages/Twisted-12.3.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
    rval = self.protocol.dataReceived(data)
  File "/usr/local/lib/python2.7/dist-packages/stratum-0.2.11-py2.7.egg/stratum/protocol.py", line 174, in dataReceived
    self.lineReceived(line, request_counter)
  File "/usr/local/lib/python2.7/dist-packages/stratum-0.2.11-py2.7.egg/stratum/protocol.py", line 185, in lineReceived
    raise custom_exceptions.ProtocolException("Cannot decode message '%s'" % line)
stratum.custom_exceptions.ProtocolException: Cannot decode message '{"params": ["XDELETED my USERX", "p��#", "�l", "���#", "58a4702a"], "id": 138, "method": "mining.submit"}'
2013-01-20 22:00:01,937 INFO stats stats.print_stats # 2 peers connected, state changed 1 times




legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Well he also copied the ATI include files and removed the ATI copyright information from them and later put in a different one under duress:
https://github.com/luke-jr/bfgminer/tree/bfgminer/ADL

... and before he comes up with some stupid comment about he typed them in all by hand from memory or some such stupidity, it is quite obvious to note that if anyone was silly enough to attempt that without using the original as source, the files would indeed be too unreliable to risk using.
They total
Code:
  782  2375 25311 adl_defines.h
   32   205  1356 adl_sdk.h
  572  1332 13487 adl_structures.h
 1386  3912 40154 total
So almost 40K of data ...

He did of course add his own version of attribution the day after I made comment about the fact that he had removed ATI's copyright.

My (and other) comments about it:
https://github.com/luke-jr/bfgminer/commit/9a69a317123592eec5374a4b7893e4fe3c2f9d7a#commitcomment-1684590

His later changed version of the ATI copyright he removed:
https://github.com/luke-jr/bfgminer/commit/8bb6c2b5e3653a5bf4f92c9572ee638f2cbc1583

Yes he indeed likes to take credit for other people's work ...
legendary
Activity: 2128
Merit: 1074
Luke-Jr you are a scam artist fraud.
You regularly try to take credit for other's work.
Just to refresh anyone's memory: Luke-Jr publicly tried to take credit for original Satoshi Nakamoto's work, one of the key algorithms in the reference Bitcoin client.

https://github.com/github/dmca/blob/master/2012-01-09-bitcoin.markdown

Further discussion was there:

https://bitcointalksearch.org/topic/m.685086
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Ignoring Kano's lies... here's an example of how cgminer corrupts shares:
I'm a little confused. I don't have any issue with CGMiner issuing corrupt shares.
It doesn't happen every share, just (as far as I've seen) randomly.

So how does this so called "issue" invalidate all of the arguments that Kano just posted. You literally just sidestepped everything he just called you out on.
Yes, I did. Because he didn't call me out on anything, just spewed a bunch of lies with no truth to them. There's really only one thing you can do with such trolling: ignore it.
Luke-Jr you are a scam artist fraud.
You regularly try to take credit for other's work.

You have stolen code.
This commit proves it:
https://github.com/luke-jr/bfgminer/commit/8445ce898f3a704c884eae0c9971856e25969d28

As I stated above, there are 2 files that I know of in your clone that you have attributed code, that I wrote, to yourself.

Who knows how much other code you have done that with.

You even stated that the ztex code was your original - where in fact nelisky wrote it.

Scum.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
legendary
Activity: 2576
Merit: 1186
Ignoring Kano's lies... here's an example of how cgminer corrupts shares:
I'm a little confused. I don't have any issue with CGMiner issuing corrupt shares.
It doesn't happen every share, just (as far as I've seen) randomly.

So how does this so called "issue" invalidate all of the arguments that Kano just posted. You literally just sidestepped everything he just called you out on.
Yes, I did. Because he didn't call me out on anything, just spewed a bunch of lies with no truth to them. There's really only one thing you can do with such trolling: ignore it.
legendary
Activity: 952
Merit: 1000
Ignoring Kano's lies... here's an example of how cgminer corrupts shares:
I'm a little confused. I don't have any issue with CGMiner issuing corrupt shares. I even got a block solver on OzCoin a week or two back. So how does this so called "issue" invalidate all of the arguments that Kano just posted. You literally just sidestepped everything he just called you out on.
legendary
Activity: 2576
Merit: 1186
Ignoring Kano's lies... here's an example of how cgminer corrupts shares:

2013-01-21 03:58:19,492 JSONRPCHandler  ERROR   Error during JSON-RPC call (UA=
b'cgminer 2.10.4', IP=::ffff:94.126.178.1): doJSON_submitblock['0200029c37a0ed5
1c08f04a41ff31b95581438905341a3330bcfc50b129051afc3ea4a420&w0000000100000000000
00000000000000000000000000000000000000000000000000000ffffffe52e15d40d233bcdb5ea
bcb610800000000000000002f503253482f00eb710000ffffffff2058790c04000000001976a914
b9a295c6d524539bc1697c88b5924e0ca93e804b88acfc490aa2f3e1e0eb5dbe230141dcc6d55d4
dbbebff388acd9471404000000001976a9144099b9412742931608242dd3dfe14f339a2664e988a
c6b681d04000000001976a9141b8a3702070457f7acf88acebb80704000000001976a91452e1efd
5379f772621ebf578ebd7bc33dc48a33d88acdc770104000000001976a9148d8a9e208fcac0ad56
6b7507719e6e8699e72e3f88ac4facbf559b9d1f02508a448e28891395d8a143f26fb88ac8c9201
04000000001976a914572265f6ea74c123d20a37fb10fb3abebb56dbf688ac39026b04000000001
976a9147487fe51c0a63ae9bb788acf7e20e04000000001976a9146ad47e26a21e5c5521b76eb11
a3378d5528a436988acf2376e04000000001976a914e971351d1df56266005b1a79cb1b91282fd2
13ae88aca141fed5b3bffd76ecc742257286befccf4a561ac6788acc68d2a05000000001976a914
6f319511eff679bf972518d810cab0532df9200388ac83df6a04000000001976a9143dfcf9866eb
d3c98b6888acc6256105000000001976a91494e5178f3cfc56b77f9f1c508b74ed9ff3b558ad88a
c11eaa404000000001976a9144ebf00154078a5ee78599adb4a82ce3b75709f5688aa91403d984b
4a0f1251370a86abb66ddaa61f67bb2bc88ac4b777807000000001976a9149465fdac29b5c47b99
c8d17379d0fc6d99c1e4a688ac849b2a08000000001976a9143f0c4ffe8626e3705ca88ac8993a8
04000000001976a914365fb3bc7793c8ffde2eccf0e0db7076a8fcc5b388ac27fb3304000000001
976a91444fae3395cdfbca7b8fcd7ab8d97f0e58bdb7beb876a9146ba1807121fdcb390db917b4c
e84b0dc8e70883e88ace0fd1c00000000001976a9145399c3093d31e4b0af4be1215d59b857b861
ad5d88ac00000000', {}]
Traceback (most recent call last):
  File "/home/bitcoinpool/eloipool/jsonrpcserver.py", line 200, in _doJSON_i
    rv = getattr(self, method)(*params)
  File "/home/bitcoinpool/eloipool/jsonrpc_getmemorypool.py", line 85, in doJSON_submitblock
    data = bytes.fromhex(data)
ValueError: non-hexadecimal number found in fromhex() arg at position 162

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
A corrected update (all able to be proven by checking git) of Luke-Jr's attempt to yet again claim other people's work as his own.
The guy is indeed scum of the earth.

CodeBFGMinercgminer
ScryptCopied, known bugsOriginal
getworkCopiedOriginal
GBTOriginalOriginal, known bugsOne reported possible bug
StratumCopied, plus many bugfixes because of problemsproblems in his clone, not cgminerOriginal
Share submission and stale detectionOriginalCopied, modified, with the share submission code recently done by Kano and ckolivas also copiedOriginal
RPC APICopied, useless "features" hiddenOriginal
Device driver interfaceOriginalCopiedOriginally committed to cgminer now much modified
BFL driverOriginalCopiedCopied, Originally committed to cgminer then heavily modified and about-to-be heavily modified again
CM1 driverOriginalCopied (and modified) from Kano's Icarus codeNon-existent
Icarus driverOriginalMostly Kano's Icarus codeCopied, heavily modified and known buggyOriginal - Xiangfu's original cgminer code heavily modified by Kano
ModMiner driverOriginalCopied, heavily modified and his cgminer version didn't even work until it was modified by Kano!
OpenCL driverCopied, with minor low-level improvementsOriginal
X6500 driverOriginalNon-existent
Ztex driverOriginalCopiedCopiedOriginal
VCOM USB interfacesOS-provided with performance problems and reported device sharing problemsCustom

Edit: and just to repeat ... the file icarus_common.h in his git that claims he wrote it all is mostly written by me and taken out of driver-icarus.c as you can prove by checking driver-icarus.c (or earlier versions depending on which git) ...

Edit2: and in case anyone was thinking that was a once off ... driver-cairnsmore.c also include some amount of code I wrote and is attributed to him in his git.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Firstly note, I'll only waste my time doing this with one source file rather than spending hours sorting through it all.
This one shows so well how much bullshit his post it.

So ... I just now git cloned his clone miner to a directory on my computer
Code:
git clone https://github.com/luke-jr/bfgminer.git

and then ran this command:
Code:
git blame driver-icarus.c | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3

and the clone result right now (that anyone can run if they like) is
Code:
      5 ckolivas   
     10 Con Kolivas
    526 Kano      
    381 Luke Dashjr
    175 Xiangfu    

and in my cgminer git
Code:
      5 ckolivas     
     18 Con Kolivas  
    698 Kano        
      8 Luke Dashjr  
      3 Paul Sheppard
    180 Xiangfu      

The main changes to the clone code he copied from me (why it says he wrote more than 8 lines in the clone, but still less than me) are CM1 code
They're not in the cgminer version, the cgminer version only supports a CM1 with an Icarus bitstream and no extra CM1 commands that aren't necessary anyway - but the work division, fpga count, baud rate and timing code necessary for the CM1 were written by me.

I'll also point out that there is a file in his git called icarus-common.h that says he wrote every line - but of course I wrote most of the code in there.
full member
Activity: 196
Merit: 100
  • There is no guarantees that the USB interface for any given FPGA/ASIC is set and unchanging. It is possible a vendor could change the USB chip in their ASIC/FPGA to another brand to avoid shipping delays, for example.

In practice, this happens approximately never.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
kanoi lulz at the amount of bullshit in the previous post ...
legendary
Activity: 2576
Merit: 1186
... and now the FPGA code has been rewritten by me using direct USB (libusb)
Yes, you've rewritten a lot (but not all) of the FPGA code in cgminer since you and con forked it from BFGMiner. However, your FUD about VCOM is just FUD (the VCOM interfaces are not "slowed down" in any way because they use standard file interfaces), and there is no reason to prefer libusb; in fact, I know of at least four reasons to prefer VCOM at this time:
  • libusb has no way to be used asynchronously on Windows; part of my original plan for ASICs was to move to a few-threaded model (BFGMiner has already a single async share submission thread) to improve scalability. I still plan to do that, but libusb-based drivers are going to force me to "hold it back" a bit.
  • VCOM has a user-friendly interface for devices: COM port numbers. This allows users to easily manage which devices are enabled or not, even if they don't have unique serial numbers (such as BFL FPGAs)
  • There is no guarantees that the USB interface for any given FPGA/ASIC is set and unchanging. It is possible a vendor could change the USB chip in their ASIC/FPGA to another brand to avoid shipping delays, for example. While there is a standard for USB VCOM interfaces (USB CDC), only the MMQ has ever used it by having a mostly-CPU-controlled USB interface on the device. All the "ready to go" USB VCOM chips use their own incompatible interfaces; your libusb-based code will fail on anything changing here!
  • VCOM drivers, at least for FTDI, are installed automatically by most operating systems. While libusb for Linux allows us to tell the OS to "steal" the device from the VCOM driver, doing so on Windows requires the user to manually change to the libusb driver.
Though I haven't updated the Icarus driver code for libusb yet, but that driver code was mostly written by xiangfu and me anyway - and even your clone CM1 driver is from the Icarus code I wrote ... and I'd not at all be surprised if the clone x6500 code is based on the ZTex code that nelisky wrote ...
While admittedly you have made some contributions to the Icarus driver, you can only claim to take as much credit as you do because you have since forked the driver originally developed by xiangfu while FPGA code was maintained by myself (thus part of what is now BFGMiner). BFGMiner's Cairnsmore1 driver is 100% my own efforts, and only "based on" your code to the extent that it doesn't conflict with it. While I have heard that Ztex and X6500 share some common logic, I am still unfortunately not familiar enough with nelisky's "libztex" code to have ensured they share common code where appropriate; instead, I implemented JTAG and FT232R bitbanging mode in their own semi-isolated modules from scratch. Perhaps someday, I will have time to integrate the Ztex driver in with these better as appropriate, but as I lack the 1.15a/b/c/d models, I am hesitant to make major internal changes I cannot test.

Clone: Stratum code, copied from cgminer, Scrypt code, copied, GPU code, copied, pool & work scheduling, copied, API, copied, Icarus, BFL, Ztex, driver code, copied. Even the code that makes the CM1 work properly, copied.
More FUD and lies again, kano? Let's try a table:
CodeBFGMinercgminer
ScryptCopied, known bugsOriginal
getworkCopiedOriginal
GBTOriginalOriginal, known bugs
StratumCopied, plus many bugfixes because of problemsOriginal
Share submission and stale detectionOriginalOriginal
RPC APICopied, useless "features" hiddenOriginal
Device driver interfaceOriginalCopied
BFL driverOriginalCopied, about-to-be heavily modified
CM1 driverOriginalNon-existent
Icarus driverOriginalCopied, heavily modified and known buggy
ModMiner driverOriginalCopied, heavily modified
OpenCL driverCopied, with minor low-level improvementsOriginal
X6500 driverOriginalNon-existent
Ztex driverOriginalCopied
VCOM USB interfacesOS-providedCustom
(Yeah, there's other stuff I left out, but I was only trying to cover the actual topics you mentioned in your FUD.)
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
So that makes BFGMiner vs CGMiner comparisons off-limits?  Inferiority complex?
Feel free to make comparisons on the BFGMiner thread.
As stated clearly above, but I guess is beyond your feeble levels of understanding, there was no comparison, only questions about your clone which has lots of old outdated code for the non-GPU parts.

Meanwhile, the GPU code is ckolivas.

... and now the FPGA code has been rewritten by me using direct USB (libusb)
Though I haven't updated the Icarus driver code for libusb yet, but that driver code was mostly written by xiangfu and me anyway - and even your clone CM1 driver is from the Icarus code I wrote ... and I'd not at all be surprised if the clone x6500 code is based on the ZTex code that nelisky wrote ...

But, the clone still uses, for most of the FPGA drivers, the old 1900's serial I/O code that Mr. Clone chose coz it was easy, not coz it was best
(though there is code in there that I wrote also to fix problems and debug serial issues)

Anyway, performance comparisons will of course be of great interest once ASIC devices come out ... Smiley
Will Mr Clone actually be able to write some original important code, or will he just copy it from cgminer like he does all the time and then fudge minor code changes and claim his clone is the original ...

Clone: Stratum code, copied from cgminer, Scrypt code, copied, GPU code, copied, pool & work scheduling, copied, API, copied, Icarus, BFL, Ztex, driver code, copied. Even the code that makes the CM1 work properly, copied.

CGMiner only original code (mostly not copied to the clone): GBT, MMQ, USB driver libraries for all but Icarus (yeah I'll get around to redoing that for Icarus one day ...)

Truly original (different) code in the clone? GBT - the currently suckyest work protocol on the planet - that still does nothing to secure anything.

I wonder what a 'current' lines of code per programmer would show with cgminer? Smiley
I've no idea how to get that accurately Tongue
GitHub doesn't even show me for some of the reports Cheesy
(yes I know why)
legendary
Activity: 2576
Merit: 1186
So that makes BFGMiner vs CGMiner comparisons off-limits?  Inferiority complex?
Feel free to make comparisons on the BFGMiner thread.
legendary
Activity: 3586
Merit: 1098
Think for yourself
So that makes BFGMiner vs CGMiner comparisons off-limits?  Inferiority complex?

How bizarre

Haven't seen any comparisons, just you asking Luke-jr questions about bgfminer.

How bizarre
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
So that makes BFGMiner vs CGMiner comparisons off-limits?  Inferiority complex?

How bizarre
legendary
Activity: 2576
Merit: 1186
does bfgminer actually restart dead gpus?
I presume so. I've never seen a dead GPU that doesn't also crash the entire system, so I'm not really sure how to test this to make sure it still works.

and i hate having to edit cfg files to fix fan speeds, what is up with the 85 max
Can you elaborate?

Any changes vs cgminer in regard to restarting GPUs?  I would say only about 1% of the time my computer also crashes on a GPU failure.  That seems to occur w/ heat issues.  I've had Windows blue screen and say something about how it was shutting down for the 'safety' of my system.  Most of the time they just blink the screen and reset.  cgminer says they're dead and it can't restart them, but it takes me about 5 seconds to press q and reload cgminer and the card starts fine.

As for the fan thing, I know that's a setting you can change in the program, I just haven't bothered.  It may be part of the 'powertune' thing.  I just opened the cfg file and changed the 0-85 to 0.

What I didn't expect was for it to put an 85% limit on my fans as part of a 'default' config.  It shouldn't mess with my clock, memory, or fan settings at all.  Just pool settings, intensity, etc.
Yes, the whole "restart dead GPUs" code has been abstracted in BFGMiner so it works for other devices (eg FPGAs) as well. If there is a problem, I'd love to make sure it gets fixed, or at least be aware of it.

If you don't use "auto-fan", BFGMiner shouldn't mess with them at all...?
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
does bfgminer actually restart dead gpus?
I presume so. I've never seen a dead GPU that doesn't also crash the entire system, so I'm not really sure how to test this to make sure it still works.

and i hate having to edit cfg files to fix fan speeds, what is up with the 85 max
Can you elaborate?

Any changes vs cgminer in regard to restarting GPUs?  I would say only about 1% of the time my computer also crashes on a GPU failure.  That seems to occur w/ heat issues.  I've had Windows blue screen and say something about how it was shutting down for the 'safety' of my system.  Most of the time they just blink the screen and reset.  cgminer says they're dead and it can't restart them, but it takes me about 5 seconds to press q and reload cgminer and the card starts fine.

As for the fan thing, I know that's a setting you can change in the program, I just haven't bothered.  It may be part of the 'powertune' thing.  I just opened the cfg file and changed the 0-85 to 0.

What I didn't expect was for it to put an 85% limit on my fans as part of a 'default' config.  It shouldn't mess with my clock, memory, or fan settings at all.  Just pool settings, intensity, etc.
Jump to: