Read-only forum archive. PROHASHING has closed. Posting, registration, and account access are unavailable. Preserved from the April 3, 2026 server backup.

Definitive Titan Reference Configuration?

excelerator
Archived posts: 140
Joined: Dec 28, 2015

Re: Definitive Titan Reference Configuration?

by excelerator · · Post #3615

gaanthony wrote: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
}

Thanks for this! I've updated my Titans and I appreciate the time and effort you've put into researching these values.

I'm still using h=5 and one of your previous posts had you at h=10? Have you further experimented with "h="? I've stopped as this result works really well with rejects well under 1%.
Last edited Sat Jul 09, 2016 07:05 PM UTC by excelerator; edited 1 time(s).
GenTarkin
Archived posts: 135
Joined: Dec 02, 2015

Re: Definitive Titan Reference Configuration?

by GenTarkin · · Post #3616

gaanthony wrote:Since the discussion has been on optimizing Titan miners I've looked into other places to optimize: Network that I control and the Raspberry Pi controller.
I run OpenWrt Chaos Calmer 15.05 on my routers. I added Smart Queue Management to OpenWrt on my router following information in this link http://fixmynix.com/openwrt-qos-settings-luci-app-sqm/ and it improved hash rash slightly and smoothed out network performance in/outbound.
Next I looked to the Rasberry Pi. I performed a couple of tweaks with disabling logging, enabling ram disk, and overclocking to medium per steps at this blog http://linuxonflash.blogspot.com/2015/02/optimizing-performance-on-raspberry-pi.html.
So far pool rejects are <1% and hash rate seems to be more steady and slightly higher.
Overclocking increases heat load on the Pi and can shorten life without the needed cooling or heat sinks.
Will see what long term running brings.
Proceed at your own risk.
My pi is set to this for clocks:

Code:

kernel=kernel.img

gpu_mem=16

# for more options see http://elinux.org/RPi_config.txt
arm_freq=1000
core_freq=400
sdram_freq=500
over_voltage=5
force_turbo=1
temp_limit=85
stable and no hs required. Also, the cpu is no longer pegged 90% of the time by Titan / mining, probably only 30-40% of the time now.


Furthermore, I have h=4 and rejects are under 1%, avg hashrate @ 349.8mh over 71hrs
excelerator
Archived posts: 140
Joined: Dec 28, 2015

Re: Definitive Titan Reference Configuration?

by excelerator · · Post #3617

GenTarkin wrote:
gaanthony wrote:Since the discussion has been on optimizing Titan miners I've looked into other places to optimize: Network that I control and the Raspberry Pi controller.
I run OpenWrt Chaos Calmer 15.05 on my routers. I added Smart Queue Management to OpenWrt on my router following information in this link http://fixmynix.com/openwrt-qos-settings-luci-app-sqm/ and it improved hash rash slightly and smoothed out network performance in/outbound.
Next I looked to the Rasberry Pi. I performed a couple of tweaks with disabling logging, enabling ram disk, and overclocking to medium per steps at this blog http://linuxonflash.blogspot.com/2015/02/optimizing-performance-on-raspberry-pi.html.
So far pool rejects are <1% and hash rate seems to be more steady and slightly higher.
Overclocking increases heat load on the Pi and can shorten life without the needed cooling or heat sinks.
Will see what long term running brings.
Proceed at your own risk.
My pi is set to this for clocks:

Code:

kernel=kernel.img

gpu_mem=16

# for more options see http://elinux.org/RPi_config.txt
arm_freq=1000
core_freq=400
sdram_freq=500
over_voltage=5
force_turbo=1
temp_limit=85
stable and no hs required. Also, the cpu is no longer pegged 90% of the time by Titan / mining, probably only 30-40% of the time now.


Furthermore, I have h=4 and rejects are under 1%, avg hashrate @ 349.8mh over 71hrs
What directory and filename is this on the Titan RPi for changing the clock speeds? I've SSH'd in but am struggling to find the file.
gaanthony
Archived posts: 77
Joined: Feb 02, 2016

Re: Definitive Titan Reference Configuration?

by gaanthony · · Post #3626

excelerator wrote:
gaanthony wrote: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
}

Thanks for this! I've updated my Titans and I appreciate the time and effort you've put into researching these values.

I'm still using h=5 and one of your previous posts had you at h=10? Have you further experimented with "h="? I've stopped as this result works really well with rejects well under 1%.
I've dropped back to h=5 and now trying h=3.

With the no-show-processors, quiet, and compact settings above you do not get a BFGMINER screen display when you SSH and run screen -dr as it's turned off but you can press M to reach the CPU menu and then arrow key up/down to see ASICs 0 through however many you have. Remember there are 4 dies per ASIC and 0 will equal 2 in the Web GUI on the Advanced Settings page.
If you have hardware errors on a die you can bump voltage up to reduce them or no errors you can bump it down until you see errors and then raise it back up. This helps to tweak the error rate on the main GUI Status page.