If you set expiry too low (possibly compared to scan-time), a lot of valid work will get discarded when no-submit-stale is enabled. Make sure no-submit-stale is not turned on, and increase expiry a few seconds if you see discarded shares that occur seperate from block changes.
Thanks to you and PoolWaffle for getting back to me. I've verified that I do not have no-submit-stale specified. As long as it's off by default, then it should not be on.
Currently expiry is set to 120 and scan time is 30, which I think I saw from a GridSeed example somewhere. So expiry is quite bit higher than the scan time.
In case it helps, here's all of the options from my config (minus the pool specifications, which aren't relevant):
"failover-only": true,
"verbose": true,
"api-listen": true,
"api-port": "4028",
"expiry": "120",
"hotplug": "5",
"log": "5",
"no-pool-disable": true,
"queue": "1",
"scan-time": "30",
"scrypt": true,
"shares": "0",
Any thoughts on changes that I should make?
I keep complete logs (rotating) on my rigs. What should I look for in the logs to see if discards are happening separately from block changes?
Note that I have basically the same settings on my second rig which is made of DualMiner's (also the GridSeed chip). Not surprisingly, I see similar discard percentages with that rig.