Are you saying the DCs are drifting from the PDCE as well?
Firstly, I suggest configuring the peer list on the PDCE to use 0x8 rather than 0x1.
w32tm.exe /config /syncfromflags:manual /manualpeerlist:time.nist.gov,0x8 time-a-g.nist.gov,0x8 [...] /reliable:yes /update
In the System event log, does the PDCE show it's successfully syncing time? I suggest filtering the log source to show events from Time-Service.
There should be one event 35 for each of the peers you have configured to show they're syncing time. Then followed by Event 37 for each peer to say the PDCE is receiving valid time. You may need to run w32tm /resync /rediscover or restart the service to trigger the events.
Check the peers too: w32tm /query /peers.
If any show State: pending, run w32tm /query /status and check each peer for a Last Successful Sync Time a long time in the past (e.g. more than an hour). If that's the case, you might have a networking issue or it's a bad source.
Next, does the PDCE show Events 139 followed by 143 (event 12 might appear as a temporary warning before 143), showing that it is advertising as a time source and then a good time source? At this point, the PDCE is advertising correctly. Or it should be. This can take a few minutes after rediscovering/restarting the service. Make sure there is no 144 event after 143 - this means the PDCE has stopped advertising as a time source.
Next, on your other DCs, run w32tm /query /peers. Check there's just the one peer (PDCE), that the state is Active, and that the Time Remaining is less than the PeerPoll\HostPoll intervals. Which is 1024 for yours, it seems.
C:\> w32tm /query /peers
#Peers: 1
Peer: PDCE.xxx.au
State: Active
Time Remaining: 593.4024152s
Mode: 1 (Symmetric Active)
Stratum: 2 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 10 (1024s)
HostPoll Interval: 10 (1024s)
In the System event log, the last Time-Source events should be 35 or 37, to say the DC is getting time from the PDCE. There should be a 139 event to say it's advertising as a time source. There should not be a 143 event (advertising as a good time source) unless it's most recently followed by a 144 warning (it's stopped advertising as 'good').
If there are any issues with any of the above, check that the NTP ports are open between the DCs - UDP 123. Obviously, if the PDCE isn't getting time from its upstream sources, check the port as well. There may be a local timesource you should use instead (we use the one configured internally as part of our DNS/DHCP solution managed by the Networks team, which is downstream from the Stratum 1 clock in our region).
If the most recent time events are warnings or errors on the DC - 35/37 aren't the most recent time events on the non-PDCEs - those will be worth investigating.
If the DCs are all fine with time sync, then the next thing is to look at the clients.
By the way, it's good to configure this with Group Policy. I highly recommend that there's a GPO targeted to the PDCE so that if you move the role, the time config goes with it. I also have a "default" time GPO just as a fallback in the DC policies - it's just the usual defaults - but really there to ensure that a former PDCE gets the regular time config back after the FSMO is moved. But GPOs can be done later, once the DCs are happy.
