Definitive Titan Reference Configuration?

I'm really enjoying mining at Prohashing, but the reduced hashrate (compared to Nicehash) is very dramatic and through extensive testing over weeks, even with the higher payout/MH at Prohashing, it doesn't compensate for lost earnings due to the overall reduced hash rate. I'm seeing a consistent 10-15% lower hashrate at Prohashing vs Nicehash, I've followed the help section with xnsub, skipbcheck, scan-time, etc and I just can't get the hash rate higher. I truly believe this is the best pool out there, so am hoping that other Titan owners might we willing to share their "Manual File Configuration Editor" values and we can collectively come up with the definitive Titan reference setup for Prohashing instead of bits and pieces of advice within the forum. Are people comfortable with this idea, or am I being naive, as owners want to protect this for competitive advantage (a position I can respect). Here's my setup if anyone finds it useful.

{
"pools": [
{
"url": "stratum+tcp://us-west01.miningrigrentals.com:3333/#xnsub#skipcbcheck",
"user": "excelerator.27361",
"pass": "x"
},
{
"url": "stratum+tcp://us-central01.miningrigrentals.com:3333/#xnsub#skipcbcheck",
"user": "excelerator.27361",
"pass": "x"
},
],
"scrypt-n": 10,
"failover-only": true,
"scan-time": "1"
}

That looks fairly close to what I'm using, with 3 differences I see that might be impacting your hashrate. Here's my config file: First, you're not submitting stale shares, which you should do here, as you're paid for them. 2nd, you're specifying a scan time of 1, and I'm not sure if that is having an impact on your hashrate or not. Lastly, the #xnsub argument might be having an effect; I don't know if it's used here, but I doubt it. Chris or Steve- correct me if I'm wrong on that point. Try setting no-submit-stale to false, and removing the scantime and #xnsub modifiers, and see what effect, if any, that has on your hashrate. I hope this helps.

Thanks Kires - I've updated all my controllers with the "no-submit-stale": false instruction.

I'm looking forward to feedback on xnsub and especially scan-time - I'm wondering if the quotes around the "1" might also be a problem (makes it a text string instead of integer).

When I get home from work, I can give more detail about the rest, but for now I'll say that not submitting stale shares will lower profitability by several percentage points.

There are two reasons. First, we build upon orphaned blocks, so "stale" shares can revert to being in the longest chain in many cases. Second, merge mining allows parts of the share to be stale while the rest is still worth something. Even if the primary coin is stale, you can still almost always be paid at the dogecoin rate for a stale share.

I'll reply more later.

Adding the "no-submit-stale": false instruction worked demonstrably well yesterday! Thank you both Kires and Steve.

Now onto xnsub and the correct syntax for scan-time...

Steve,

How do we go about reviving this thread and creating the definitive setup guide for Titans? You're in the central position to accumulate the collective knowledge and publish. I'm certain all of us Titan owners will contribute. Titan owners can make an enormous difference in the pool hash rate if we can either receive, or collectively produce, a reference setup guide. I can see the potential of this pool and am prepared to help but I believe this needs to be a community effort. I'm happy to publish all my setup information if we have a structured way to do this and share it all out.

I'm not sure where you're at with selfish mining, but if we can get a rock solid reference setup, won't that help with using the orphan blocks to your advantage?

Thanks

This is what I run with:

{
"pools": [
{
"url": "stratum+tcp://prohashing.com:3333/#xnsub#skipcbcheck",
"user": "<username>",
"pass": "n=<minername>"
},
{
<backup pool entry>
}
],
"scrypt-n": 10,
"queue": "0",
"scan-time": "1",
"expiry": "1",
"no-longpoll": false,
"expiry-lp": "1",
"skip-security-checks": "0",
"no-unicode": true,
"retries": -1,
"no-submit-stale": false,
"no-show-processors": true,
"failover-only": true,
"quiet": true,
"compact": true,
"net-delay": false
}

excelerator wrote:Steve,

How do we go about reviving this thread and creating the definitive setup guide for Titans? You're in the central position to accumulate the collective knowledge and publish. I'm certain all of us Titan owners will contribute. Titan owners can make an enormous difference in the pool hash rate if we can either receive, or collectively produce, a reference setup guide. I can see the potential of this pool and am prepared to help but I believe this needs to be a community effort. I'm happy to publish all my setup information if we have a structured way to do this and share it all out.

I'm not sure where you're at with selfish mining, but if we can get a rock solid reference setup, won't that help with using the orphan blocks to your advantage?

Thanks

Chris has found that Titans seem to have a "spin up" period, which differs from other types of miners. They have 25% of their hashrate at 1s after restart, 50% 2s after, and so on. Other miners have either zero hashrate or 100% hashrate at any given time after restart.

One of the solutions we think will improve Titan performance is to set the "h=" password parameter. This parameter sets a minimum network difficulty, which will cause the Titans to only mine difficult coins. That might decrease your profitability a bit, but will still come out over litecoin.

Try using different numbers and seeing what happens. Start at h=20, for example. Once we can prove that Titans hash efficiently with the parameter, then I think it should be easy to create a guide. The goal would be to determine the lowest value of h that will work.

on it now

I've been experimenting around and found that at h=10 it selects other coins other than LTC & the occasional Megacoin.

Does your switching take into account both revenue/block & difficulty? I'm seeing high difficulty and lower value coins found so it seems that high difficulty may not be sufficient to beat the daily LTC average. If you are taking both into account, then I'm setting the 'h=" value too low and need to increase it.