Bitcoin Forum
July 19, 2018, 04:01:31 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 [435] 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756928 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 20, 2013, 01:49:56 PM
 #8681

kanoi lulz at the amount of bullshit in the previous post ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
fair bitcoin games | pvp - pve - solo pve games | faucet |
Free satoshi code btcoon500
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1532016091
Hero Member
*
Offline Offline

Posts: 1532016091

View Profile Personal Message (Offline)

Ignore
1532016091
Reply with quote  #2

1532016091
Report to moderator
1532016091
Hero Member
*
Offline Offline

Posts: 1532016091

View Profile Personal Message (Offline)

Ignore
1532016091
Reply with quote  #2

1532016091
Report to moderator
nathanrees19
Full Member
***
Offline Offline

Activity: 196
Merit: 100



View Profile
January 20, 2013, 01:56:16 PM
 #8682

  • 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.
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 20, 2013, 02:58:28 PM
 #8683

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 21, 2013, 02:35:09 AM
 #8684

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
January 21, 2013, 04:07:03 AM
 #8685

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


crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
January 21, 2013, 04:10:53 AM
 #8686

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.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
January 21, 2013, 04:18:21 AM
 #8687

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.

kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 21, 2013, 05:43:57 AM
 #8688

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


Which is EXACTLY what I said above ... one reported possible bug ...

Yes wizkid reported it to me ... yesterday ... and as I said to him ... he needs to report it to ckolivas ... I've had almost nothing to do with the GBT code development.
wizkid also reported that it is VERY RARE ...

So how did you get that log?
Do you still have secure access to Eligius to access other peoples information? .....................................

In my testing of Stratum vs GBT the other day ... it didn't happen even once.
I've never seen it happen.
It was only first reported once yesterday ...

No doubt ckolivas will look into it when he gets back.

Edit: and I will also point out that Luke-Jr said 'bugs' not 'bug' so unless the all powerful Luke-Jr dictionary that is always correct ... even when it is wrong ... means that the definition of the word 'bugs' is singular and not plural ... where is this list of 'bugs' - I see only one that was reported for the first time yesterday ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 21, 2013, 05:47:58 AM
 #8689

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
January 21, 2013, 06:31:57 AM
 #8690

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://bitcointalk.org/index.php?topic=57437.msg685086#msg685086

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 21, 2013, 07:02:46 AM
 #8691

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

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
flatronw
Jr. Member
*
Offline Offline

Activity: 50
Merit: 0


View Profile
January 21, 2013, 08:07:17 AM
 #8692

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)
--- <exception caught here> ---
  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




kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 21, 2013, 09:19:16 AM
 #8693

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 Tongue

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
c4n10
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
January 21, 2013, 08:08:10 PM
 #8694

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...
jamesg
VIP
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000


AKA: gigavps


View Profile
January 21, 2013, 09:37:09 PM
 #8695

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

Code:
2013-01-21 16:30:15-0500 [Protocol,4,192.168.2.100] Unhandled Error
...................
stratum.custom_exceptions.ProtocolException: Cannot decode message '{"params": ["gigavps.000", "8� 0002", "H��0000", "Hh� b334", "4c39cdf0"], "id": 2320, "method": "mining.submit"}'

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

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 22, 2013, 12:25:00 AM
 #8696

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

Code:
2013-01-21 16:30:15-0500 [Protocol,4,192.168.2.100] Unhandled Error
...................
stratum.custom_exceptions.ProtocolException: Cannot decode message '{"params": ["gigavps.000", "8� 0002", "H��0000", "Hh� b334", "4c39cdf0"], "id": 2320, "method": "mining.submit"}'

Not sure what that is, but cgminer submitted it. All of the mining equipment running at the time was BFL singles or mini rigs.
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)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
ocminer
Legendary
*
Offline Offline

Activity: 2156
Merit: 1212



View Profile WWW
January 24, 2013, 08:26:57 PM
 #8697

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

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
January 24, 2013, 09:08:54 PM
 #8698

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

streetuff
Full Member
***
Offline Offline

Activity: 150
Merit: 100



View Profile
January 24, 2013, 09:10:20 PM
 #8699

go away!
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1043


Linux since 1997 RedHat 4


View Profile
January 25, 2013, 01:21:47 AM
 #8700

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
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
The whole icarus issue is not up for debate.
I've posted about it many times.
You even once offered to PAY ME, the time I had spent to find the proof, when I proved you were wrong.

Then of course there is the code line count I did recently that ALSO proves: even in your git, there is more code by me than by you.
In the cgminer git there is ALMOST NO CODE by you in the driver-icarus.c file.

As for the BFL code - well firstly there is the obvious point about why conman got involved in the BFL code.
I have posted about this in detail before also.
I asked Luke-Jr to make a change and his reply implied it was too difficult for him to do it.
I wasn't going to change it coz I wasn't interested in spending time on code that could be rejected because at that point Luke-Jr had veto over the BFL code.
So eventually conman was convinced to make the code change himself.

Luke-Jr is just a complete fucking liar and I do not understand why anyone believes a word he says.
He is trash at the highest level when it comes to trying to claim ownership of code - he wants credit for other peoples work all the time.

What the heck, I'll do a code count also based on the clone git and the cgminer git:
Code:
git blame driver-bitforce.c | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3
On the clone:
Code:
   191 Con Kolivas  
     61 Kano        
    222 Luke Dashjr  
    169 Paul Sheppard
      5 Xiangfu

And in my git - the new BFL code
Code:
   167 Con Kolivas  
    399 Kano        
    101 Luke Dashjr  
    100 Paul Sheppard

Note - I joined the two numbers together for ckolivas - he has two names in the counters that I totalled into one name.

So yes Luke wrote the biggest % of code in the old BFL driver (but not the biggest by much) - conman's rewrite code is almost as much as Luke-Jr's code (same for Paul Sheppard % also almost as high) - in the old code.
But again the reason for conman's rewrite of some of the code, that was a good performance gain, was because Luke-Jr had implied it was too difficult for him to do it.
Luke-Jr even copied ckolivas change back from cgminer to his clone as the git line counts clearly show ... and he has copied code back from my recent changes also.

His whole argument can be compared to this (that I'm sure most but the blind will see clearly):
When someone releases some code - you usually get the 'wow great' new code response from all who want it.
When the code is updated you also usually get the 'wow great' new code response from most who want the update.
Does everyone say 'wow yes I want the old original code from a year ago with bugs and problems and slower performance'? .....

Not even Luke-Jr says that - he wants the new better code from cgminer all the time - look at his latest release, how much code there is copied directly from cgminer?

However, does cgminer copy code back from Luke-Jr?
In the past 6 months we have rarely copied anything back.
We have made a lot of changes and a lot of new features wanted by many - that have been copied to the clone.

cgminer isn't a clone in any way - it is quite clearly the opposite! The clone releases, regularly contain many changes copied from cgminer.
Luke-Jr, seriously, GTFO of here.
Your lies are so damn blatantly easy to prove they are lies and so damn annoying how often you regurgitate these lies ... even here in the cgminer thread.
Go spew them to your ignorant acolytes in your clone thread - not here.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Pages: « 1 ... 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 [435] 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 ... 847 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!