etwenandClaude Opus 5
496e3ab650
blanton_ber.sh init -> start -> sleep 30 -> report -> stop -> clear, branched on SWB_UNIT0 / SWB_UNIT1 the same way the traffic block beside it is. Script C already took the closing sweep after its traffic report. With this one at the front the pair brackets the soak, the same shape the DSC scans got in V1.2.0 and for the same reason: one BER figure says very little, a change in it says a lot. The sleep 30 is blanton_ber.sh's BER_INTERVAL. Reporting before a full interval has accumulated reads a window that has not finished, and nothing warns about it - that number now lives in three places. The block was copied out of Script C, whose comment says it runs after the traffic report, because there it does. Here it runs before. The comment was rewritten to describe where the code actually sits and why 'clear' has to happen before the traffic block. Not yet run on hardware. Nothing settles between blanton_ber.sh clear and the blanton_traffic_linespeed ps that follows it, and 'clear' is what releases lanes PRBS was holding out of normal operation. Script C does not have that ordering, so the two traffic reports are a built-in comparison: NA or FAIL pairs in Script A's that are absent from Script C's mean the lanes had not come back, and a sleep after 'clear' is the fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014RetWKFZFG1ZHcitQAyhwM