I really don't know what to do for the best.
Don't make any other changes to the circuit. Please let it operate in that state for the next 24 hours. WWWombat will look and think and . . . 
I'm afraid my superpowers are waning... though being on a narrowboat, with limited access and the fact I can't get on MDWS this way may be more effective than kryptonite.
The original impact is strange - that UnCorr happen in such a patterned way suggests, perhaps, a modem artifact, rather than a noise impact. I really need to correlate all the (error) graphs at once to say more.
The later impact, where errors don't appear with the lower sync, is the conventional expectation.
To @maybecrazy - what should you do? I don't see anything critical either way, but the key thing to watch is the ES graph, making sure the ES total per 24hrs stays reasonable. A few hundred or less.
@b*cat For upstream noise margin, you always need to factor in any adjustments to the power too. I suspect that UPBO works by adjusting power relative to "excess" noise margin, at least when the package speed can be achieved. I can't tell if that's the case here...
@anyone
The graphs for CRC vs UnCorr (on one of @maybecrazy's post above) are both described as "per min", but (in my mind) ought to end up as the same value. That UnCorr peaks at 60, while CRC peaks at 4 suggests that one isn't being converted from a "15 min" statistics value into a per minute value.
Thinking on from that, I recall that UnCorr are counted in the section on retransmission, while CRC probably come from the 15 minute bins that are in the --stats output. I wonder how the two raw values change over a 30 minute period, vs conversion into "per min" values.
