Topic: [ANN] Stratum mining protocol - ASIC ready - page 27. (Read 146083 times)
he is asleep, but it is correct
Stratum support is now in an official cgminer release, version 2.8.0:
https://bitcointalksearch.org/topic/m.1252632
https://bitcointalksearch.org/topic/m.1252632
Awesome work ckolivas
I sent a 5btc donation from the pool, I know our miners will appreciate it when we have stratum support
Coming soontm
It was quite a bit of work...Thanks for your work ckolivas. Before I send it, please just confirm that the donation should be sent to the address in your sig: 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
Stratum support is now in an official cgminer release, version 2.8.0:
https://bitcointalksearch.org/topic/m.1252632
https://bitcointalksearch.org/topic/m.1252632
Awesome work ckolivas
I sent a 5btc donation from the pool, I know our miners will appreciate it when we have stratum support
Coming soontm
It was quite a bit of work... Stratum support is now in an official cgminer release, version 2.8.0:
https://bitcointalksearch.org/topic/m.1252632
https://bitcointalksearch.org/topic/m.1252632
Awesome work ckolivas
I sent a 5btc donation from the pool, I know our miners will appreciate it when we have stratum support
Coming soontm
Perfect!
That's excellent news! Btw did you fix that reconnection issue?
Yes it works generically by reconnecting if possible after a clear disconnection, or 2 minutes of no communication from the pool. 
cool
Cool
Stratum support is now in an official cgminer release, version 2.8.0:
https://bitcointalksearch.org/topic/m.1252632
https://bitcointalksearch.org/topic/m.1252632
Cool
That's excellent news! Btw did you fix that reconnection issue?
Stratum support is now in an official cgminer release, version 2.8.0:
https://bitcointalksearch.org/topic/m.1252632
https://bitcointalksearch.org/topic/m.1252632
I just published version 1.0.0 of proxy on github (I'll publish EXE in few days if there won't be any major bug). This version introduces "Stratum subpool" feature: now can proxy serve not only getwork jobs, but also Stratum jobs for native Stratum miners. Thanks to this, you can now point up to 256 Stratum-powered miners to Stratum proxy and it will use just one upstream connection to the pool, keeping network overhead at minimum.
Edit: Version 1.0.0 requires stratum library 0.2.7, so after "git pull" you'll need to re-run "setup.py install" or run "easy_install -U stratum".
Edit: Version 1.0.0 requires stratum library 0.2.7, so after "git pull" you'll need to re-run "setup.py install" or run "easy_install -U stratum".
In theory, shouldn't the proxy be able to relabel the header response to keep itself in the chain? (maybe make that behavior a command-line-switch?)
Ok, I will. TY
So I need a diff1 stratum connection to test if vardiff causes this difference or something else (network, etc.)
You can test it on my pool, it is still working on diff1. About that losing work - you'll probably need to discuss this with Eleuthria and ask him to check server logs.
Proxying of Stratum protocol itself isn't finished in the proxy yet. For this reason proxy simply instruct Stratum miners to connect directly to the pool. I'm working on stratum-stratum mode right now and it will be available in version 1.0.0.
Slush, I'm testing the new version of cgminer+stratum behind the proxy and I ran into an interesting question/issue.
BTCGuild returns stratum information in it's header, which the proxy passes through to cgminer. Cgminer then takes that IP and bypasses the proxy.
In theory, shouldn't the proxy be able to relabel the header response to keep itself in the chain? (maybe make that behavior a command-line-switch?)
BTCGuild returns stratum information in it's header, which the proxy passes through to cgminer. Cgminer then takes that IP and bypasses the proxy.
In theory, shouldn't the proxy be able to relabel the header response to keep itself in the chain? (maybe make that behavior a command-line-switch?)
Across an internet connection ... then I presume you are somehow forcing both pieces of data to be in a single packet?
... so it's working around a design problem by ... doing something because it's not part of the notify ...
... so it's working around a design problem by ... doing something because it's not part of the notify ...
Yes! That's what a good stratum pool will do. Again the effect result of a good implementation is the same to all miners - they don't lose credit for work they have completed.
...
Whether to include or separate mining difficulty from the notify transaction may be interesting from an academic perspective, but the real life implementation of the protocol WILL NOT result in miners loosing credit for work.
Ah so you are getting around the problem of the protocol somehow by forcing the two pieces of data to be linked?Whether to include or separate mining difficulty from the notify transaction may be interesting from an academic perspective, but the real life implementation of the protocol WILL NOT result in miners loosing credit for work.
(instead of simply having them as one piece of data)
Across an internet connection ... then I presume you are somehow forcing both pieces of data to be in a single packet?
... so it's working around a design problem by ... doing something because it's not part of the notify ...
Why not just fix notify
Oh wait ... then slush's current code would require changes ... and that's out of the question - he's at the top of the curve - though which one?
While on the subject of good code - slush are you ever going to stop prioritising higher rate hashers on LP?
What you do at the moment means that low rate hashers lose a higher % of work on an LP ... the lower the hash rate - the higher the %.
Removing 'random' from that part of the equation has that obvious effect.
Slush, I'm testing the new version of cgminer+stratum behind the proxy and I ran into an interesting question/issue.
BTCGuild returns stratum information in it's header, which the proxy passes through to cgminer. Cgminer then takes that IP and bypasses the proxy.
In theory, shouldn't the proxy be able to relabel the header response to keep itself in the chain? (maybe make that behavior a command-line-switch?)
I think this discussion is a simple misunderstanding
Difficulty not being an attribute of job definition is as the stratum protocol defines it.
However, this does not preclude a pool from tracking the difficulty associated with a job. It's up to the pool's implementation to determine how it will be handled. I suspect most pools will NOT let the miner lose credit for work created.
Whether to include or separate mining difficulty from the notify transaction may be interesting from an academic perspective, but the real life implementation of the protocol WILL NOT result in miners loosing credit for work.
Difficulty is not an attribute of job definition, which is clearly true
Difficulty not being an attribute of job definition is as the stratum protocol defines it.
However, this does not preclude a pool from tracking the difficulty associated with a job. It's up to the pool's implementation to determine how it will be handled. I suspect most pools will NOT let the miner lose credit for work created.
Whether to include or separate mining difficulty from the notify transaction may be interesting from an academic perspective, but the real life implementation of the protocol WILL NOT result in miners loosing credit for work.
Oh, this! Proxy is working in "compatibility mode" by default, to ensure that all, even very old miners, will work with it with no issues. If you have some modern miner (cgminer, poclbm or so), you can run it with --real-target. Currently the proxy is filtering low-diff shares, so you may see different numbers in the miner and on the pool. Thanks to --real-target, your numbers in miner won't be screwed anymore.
yes, I do that:
Quote
user 27107 1.6 1.3 28920 13692 ? Sl 00:42 1:06 python ./mining_proxy.py -o stratum.btcguild.com -p 9332 -rt
there is no difference, still around 5% missing (I am using some custom miner):
Example vardiff worker:
Quote
total_unsolved_gws(superK)=4640(41.46%), total_solved_gws(superK)=6552(58.54%), (solved+unsolved)=11192
Example diff1, DE server worker:
Quote
total_solved_workunits_count=30078.00
total_failed_workunits_count=16128.00
If you compute second, total_solved_workunits_count is 65% of (total_solved_workunits_count + total_failed_workunits_count)total_failed_workunits_count=16128.00
So I need a diff1 stratum connection to test if vardiff causes this difference or something else (network, etc.)
kano, how many pool software did you implement? How many of them have thousands concurrently connected clients?
I'm quite bored with arguing to you, because everytime you use some new weird arguments. Most of your comments in last message are irrelevant in some way. I'm really not going to calculate CPU cycles for you, it is simply out of scope of this discussion.
Edit:
However, if you're really interested, there's pseudocode of both solutions:
Do you see the difference?
http://www.forbes.com/sites/chrisbarth/2011/12/29/want-to-make-good-decisions-avoid-mount-stupid/
Yeah I see the difference - you lose as a programmer I'm quite bored with arguing to you, because everytime you use some new weird arguments. Most of your comments in last message are irrelevant in some way. I'm really not going to calculate CPU cycles for you, it is simply out of scope of this discussion.
Edit:
However, if you're really interested, there's pseudocode of both solutions:
Code:
for diff in waiting_notifications: # Iterates only over connections which needs new difficulty
diff.send()
job = prepare_job()
job.broadcast() # Send same packet to all connected client
Code:
for client in iterate_clients: # Iterates over all connected clients every time
job = prepare_job(client.difficulty) # Do custom serialization
job.send() # Send one packet
Do you see the difference?
http://www.forbes.com/sites/chrisbarth/2011/12/29/want-to-make-good-decisions-avoid-mount-stupid/
I've even commented on that without looking at your code.
Oh, this! Proxy is working in "compatibility mode" by default, to ensure that all, even very old miners, will work with it with no issues. If you have some modern miner (cgminer, poclbm or so), you can run it with --real-target. Currently the proxy is filtering low-diff shares, so you may see different numbers in the miner and on the pool. Thanks to --real-target, your numbers in miner won't be screwed anymore.
Jump to: