It's also possible that the clocks really ARE skewed - assuming the threshhold Reid mentioned in the default, and it's a reasonable value (I've never had to change it and never gotten a skew error), then maybe the NTP settings on the controllers are not correct, or there is a problem with the NTP server, or there are intermittent connectivity errors. I'm not sure how DFM does it, but if it compares the controller time with the DFM server time, then perhaps the NTP issues are on the DFM server.
You can try enabling the timed.log (options time.log on) to see if it tells you anything. If DFM is a unix host, you can use ntpq to check the status of the time servers (ntpq -c lpeers - check for an asterisk by a host that tells you it's bound).
Look at the hostClockNearlySkewedThreshold setting on your DFM server. The following KB article explains how the host clock is monitored using a polling interval on the DFM server and how you can adjust the threshold.
If you are getting the messages on DFM (operations manager) then the clocks are skewed. One simple way from windows to determine in to run from a command prompt the following:
"Net Time \\filer name" this will give you the output of the current system time on the Netapp, compatre it to the DFM server "Net Time \\DFM Server Name" and see what the time difference is. This is the fastest way to be sure. Make sure you do it for all your filers, just to be on the safe side.