1) It looks like both your PRIMARY TIMING SOURCE and your BACKUP TIMING SOURCE are configured for Slot 1 Port 3. When it loses clock sync on one, it switches to the other (which is programmed to be the exact same slot and port). So the ATLAS is attempting to swap clock sources but both the primary and backup are the same.
2) To the left of the "T1 Curr UAS Thrs Exceeded" message in the Event Log it should list the slot and port this is being reported on. If it is a DS3 module, the "port" is the DS1 on the DS3, and would indicate unavailable seconds (UAS) on that particular T1.
Hope this helps,
Thank you for the pointers.
On point 1, is this a problem? Could this be causing the UAS that we're seeing on point 2?
On point 2, I'm seeing these messages sporadically throughout the day across different T1s. And, it's not always the same T1. Sometimes I see the errors for 4 T1s. Other times 8 of these messages will show up. They also appear in groups, all at the same time.
I have an open ticket with support, also. After I've had a chance to speak with them I'll update this thread.
Thanks again patrick!
UAS on Slot1 Port3 can cause the timing change, but the timing change shouldn't cause UAS on another port. You should not have both the Primary and Backup timing as the same interface. If there is no other interface you can take timing from then the Backup should be INTERNAL.
Point 2 sounds like you either have major circuit issues, or you have interfaces configured that are not in use.
We indeed has ports active that had no cable in them. The timing issues we had were, again, from ports that no longer had cables in them.
We still have some work to do on our unit, but I certainly have a better idea of what is going on!
Big Thanks! to Patrick at Adtran!