Consider changing --scan-time, --expiry, --queue about sgminer HOT 7 CLOSED

It's now set to

int opt_scantime = -1;
int opt_expiry = 120;

Expiry should probably be lowered 4 times (block speed ratio of Litecoin/Bitcoin). Scantime is a very safe default.

from sgminer.

So the default expiry should probably be 30?

What does scantime -1 mean?

from sgminer.

Looks like queue is also a parameter that should be reconsidered for scrypt coins.

from sgminer.

What does scantime -1 mean?

Good question.

I'd assumed it means there is no time limit (unless the signed integer overflows), but main.c has this:

/* Use a shorter scantime for scrypt (SHA256d had 60) */
if (opt_scantime < 0)
    opt_scantime = 30;

So "-1" effectively translates to "30", which is confusing.

from sgminer.

Changed scantime/expiry to 10/30. Queue remains unchanged. Needs testing.

from sgminer.

I'll change mine to those defaults and monitor rejects and WU

from sgminer.

Ratio 1:4 at 7/28 seems to work best.

Source - IRC log:

02:03 < MissedOutOnBTC_> alright, well last night I was talking to veox about scan-time and expiry settings
02:03 < MissedOutOnBTC_> and I did a bunch of testing last night
02:03 < MissedOutOnBTC_> the default settings are 30 for scan-time and 120 for expiry, which is optimized for Bitcoin's long block times
02:04 < martinium> yeah I remember when you guys were discussing it
02:04 < MissedOutOnBTC_> I have been hunting down better settings for faster coins, everything from LTC's 2.5 minute block time to Digitalcoin's 40 second block time
02:05 < MissedOutOnBTC_> by using the 1:4 ratio that Bitcoin already set in place, I played around with lower number in the same ratio
02:05 < MissedOutOnBTC_> when I used 2/8 I went an hour and a half of mining LTC with zero rejected shares
02:05 < MissedOutOnBTC_> but as a side effect, my estimated hashrate on the pool was lower than usual
02:06 < billybigrigger> but 0 stales
02:06 < MissedOutOnBTC_> probably because it was submitting fewer shares overall, it might have been abandoning good shares too early (but not counting them as rejected) or maybe not finding new work when it should be
02:06 < MissedOutOnBTC_> so I started raising the values
02:07 < MissedOutOnBTC_> at 7/28 I was getting around 0.4% rejected shares on LTC, and my hashrate estimation was back to normal
02:08 < MissedOutOnBTC_> then, on a fast coin like Digitalcoin with 40 second block times, 7/28 also gave me 0.4% rejected shares
02:08 < MissedOutOnBTC_> again, full hashrate estimation on the pool
02:09 < martinium> very low rejects
02:10 < martinium> that should be very useful
02:10 < MissedOutOnBTC_> astoundingly low, in fact I'm rounding up to 0.4%
02:10 < martinium> i'm guessing with the other timings the shares are like in a queue and the oldest become to old and get rejected but this widens the tunnel
02:11 < martinium> so more can fit making the miner more efficient
02:11 < MissedOutOnBTC_> yeah, there is also a queue option that I briefly experimented with, but so far I have either had the same or worse performance if I strayed away from the default of 1
02:12 < MissedOutOnBTC_> someone might want to post all these results on the forum thread or something, I try not to register for too many forums unless I need to, hah
02:12 < MissedOutOnBTC_> get some more people testing and confirming results
02:12 < MissedOutOnBTC_> trying other numbers
...
02:27 < MissedOutOnBTC_> could also try 8/32 - I have not tested that one yet

from sgminer.