I can confirm the same results experienced by jurASIC when modifying -scantime and -expiry in BFGminer 4.10.0.

I too experienced a significant delay in the new block detection time when solo mining using BFGminer. Using a stopwatch, I timed the following:

-Start: Exact moment (minus reaction time) that the Bitcoin Core debug window showed a new block number in the Block Chain section on the Information tab. Note, this was based on the actual time Bitcoin Core (v 0.9.3.0-g40d2041-beta) received information of a new block with 39 connections (30 in/8 out), not the timestamp of said block.

-Stop: Exact moment (again, minus reaction time) that BFGminer showed 'New block detected on network'.

On two independent, subsequent tests (Block# 327012 and 327013), this resulted in an average new block detection latency of 1 minute 14 seconds. Keep in mind, BFGminer and Bitcoin Core are running on the same computer, thus WAN and/or LAN latency is not an issue.

As one would assume, the target command to alter would be -scantime, given the fact this dictates the upper bound on time spent scanning current work. I played with the argument here, changing it to 0, then 1 (would not accept -1), to no avail.

However, when changing the -expiry argument from the default 120 to 1, I experienced almost simultaneous synchronization between Bitcoin Core and BFGminer regarding the detection of a new block. Since -expiry only pertains to the upper bound on how many seconds after getting work we consider a share from it stale, I am not sure how this pertains to situations when solo mining. From what I've gathered, Bitcoin Core running in server mode does not have long poll capability. Given there are two different commands regarding expiry (e.g. -expiry and -expiry-lp), I wouldn't even know where to start on rationalizing how the expiry command impacts new block detection when solo mining.

Can any resident experts weigh in on this? As jurASIC noted, latency regarding new block detection does have a substantial impact on solo miners, as time wasted working on a block that has already been solved is an even further handicap to the solo miner. However, if altering this argument is somehow harming the solo miner's ability to submit block solutions, it would be good to reopen discussion on the specifics of what the -expiry impact is when not submitting shares to a pool.

Not sure this warrants a new thread, as the issue is quite specific; however, I do hope to revive discussion on this issue in hopes to clarify it for future solo miners. Perhaps it's something worth noting in the README...