Topic: SimpleVert.com: Triple merge mining, VTC/MON/PLX, 4% bonus MON + PLX - page 2. (Read 4274 times)
May 11, 2014, 03:52:36 AM
i am getting lower hash rates in this pool
May 10, 2014, 05:17:55 PM
bump
May 09, 2014, 04:30:18 PM
Triple merged mining is launched 
"
Current merged mining address: [not set]
An error occurred: list index out of range
"
...when trying to set merged mining?
thats most likely because you're using IE11. theres a known bug with that
May 09, 2014, 01:22:06 PM
Triple merged mining is launched
"
Current merged mining address: [not set]
An error occurred: list index out of range
"
...when trying to set merged mining?
May 09, 2014, 08:07:28 AM
Triple merged mining is launched
May 08, 2014, 10:52:30 AM
Do you have an ETA on PLX mining? Tossing up whether it's worth setting up a p2pool until it is. Cheers.
We'll probably have something up late tonight, no guarantees though, if we hit snags it could easily take longer.
May 08, 2014, 08:12:34 AM
Do you have an ETA on PLX mining? Tossing up whether it's worth setting up a p2pool until it is. Cheers.
May 07, 2014, 08:17:59 PM
Ohh, I forgot to mention, we're testing the patched version on our vardiff stratum if you wanna try it out its on port 3344
Just switched my 8MH/s over. Reject schema looks like it makes way more sense, and I haven't seen any uncatagorized/untracked rejects yet.The vardiff looks decent too - didn't start too low, climbing gradually/slowly, and I haven't observed any weird diff change rejects that are so common on poorly designed pools.
Rock on! And thank-you!
Edit: you still get untracked stratum shares when there is a VTC block change - would be nice to have these rejected with a proper message like "STALE-PrevHash". But that's not nearly as important.
Yup, thats still an issue, but relatively minor for sure. Just as a heads up, we're rolling back the new code temporarily, we've detected a potentially significant issue with it and will be doing more local testing before redeploying
EDIT: the upgrade is running on the main server atm, looks solid, seems to have improved efficiency noticably
May 07, 2014, 02:02:25 PM
Ohh, I forgot to mention, we're testing the patched version on our vardiff stratum if you wanna try it out its on port 3344
Just switched my 8MH/s over. Reject schema looks like it makes way more sense, and I haven't seen any uncatagorized/untracked rejects yet.The vardiff looks decent too - didn't start too low, climbing gradually/slowly, and I haven't observed any weird diff change rejects that are so common on poorly designed pools.
Rock on! And thank-you!
Edit: you still get untracked stratum shares when there is a VTC block change - would be nice to have these rejected with a proper message like "STALE-PrevHash". But that's not nearly as important.
May 07, 2014, 01:54:34 PM
Thanks for posting! We're 99% sure this is caused by the way we hacked merged mining together. The way it is currently, stratum is (improperly) requesting a work restart every time there is a change in getauxblock. We're already testing a more robust stratum server that doesn't force a work flush for merged networks. This change will probably go live sometime tonight if testing doesn't turn up many bugs
Awesome. It looks like SimpleVert might be around for a long time to come =). 1GH/s soon I think.That was what I presumed as well, that the rejects were related to MON block changes.
Ohh, I forgot to mention, we're testing the patched version on our vardiff stratum if you wanna try it out its on port 3344
May 07, 2014, 01:50:39 PM
Thanks for posting! We're 99% sure this is caused by the way we hacked merged mining together. The way it is currently, stratum is (improperly) requesting a work restart every time there is a change in getauxblock. We're already testing a more robust stratum server that doesn't force a work flush for merged networks. This change will probably go live sometime tonight if testing doesn't turn up many bugs
Awesome. It looks like SimpleVert might be around for a long time to come =). 1GH/s soon I think.That was what I presumed as well, that the rejects were related to MON block changes.
May 07, 2014, 01:47:06 PM
I am getting a lot of rejects that appear to be invalidly classified as such - I suspect this is a bug related to merge-mining.
Basically the server is requesting work restarts A LOT, and these do not coincide with VTC block changes. None of these work restarts occurred on a block change, and so the shares following them should NOT have been rejected. If these shares were high enough to be a block, they would not have been an orphan, so rejecting them is flatly incorrect. If a share is not a potential orphan block on the master chain (VTC), then it should always be a valid share (presuming it was computed correctly of course).
Please make fixing your stratum reject scheme a higher priority, and provide proper reject messages.
Basically the server is requesting work restarts A LOT, and these do not coincide with VTC block changes. None of these work restarts occurred on a block change, and so the shares following them should NOT have been rejected. If these shares were high enough to be a block, they would not have been an orphan, so rejecting them is flatly incorrect. If a share is not a potential orphan block on the master chain (VTC), then it should always be a valid share (presuming it was computed correctly of course).
Code:
[11:11:37] Stratum from MRRentals Nsc requested work restart
[11:11:37] MRRentals Nsc stale share detected, submitting as user requested
[11:11:38] Rejected untracked stratum share from MRRentals Nsc
[11:11:38] MRRentals Nsc stale share detected, submitting as user requested
[11:11:38] Rejected untracked stratum share from MRRentals Nsc
<...>
[11:11:47] Stratum from miningrigrentals Nsc requested work restart
[11:11:47] miningrigrentals Nsc stale share detected, submitting as user requested
[11:11:47] Rejected untracked stratum share from miningrigrentals Nsc
<...>
[11:12:15] Stratum from miningrigrentals Nsc requested work restart
Please make fixing your stratum reject scheme a higher priority, and provide proper reject messages.
Thanks for posting! We're 99% sure this is caused by the way we hacked merged mining together. The way it is currently, stratum is (improperly) requesting a work restart every time there is a change in getauxblock. We're already testing a more robust stratum server that doesn't force a work flush for merged networks. This change will probably go live sometime tonight if testing doesn't turn up many bugs
May 07, 2014, 01:28:44 PM
I am getting a lot of rejects that appear to be invalidly classified as such - I suspect this is a bug related to merge-mining.
Basically the server is requesting work restarts A LOT, and these do not coincide with VTC block changes. None of these work restarts occurred on a block change, and so the shares following them should NOT have been rejected. If these shares were high enough to be a block, they would not have been an orphan, so rejecting them is flatly incorrect. If a share is not a potential orphan block on the master chain (VTC), then it should always be a valid share (presuming it was computed correctly of course).
Please make fixing your stratum reject scheme a higher priority, and provide proper reject messages.
Basically the server is requesting work restarts A LOT, and these do not coincide with VTC block changes. None of these work restarts occurred on a block change, and so the shares following them should NOT have been rejected. If these shares were high enough to be a block, they would not have been an orphan, so rejecting them is flatly incorrect. If a share is not a potential orphan block on the master chain (VTC), then it should always be a valid share (presuming it was computed correctly of course).
Code:
[11:11:37] Stratum from MRRentals Nsc requested work restart
[11:11:37] MRRentals Nsc stale share detected, submitting as user requested
[11:11:38] Rejected untracked stratum share from MRRentals Nsc
[11:11:38] MRRentals Nsc stale share detected, submitting as user requested
[11:11:38] Rejected untracked stratum share from MRRentals Nsc
<...>
[11:11:47] Stratum from miningrigrentals Nsc requested work restart
[11:11:47] miningrigrentals Nsc stale share detected, submitting as user requested
[11:11:47] Rejected untracked stratum share from miningrigrentals Nsc
<...>
[11:12:15] Stratum from miningrigrentals Nsc requested work restart
Please make fixing your stratum reject scheme a higher priority, and provide proper reject messages.
Realize that with merged mining work restarts will occur when either a MON block or VTC block change happens. This is configurable on our end, but is how we're doing it at the moment. I can look into this issue more for you soon, but we haven't heard reports from other people of problems like this, so I think this may be an isolated issue with your setup.
To my knowledge (although I'm certainly not an expert) we do return proper reject messages. You can take a look at the actual stale share reject code here. A dump of actual server communications when experiencing this issue, along with what port your connected to would go a long way towards tracking down any issues you're having.
May 07, 2014, 01:21:35 PM
FYI: if you use ppagent and set
it breaks the User Stats page (internal server error).
Code:
collectors": {
"status": {
"details": false
}
}
it breaks the User Stats page (internal server error).
Thanks for the report. It's definitely true that ppagent could use some TLC, so hopefully we can do a sprint in a week or two when all this merged mining commotion is under control.
May 07, 2014, 01:15:05 PM
I am getting a lot of rejects that appear to be invalidly classified as such - I suspect this is a bug related to merge-mining.
Basically the server is requesting work restarts A LOT, and these do not coincide with VTC block changes. None of these work restarts occurred on a block change, and so the shares following them should NOT have been rejected. If these shares were high enough to be a block, they would not have been an orphan, so rejecting them is flatly incorrect. If a share is not a potential orphan block on the master chain (VTC), then it should always be a valid share (presuming it was computed correctly of course).
Please make fixing your stratum reject scheme a higher priority, and provide proper reject messages.
Basically the server is requesting work restarts A LOT, and these do not coincide with VTC block changes. None of these work restarts occurred on a block change, and so the shares following them should NOT have been rejected. If these shares were high enough to be a block, they would not have been an orphan, so rejecting them is flatly incorrect. If a share is not a potential orphan block on the master chain (VTC), then it should always be a valid share (presuming it was computed correctly of course).
Code:
[11:11:37] Stratum from MRRentals Nsc requested work restart
[11:11:37] MRRentals Nsc stale share detected, submitting as user requested
[11:11:38] Rejected untracked stratum share from MRRentals Nsc
[11:11:38] MRRentals Nsc stale share detected, submitting as user requested
[11:11:38] Rejected untracked stratum share from MRRentals Nsc
<...>
[11:11:47] Stratum from miningrigrentals Nsc requested work restart
[11:11:47] miningrigrentals Nsc stale share detected, submitting as user requested
[11:11:47] Rejected untracked stratum share from miningrigrentals Nsc
<...>
[11:12:15] Stratum from miningrigrentals Nsc requested work restart
Please make fixing your stratum reject scheme a higher priority, and provide proper reject messages.
May 07, 2014, 06:55:40 AM
FYI: if you use ppagent and set
it breaks the User Stats page (internal server error).
Code:
collectors": {
"status": {
"details": false
}
}
it breaks the User Stats page (internal server error).
May 07, 2014, 02:04:19 AM
Yea, totally possible. Its not a big priority for us atm, we're working on adding merged mining w/ PLX - I'll add an issue for it though
Keeping an eagle eye on the thread, can't wait to get into PLX.
You guys sure earn your donations. How do the 0%ers sleep at night
May 06, 2014, 11:37:27 PM
Yea, totally possible. Its not a big priority for us atm, we're working on adding merged mining w/ PLX - I'll add an issue for it though
Awesome. With merged-mined PLX and a fix for prevhash-stale rejects, this will be a seriously kick ass pool. May 06, 2014, 11:34:10 PM
Yea, totally possible. Its not a big priority for us atm, we're working on adding merged mining w/ PLX - I'll add an issue for it though
May 05, 2014, 03:58:24 PM
Is it possible to return a reject reason (e.g. Stale - previous job) for stale work, instead of bouncing them as untracked? It is rather annoying not getting per-device reject rates. Yes, this means you have to track old jobs for a period instead of clearing everytime a work flush occurs, but it makes the stratum communication a lot cleaner.
Jump to: