Bitcoin Forum
December 06, 2016, 07:58:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4820076 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.
Mobius
Hero Member
*****
Offline Offline

Activity: 957



View Profile
November 25, 2012, 05:13:37 AM
 #8161

The semi-official Bitcoin Pool Comparison Chart only shows 2 stratum pools, BTCGuild and Slush's.  Are there others?
Most pools are in the process of implementing it. Of the other ones that already have it, ozcoin is my favourite, but emc also does it (though with too unstable a variable difficulty IMO).

Come on now, lets be honest.  The variable difficulty isn't the problem here, Stratum is the problem: it's difficulty to work relation is broken from the ground up and needs to be fixed.  If the difficulty were too unstable, why can GW and GBT keep up just fine?  CGminer doesn't seem to have any trouble keeping up with it in GW, right?



Seems to be your implementation of variable difficulty with stratum. It works fine on all the other implementations that were not influenced by GBT.
1481054285
Hero Member
*
Offline Offline

Posts: 1481054285

View Profile Personal Message (Offline)

Ignore
1481054285
Reply with quote  #2

1481054285
Report to moderator
1481054285
Hero Member
*
Offline Offline

Posts: 1481054285

View Profile Personal Message (Offline)

Ignore
1481054285
Reply with quote  #2

1481054285
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481054285
Hero Member
*
Offline Offline

Posts: 1481054285

View Profile Personal Message (Offline)

Ignore
1481054285
Reply with quote  #2

1481054285
Report to moderator
1481054285
Hero Member
*
Offline Offline

Posts: 1481054285

View Profile Personal Message (Offline)

Ignore
1481054285
Reply with quote  #2

1481054285
Report to moderator
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 25, 2012, 05:25:56 AM
 #8162

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right because of the flawed difficulty design of Stratum.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?


If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 25, 2012, 05:27:43 AM
 #8163

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?


Excuse me but 99.99% of the stratum code in bfgminer is from cgminer

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 25, 2012, 05:29:13 AM
 #8164

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?


Excuse me but 99.99% of the stratum code in bfgminer is from cgminer

I'm not sure what that has to do with the fact that it works though? The problem is not with the Stratum code, it's with the Stratum protocol.  It's broken.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 25, 2012, 05:30:28 AM
 #8165

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
Excuse me but 99.99% of the stratum code in bfgminer is from cgminer
Yes, but as with other code that BFGMiner inherited from cgminer, I've fixed numerous bugs in it.

Mobius
Hero Member
*****
Offline Offline

Activity: 957



View Profile
November 25, 2012, 05:38:53 AM
 #8166

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right because of the flawed difficulty design of Stratum.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right because of the flawed difficulty design of Stratum.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?

"Acknowledged" by whom?
who specifically is "everyone involved"?

My personal mining numbers show the opposite as shown on the pools actual websites. The only magical POOF I'm seeing is the end of that cool aid you've been sipping on.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 25, 2012, 05:44:07 AM
 #8167

"Everone invloved" would be Conman, Kano, Luke, Slush, myself and pretty much anyone who has anything to do with development and implementation of Stratum.  What is your authority to make a claim?

Of course you aren't seeing the poof, because it shows up as a rejected share when it shouldn't be.  But how would you know?

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
November 25, 2012, 05:57:03 AM
 #8168

"Acknowledged" by whom?
who specifically is "everyone involved"?

My personal mining numbers show the opposite as shown on the pools actual websites. The only magical POOF I'm seeing is the end of that cool aid you've been sipping on.
Read thru this thread: https://bitcointalk.org/index.php?topic=108533.0

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 25, 2012, 06:01:56 AM
 #8169

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
Excuse me but 99.99% of the stratum code in bfgminer is from cgminer
Yes, but as with other code that BFGMiner inherited from cgminer, I've caused numerous bugs in the minor changes I've made.
You see - that's the correct version.

Please at least understand what you are talking about before making ludicrous posts that show how stupid you are.

This is the third time in here recently you've made posts that make you seem like a simpleton.
Here's two more:
https://bitcointalk.org/index.php?topic=28402.msg1342045#msg1342045
https://bitcointalk.org/index.php?topic=28402.msg1349309#msg1349309

You just post crap and never back up anything you say - and it is simply that - crap.
Coz you can't back it up.

There is a known issue with Stratum (that I brought up) that if you change difficulty, then the miner will lose a very small number of shares.
If you change it often, then of course that number increases.
Yes, this is my main issue with Stratum that I have brought up all over the place - feel free to copy me and help me get slush to accept the change.
But while your at it - at least understand what the fuck you are talking about Tongue

When I mine on OzCoin with Stratum I set difficulty fixed at 8 diff so there are no difficulty changes.
Works well.
Some days I only get a single Reject in 24 hours ...

--

There are also well known issues with GBT that you have been clearly explained.
Go fix them.
But no, your head is so far up your arse you don't hear anything anyone says.

Seriously (as I have said before) I wouldn't mind if there were 2 new competing protocols.
But at the moment there aren't - there's only one: Stratum - the other one is not worth considering.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 25, 2012, 06:45:32 AM
 #8170

To be clear, again I agree difficulty should be tied in with work on stratum instead of the current implementation. However pools can do a lot to alleviating the harm that has by tolerating a certain amount of hysteresis before retargetting diff. I'm sure emc can be tweaked some more with this in mind.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 25, 2012, 12:01:49 PM
 #8171

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

Inaba, why so aggressive? I never meet you on #stratum channel, so I'm bit surprised with your sudden interest in "proper design" of the protocol.

Did you read https://bitcointalk.org/index.php?topic=108533.msg1344456#msg1344456 ? AFAIK it fixes all previous problems with difficulty manipulation. I also didn't read any opinion to this by you, so I suppose you agree on this change. All existing miner software (cgminer, poclbm, proxy, I expect that bfgminer as well as it is derived from cgminer) is already compatible with this change, so feel free to implement it on your pool.

I only need to change documentation to cover this change. If we ever have days with 25 hours...

PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
November 25, 2012, 12:46:22 PM
 #8172

So yeah, great miner guys, but there still seems to be some compatibility issues that need to be ironed out as far as the windoze side is concerned me thinks, but I don't blame you for not bothering too much about it, seeing as we all love windows so much.
Well... I actually have busted my balls for months on end trying to sort out the windows issues, so that is a slight understatement saying "not bothering much"  Roll Eyes
 Enjoy anyway.

Of course, I realize that and appreciate all your hard work greatly - it was a very tongue in cheek comment, text can come across very blatant & uncaring sometimes - especially when I write it...... Shocked

All good, and thanks again. Now that I'm mining properly again I'll make a wee donation - my first incoming will be yours my man. Grin

First incoming donated as promised. It ain't much, as I've only got a small setup - but it's the thought that counts eh?

Thanks again for all your work on this, great stuff.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 25, 2012, 04:28:29 PM
 #8173

con, have u ever considered using a PPA?  would help simpletons on ubuntu like me.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 25, 2012, 04:52:51 PM
 #8174

No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

Inaba, why so aggressive? I never meet you on #stratum channel, so I'm bit surprised with your sudden interest in "proper design" of the protocol.

Did you read https://bitcointalk.org/index.php?topic=108533.msg1344456#msg1344456 ? AFAIK it fixes all previous problems with difficulty manipulation. I also didn't read any opinion to this by you, so I suppose you agree on this change. All existing miner software (cgminer, poclbm, proxy, I expect that bfgminer as well as it is derived from cgminer) is already compatible with this change, so feel free to implement it on your pool.

I only need to change documentation to cover this change. If we ever have days with 25 hours...

With regards to being aggressive, I am irritated with the Stratum protocol in general.  It was developed in secret and foisted upon the mining world as the second coming of mining.  That's all well and good, but it was flawed and basically every single problem we've run into so far with it would have been fixed if it was developed in the open with input from the pool operators.  Instead, I'm stuck having to implement a broken protocol and make changes/fixes as the protocol is fixed in a manner that should have happened from the start... so yes, it's very irritating.  But what's done is done and I have not posted much in that thread because there's no sense in bitching about it; it is what it is.

Personally, I don't care what solution I use to solve the problems my pool is facing, so long as it works and doesn't cause problems down the road like GW has (but who can blame Tycho et al for GW since nobody really saw this scale of mining back then).  I digress... the current implementation other pools (IE - pools that are not EMC) have with Stratum is the hysterisis methods being employed are there to fix the (former?) problem with Stratum decoupling the difficulty from the work.  There is absolutely no compelling reason to make a large window of fluctuating difficulty, other than the fact that if you don't (on Stratum) shares are incorrectly discarded.  It's not like it requires a large amount of additional work on the miner end to have difficulty changing with every submission or anything.  Additionally, changing difficulty more often alleviates future problems with fluctuating hashrates. 

That said, it's something I wanted to bring up at some point:  I don't think you (Slush) or any of the other pool ops quite understand what's about to happen with regards to ASICs.  With these large difficulty windows, you are going to get flooded with shares as large scale miners come on and offline.  Even with Gen1 ASICs, the problem is going to be a bit pronounced on the larger pools as multi terahash miners come and go.  With Gen2, Gen3, and so on into the future, the problem will only magnify to unmanageable levels.  Waiting to change difficulty for longer than is necessary will only serve to flood your server with unnecessary work returns, increasing your load and potential points of failure.  Stop and consider what happens when 250 TH across 20 workers decides to hop on and off your pool... or even better yet, what if you get someone in control of 500 TH that decides to screw with your pool by hopping on and off your pool in a manner that will keep the difficulty lower than it should be?  This is going to be a problem, either through malicious acts or through random chance - it's why I do not allow user selected difficulty on EMC and why I have difficulty changing fairly rapidly.  I don't want to get DoS'd either through intention or not simply because I have 500 TH submitting difficulty 32 shares for 5 minutes before they get bumped up, rinse and repeat.  There is no drawback to rapid difficulty change in the ASIC era, and artificially limiting that to accommodate a problem with the protocol instead of fixing the protocol is backwards thinking.

I'll review the changes you mentioned... from a cursory glance, it doesn't seem to address what happens when a worker submits a share from a previous work block that had a lower difficulty or does it?  Your post is a little unclear on that, so if you could clarify that, it would help and I will work to get that incorporated in EMC. 

Assuming that addresses the fundamental issue of a miner submitting a lower difficulty share that is still valid after the difficulty has increased, does that address the problems CGMiner is having with EMC and it's rapid difficulty changes, Con?   If not, can you elaborate on exactly what the problem is with CGMiner and EMC over Stratum?



If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 25, 2012, 08:24:41 PM
 #8175

It was developed in secret and foisted upon the mining world as the second coming of mining.

Fuck off. I'm impatiently waiting to your open initiative for ASIC device-level protocol. I don't believe that somebody with your attitude is preparing proprietary protocol which must be adopted by the community to use your miners.

Quote
That's all well and good, but it was flawed and basically every single problem we've run into so far with it would have been fixed if it was developed in the open with input from the pool operators.

I'm also impatiently waiting to your open proposal for mining protocol which will be superior to Stratum. I implemented the protocol which fits my needs. I don't keep gun to any poolop's head to support Stratum as well. If you don't like Stratum, stay away from it.

I cannot resist your arrogant style. But fine, I'm calming down and I'll try to be constructive now...

Quote
Personally, I don't care what solution I use to solve the problems my pool is facing

Pretty vague sentence. Can you be more specific? Why you didn't report your problems?

Quote
There is absolutely no compelling reason to make a large window of fluctuating difficulty, other than the fact that if you don't (on Stratum) shares are incorrectly discarded.

I don't believe you wrote such long post before you even read my post addressing this issue. Btw protocol don't define *any* window, it's up to server side implementation.

Quote
I don't think you (Slush) or any of the other pool ops quite understand what's about to happen with regards to ASICs.

I think that I understand it pretty good. Any evidence for your claim? Can you elaborate more on Stratum bottlenecks regards to ASICs and what's your solution then?

Quote
 With these large difficulty windows

Large difficulty windows are in your head, not in the protocol. Protocol don't care about any windows, pool can enforce difficulty every second. It is completely up to pool implementation and there are NO limits defined in the protocol in this area.

Quote
Waiting to change difficulty for longer than is necessary will only serve to flood your server with unnecessary work returns

How is this liimited by the protocol? For example, my vardiff code is rising the difficulty pretty aggressive and in the near future, pool even won't use diff1 on the beginning of the connection. Slower miners will wait a moment until the difficulty settle to lower values. Mining on diff1 is going to die in very near future anyway, I believe that default connection difficulty will skyrocket in few months.

Quote
Stop and consider what happens when 250 TH across 20 workers decides to hop on and off your pool...

Hm, still don't understand how this is related to the protocol and not to the pool implementation. Can you elaborate a bit more? I'm affraid you're mixing together possible problems of miner implementation, server implementation and the protocol...

Quote
what if you get someone in control of 500 TH that decides to screw with your pool by hopping on and off your pool

There're much simpler solutions how to DoS the pool, than hoping with real 500 TH/s. But fine, every solution which will save pool from overloading is welcome. What's yours proposal?

Quote
it's why I do not allow user selected difficulty on EMC and why I have difficulty changing fairly rapidly.

Exactly my solution. Again, clearly possible with Stratum.

Quote
from a cursory glance, it doesn't seem to address what happens when a worker submits a share from a previous work block that had a lower difficulty or does it?

Correct, it doesn't address submitting old shares. AFAIK there's no easy solution how to check if the share has good difficulty until you validate it on the server. What's your proposal here? Even banning the IP won't solve the problem, it only saves a bit of pool CPU time, but validating the share is quite cheap anyway...

Inaba, I ask you to calm down your tone. If you have any problems with the solution, you can report them and offer the solution in inteligent way.

DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
November 25, 2012, 09:08:15 PM
 #8176

Trying to implement Stratum on my pool, but cgminer crashes when I connect to the server.

This is what happens, from the server perspective:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","1"],"",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Then Windows says "cgminer.exe has stopped working"

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 25, 2012, 09:12:18 PM
 #8177

Trying to implement Stratum on my pool, but cgminer crashes when I connect to the server.

This is what happens, from the server perspective:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","1"],"",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Then Windows says "cgminer.exe has stopped working"

See Eleuthria's cheat sheet:
https://www.btcguild.com/new_protocol.php

You're sending a zero sized  string for extranonce1

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
November 25, 2012, 09:32:42 PM
 #8178

You're sending a zero sized  string for extranonce1

I thought that was allowed. Anyway it doesn't help changing that:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Still crash.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 25, 2012, 09:36:20 PM
 #8179

Fuck Off, really?  That's where we are at now?

Quote
I'm impatiently waiting to your open initiative for ASIC device-level protocol. I don't believe that somebody with your attitude is preparing proprietary protocol which must be adopted by the community to use your miners.

You're absolutely right I'm not preparing a proprietary protocol!  I am 100% against doing so, which is what you did and then "opened it up" to the community.  That's what irritates me, but it's a minor irritation which is why I've not made a big long posts about it.  I'm sure you had your reasons and as I said, what's done is done.

Quote
I'm also impatiently waiting to your open proposal for mining protocol which will be superior to Stratum. I implemented the protocol which fits my needs. I don't keep gun to any poolop's head to support Stratum as well. If you don't like Stratum, stay away from it.

Why are you waiting for my proposal if you already have one that fits your needs?  That doesn't even make sense!

Quote
Pretty vague sentence. Can you be more specific? Why you didn't report your problems?

I did (https://bitcointalk.org/index.php?topic=108533.msg1344256#msg1344256).  You did not respond, so what do you want me to do, pitch a fit in the thread?

Quote
don't believe you wrote such long post before you even read my post addressing this issue. Btw protocol don't define *any* window, it's up to server side implementation.

I don't know what you mean by this so it's hard to respond.  Ok, the protocol doesn't define a window, fair enough.  However, because the protocol fails to tie the difficulty to the work, some pools are putting in a window to fix the broken protocol and solve an issue that should not even be an issue.  If the difficulty were tied to the work, as it should be, it would be completely irrelevant when the share is sent back (so long as it's not expired) when viewed in relation to the current work being sent out at a higher difficulty.  

From your responses in that thread, you seem to think it is ok to discard valid work simply because the difficulty rises in the middle of a nonce.  That is basically robbing the miners of valid work and it's not something I am willing to do to my miners.  Yes, absolutely, I agree that it's a very small amount of shares, but the cumulative discards of perfectly valid shares is not insubstantial.  And this is all because difficulty is not tied to work.  Tie difficulty to work and this problem goes away.

Quote
I think that I understand it pretty good. Any evidence for your claim? Can you elaborate more on Stratum bottlenecks regards to ASICs and what's your solution then?

I did not say there were any bottlenecks in Stratum, but your response further lends credence to the fact that I don't think you understand the scale of what is about to be unleashed upon the mining world.  You are still thinking in the old mining terms were 100 TH is virtually inconceivable (Given that the whole network is a fraction of that right now).  Within less than a year, 100 TH will be well within the reach of modest professional miners and I will not be surprised to see the largest miners wielding a significant fraction of a PH.  But this isn't really a Stratum issue, beyond the fact that the discarded shares will scale in a linear fashion with the hashrate and miners will be losing a non-trivial amount of shares for no reason when mining with Stratum on current implementations.

Quote
Large difficulty windows are in your head, not in the protocol. Protocol don't care about any windows, pool can enforce difficulty every second. It is completely up to pool implementation and there are NO limits defined in the protocol in this area.

See above.  The difficulty windows are in response to fact that Stratum does not properly tie difficulty to work.

Quote
How is this liimited by the protocol? For example, my vardiff code is rising the difficulty pretty aggressive and in the near future, pool even won't use diff1 on the beginning of the connection. Slower miners will wait a moment until the difficulty settle to lower values. Mining on diff1 is going to die in very near future anyway, I believe that default connection difficulty will skyrocket in few months.

Again, see above. To overcome the flaw in the protocol, apparently the solution BTCGuild and OzCoin have come up with is to make a large hysteresis window to prevent frequent difficulty changes and to minimize the impact of lost shares.  That's a kludge to fix a problem that shouldn't exist, which is directly caused by the protocol specification.

Quote
Exactly my solution. Again, clearly possible with Stratum.

Ok, fair enough.  Maybe Con can chime in then and tell me what the difference is between EMC and Slush's pool as viewed by CGMiner?  All this is ultimately due to CGMiner apparently having trouble with EMC because the difficulty changes too rapidly - but if that's the case, wouldn't the same problem be evident on Slush's pool?  If not, why not?  I'll be glad to fix it if there's a problem somewhere.

Quote
Correct, it doesn't address submitting old shares. AFAIK there's no easy solution how to check if the share has good difficulty until you validate it on the server. What's your proposal here? Even banning the IP won't solve the problem, it only saves a bit of pool CPU time, but validating the share is quite cheap anyway...

What?  Of course there is!  Tie difficulty to the work sent out.  When the work is returned, compare it to the difficulty sent out, if it's under the target you're good to go, if not, reject it.  Simple, easy, obvious and straight forward.  I know you are aware of this, since it's been brought to your attention several times by several different people.  So I'm confused on what you are trying to say here?

Quote
Inaba, I ask you to calm down your tone. If you have any problems with the solution, you can report them and offer the solution in inteligent way.

Umm, my tone?  What are you talking about?  I made a comment in this thread, about CGMiner, explaining why Stratum is not correct and you come back at me with Fuck Off because I answered your question.  The problem with Stratum has already been beat to death in the other thread, so why should I go there and beat that dead horse again?  You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times.  





If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 25, 2012, 09:37:33 PM
 #8180

You're sending a zero sized  string for extranonce1

I thought that was allowed. Anyway it doesn't help changing that:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Still crash.

Oh sorry. Send your first set of parameters for mining.notify before sending the ack for mining.authorize.

Something like
Code:
Server: {"params": ["bf", "4d16b6f85af6e2198f44ae2a6de67f78487ae5611b77c6c0440b921e00000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff20020862062f503253482f04b8864e5008",
"072f736c7573682f000000000100f2052a010000001976a914d23fcdf86f7e756a64a7a9688ef9903327048ed988ac00000000",
["c5bd77249e27c2d3a3602dd35c3364a7983900b64a34644d03b930bfdb19c0e5","049b4e78e2d0b24f7c6a2856aa7b41811ed961ee52ae75527df9e80043fd2f12"],
"00000002", "1c2ac4af", "504e86b9", false], "id": null, "method": "mining.notify"}\n
Server: {"error": null, "id": 1, "result": true}\n


Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 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 ... 830 »
  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!