I'm not sure why you are labelling these two resyncs as DLM resyncs; they don't look like that to me.
DLM normally intervenes by setting/changing only a few parameters - INP and delay, upstream and downstream. If DLM triggered the resync, you'd expect one of these to change. The modems would then re-negotiate the rest of the FEC and interleaving settings.
If INP & delay do not change, but you see small alterations in the other FEC/interleaving settings (such as depth or width of the interleaving block, or the amount of FEC overhead), then that is not a DLM intervention - just the slight adjustments you normally see as a result of any re-sync.
For you, INP downstream stays set to 3, and upstream stays at 0, so neither changes. "delay" is not visible in the MDWS, so I can't comment there; (I tend to find it better to use the graphs for an overview and the full text for detailed analysis)
But, on balance, it doesn't look like DLM intervention at all.
I think kitz gets it right with highlighting the CRC counter. It isn't easy to see the spike now (even when zooming in, the 7am-ish spike stays hidden most of the time), but they look huge - 15,000 CRC's just before midnight and 14,000 CRC's just after 7am.
I have noticed though,whenever I get a DLM resync there's a burst of errors, as if that's the dslams way of forcing the resync?
The other way around - the errors are causing the resync.
I suspect that a burst of noise big enough to create 15,000 CRC errors is easily enough to trigger a loss of sync of some form - highly likely to be a "loss of signal" or "loss of frame".
Judging by my current modem statistics, the "OHF" counter accrues at the rate of 604 every second. This ought to be a count of the frames that are each protected by CRC; each CRC error maps to one faulty OHF. At worst, you can accumulate 604 CRC's per second,
or just under 10,000 CRC's in a minute. <- miscalc
If your MDWS graph spikes are correct, you got a burst of noise that lasted
over a minute nearly 30 seconds - easily enough for the modem at one or both ends to decide it had lost sync - either because the noise masks the signal, or the noise makes it impossible for the modem to detect the incoming framing bits.
Edit: I just checked my graphs from BE's HG612 stats program: it seems to accrue OHF's at a rate of 36,000 per minute; I miscalculated above. Still - 15k of CRC errors is 30 seconds' worth of outage.