The first parameter is the rest of original Stratum idea; to be universal overlay protocol with some extended publish/subscribe features. To be honest, there's still no real use for initial meaning of the first parameter and the whole idea seems to be a bit overcomplicated.
So I'm offering to change meaning of the first parameter, let's call it session_id :-). I checked all known implementations (stratum proxy, poclbm, cgminer/bfgminer) and all three seems to completely ignore the first parameter. Using first argument as session_id seems to be fully backward compatible.
Any ideas?
Topic: [ANN] Stratum mining protocol - ASIC ready - page 11. (Read 146229 times)
Basically the idea is that miner remember the last difficulty given by the previous mining session and it sends mining.suggest_difficulty(difficulty) on the beginning of the next session (it may be sent before mining.subscribe or mining.resume, but it should not be a requirement). The response to the call is irrelevant for the miner, but if the pool accept the suggestion in any way, it will send standard mining.set_difficulty with new computed difficulty.
Obviously the difficulty can differ from pool to pool while switching between backup pools, because every pool can have different SPM target . The main goal is to give at least some approximation for the newly connected pool, so it won't start with difficulty 1 for 10 THash/s monster rig...
Ok, I can easily implement this.Obviously the difficulty can differ from pool to pool while switching between backup pools, because every pool can have different SPM target . The main goal is to give at least some approximation for the newly connected pool, so it won't start with difficulty 1 for 10 THash/s monster rig...
Moving back to the resume support, since mining.resume breaks your proxy when implemented pool-side with the current format, and there will be lots of miners still using your proxy and this makes the pools not interested in supporting the feature, can I suggest a modification to a use of the mining.subscribe response?
SEND: {"id": 0, "method": "mining.subscribe", "params": []}
RECV: {"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f8019658", 4]}
Is it possible to use the existing unique subscription ID as the session ID with mining.resume instead? I know some pools use this for different reasons, so I'm not sure if that's possible, but just a suggestion. Alternatively, can you put the session ID somewhere else in the JSON response that does NOT break your proxy? While I have committed the changes to cgminer git with the existing format, there are no users currently depending on that format so we can and should change it.
However, I think simple minimum difficulty settings available through the frontend solve problems for large workers. And at least with my implementation, the pool will adjust very high speed workers to an appropriate difficulty before bandwidth becomes an issue. They'll see a spike at the very start, but with aggressive difficulty adjustments you can prevent it from being enough to saturate even on a very slow connection (3g/dial-up).
I agree that this will work, too, but it requires that user knows what's the appropriate difficulty for his miners. For the most users difficulty is simply abstract number.
In the end, pools will use some mixed solutions like
a) suggestion provided by mining software
b) minimum difficulty set by the user on pool profile
c) using higher default difficulty for unknown connections (will affect slow miners until the difficulty settle down, but it will help fast miners during startup).
Is it OK for a pool to remember a minimum diff per worker and when the worker reconnects set their diff to the remembered value?
The chain of events would be something like:
- mining.subscribe (default diff of the pool is given)
- mining.authorize (this is where the worker would be known and a remembered diff could be determined.)
- if remembered worker diff higher than default send mining.set_difficulty
Thoughts?
The chain of events would be something like:
- mining.subscribe (default diff of the pool is given)
- mining.authorize (this is where the worker would be known and a remembered diff could be determined.)
- if remembered worker diff higher than default send mining.set_difficulty
Thoughts?
That is certainly one way a pool can handle it, and one way I've been considering for BTC Guild. However, I think simple minimum difficulty settings available through the frontend solve problems for large workers. And at least with my implementation, the pool will adjust very high speed workers to an appropriate difficulty before bandwidth becomes an issue. They'll see a spike at the very start, but with aggressive difficulty adjustments you can prevent it from being enough to saturate even on a very slow connection (3g/dial-up).
I use one worker at ozcoin and it sets each rig to a unique difficulty somehow.
Stratum by definition is per-connection difficulty. gigavps's suggestion would only affect pools which try to remember/re-instate difficulty on a after worker authorization.
No, except that slow devices using the same worker name as fast ones will have huge difficulty and it will take some time to settle on natural level.
I use one worker at ozcoin and it sets each rig to a unique difficulty somehow.
No, except that slow devices using the same worker name as fast ones will have huge difficulty and it will take some time to settle on natural level.
Thoughts?
This is one of possible solutions. Unfortunately many users use one worker accross all miners, because they were lazy to set up unique worker per miner...
Does the break any of the current rules for stratum?
Thoughts?
This is one of possible solutions. Unfortunately many users use one worker accross all miners, because they were lazy to set up unique worker per miner...
Is it OK for a pool to remember a minimum diff per worker and when the worker reconnects set their diff to the remembered value?
The chain of events would be something like:
- mining.subscribe (default diff of the pool is given)
- mining.authorize (this is where the worker would be known and a remembered diff could be determined.)
- if remembered worker diff higher than default send mining.set_difficulty
Thoughts?
The chain of events would be something like:
- mining.subscribe (default diff of the pool is given)
- mining.authorize (this is where the worker would be known and a remembered diff could be determined.)
- if remembered worker diff higher than default send mining.set_difficulty
Thoughts?
Basically the idea is that miner remember the last difficulty given by the previous mining session and it sends mining.suggest_difficulty(difficulty) on the beginning of the next session (it may be sent before mining.subscribe or mining.resume, but it should not be a requirement). The response to the call is irrelevant for the miner, but if the pool accept the suggestion in any way, it will send standard mining.set_difficulty with new computed difficulty.
Obviously the difficulty can differ from pool to pool while switching between backup pools, because every pool can have different SPM target . The main goal is to give at least some approximation for the newly connected pool, so it won't start with difficulty 1 for 10 THash/s monster rig...
Obviously the difficulty can differ from pool to pool while switching between backup pools, because every pool can have different SPM target . The main goal is to give at least some approximation for the newly connected pool, so it won't start with difficulty 1 for 10 THash/s monster rig...
Would it be a suggestion that the server can take under advisement and choose to ignore?
I suggested this already, but there was almost no response by miner developers (cgminer). In oposite to mining.resume, mining.suggest is trivial to implement on pool side or it can be ignored if pool doesn't understand it.
I do see reasons to implement a difficulty setting in the miner
What are those reasons?
I had brought it up with Luke Jr. because I am mining at Eligius Diff 64 and I was having network problems. I'd be dropping to backup pool Diff 1 and then slowly climb to 64 with massive bandwidth usage in the meantime and then a while later I'd be back at Eligius at Diff 1 again with massive bandwidth usage while it made its way back to Diff 64 again. Back and forth with 168GH I was seeing the drawback to having to wait for the pool to figure out my Difficulty and I asked Luke Jr. if I could just set it myself.
Luke Jr. explained thats not possible with Stratum at this time. I have 10TH on order. If I had that hashrate at this time and I was dropping to and from backup pools it appears I would have a major problem and it would appear the pool would too.
Am I mistaken?
Would it be a suggestion that the server can take under advisement and choose to ignore?
I suggested this already, but there was almost no response by miner developers (cgminer). In oposite to mining.resume, mining.suggest is trivial to implement on pool side or it can be ignored if pool doesn't understand it.
I do see reasons to implement a difficulty setting in the miner
What are those reasons?
How would it work? Would it be a suggestion that the server can take under advisement and choose to ignore?
User defined Stratum diff is already available. So I don't see the rush to implement it into a miner.
I do see reasons to implement a difficulty setting in the miner and hope this bounces up the list of priorities for BFGMiner.
Quote
cgminer's implementation is
This unjustified assertion has no place in this thread.
Quote
Sadly, I've also found I cannot simply disable it based on client.get_version response - apparently requesting this information before initialization has completed breaks
It's normal for things to break if you hammer them with requests before initialization is finished.
Quote
The only solution I can think of to deal with this bug is to have newer clients send their version unsolicited before trying to subscribe.
This is surprisingly not a bad idea.
Quote
Another feature request (which I have to note has been specified in GBT for a year now)
There's no need to beat a dead horse here.
Quote
is the ability for miners to send a default difficulty/target to the server.
It should be up to the server to decide what rate of shares it can accept, but if an unsolicited client version is to be added, then perhaps a "suggested minimum difficulty" could be added as well.
Luke, I thought you were still using this full of bugs codebase.....?
Fixing bugs as I find them, but Eloipool still has to support cgminer for now.Luke , have you submitted a support ticket to Con, so he can help you out?
Feel free to pass it on to him. The details on the mining.resume bug lie in send() succeeding even when the packets don't actually reach their destination, and cgminer leaking the sshare object since it never gets a response.BFGMiner's codebase is too different from cgminer's in the relevant code, so if this gets fixed it can be the first cgminer-unique feature until I get a chance to write a version for BFGMiner.
Luke, I thought you were still using this full of bugs codebase.....?
Luke , have you submitted a support ticket to Con, so he can help you out?
He submitted 2 bugfixes, I took them. After that... no idea, but then I go out of my way to make myself uncontactable by him, but somehow he still gets through. I'm in a quandary here if I'm to fix bugs he reports but I don't give him a way to report them apart from random attacks on the codebase in the forum as quoted by someone else. If he could stop with the mindless attacks and other crap, I'd listen and he'd have a way, but I can't sift through his noise because it really is a mindfuck.Luke , have you submitted a support ticket to Con, so he can help you out?
I really should give up, this is doing my head in.
Luke, I thought you were still using this full of bugs codebase.....?
Luke , have you submitted a support ticket to Con, so he can help you out?
User defined Stratum diff is already available. So I don't see the rush to implement it into a miner.
Luke , have you submitted a support ticket to Con, so he can help you out?
User defined Stratum diff is already available. So I don't see the rush to implement it into a miner.
Regarding mining.resume...
The proposed mining.resume protocol breaks stratum proxy, and cgminer's implementation is full of bugs, so I've decided to put off merging it to Eloipool master for now pending some kind of revision to deal with these bugs.
Regarding client.get_version...
Sadly, I've also found I cannot simply disable it based on client.get_version response - apparently requesting this information before initialization has completed breaks cgminer.
The only solution I can think of to deal with this bug is to have newer clients send their version unsolicited before trying to subscribe.
Regarding a default difficulty request...
Another feature request (which I have to note has been specified in GBT for a year now) is the ability for miners to send a default difficulty/target to the server.
Since clients are subscribing before authorizing, there's no reliable way to abuse to username/password for this purpose.
I propose clients simply send a mining.set_difficulty to the server when they connect, before subscribing, and adopt it only if the server replies with a true result.
Thoughts on any of these?
The proposed mining.resume protocol breaks stratum proxy, and cgminer's implementation is full of bugs, so I've decided to put off merging it to Eloipool master for now pending some kind of revision to deal with these bugs.
Regarding client.get_version...
Sadly, I've also found I cannot simply disable it based on client.get_version response - apparently requesting this information before initialization has completed breaks cgminer.
The only solution I can think of to deal with this bug is to have newer clients send their version unsolicited before trying to subscribe.
Regarding a default difficulty request...
Another feature request (which I have to note has been specified in GBT for a year now) is the ability for miners to send a default difficulty/target to the server.
Since clients are subscribing before authorizing, there's no reliable way to abuse to username/password for this purpose.
I propose clients simply send a mining.set_difficulty to the server when they connect, before subscribing, and adopt it only if the server replies with a true result.
Thoughts on any of these?
I've felt that the client should send their name/version unsolicited with the initial subscription from the start. It makes sense for the client to push that data, rather than the server to ask for it explicitly. It's just a few bytes sent once.
Jump to: