Prohashing Mining Pool Forums

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
}

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/0 ... ry-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.

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

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/0 ... ry-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: Select all

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 wrote: 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.

GenTarkin wrote:

excelerator wrote: 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.

/boot/config.txt

the URL where you can find all this info is shown in my config file above lol!

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%.

GenTarkin wrote:I wonder if I should make this an option in my firmware... hrm... ideas ... lol!