Time syncronisation in domain
-
@BRRABill said in Time syncronisation in domain:
@JaredBusch said
I never set any GPO for time synchronization on my workstations that are joined to a domain.
Right, that is just automatic, correct?
Yes, normally.
-
@DustinB3403 said
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
Time will still be bad, but it's bad everywhere.
That's a good question. How would the client know the DC is off? Wouldn't it just update to the DC time?
But again, I think that goes back to Scott's question of ... what does the DC use for its time source.
-
@DustinB3403 said in Time syncronisation in domain:
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
Only if they were always off together. NTP and SNTP don't allow for large, rapid time drift. Which is why stability on the DC is critical.
-
@BRRABill said in Time syncronisation in domain:
That's a good question. How would the client know the DC is off? Wouldn't it just update to the DC time?
No, not if the drift is too rapid. It will see it as a stability issue and not sync.
-
@BRRABill said in Time syncronisation in domain:
But again, I think that goes back to Scott's question of ... what does the DC use for its time source.
Exactly. If the DC's source is too unstable, like using the software clock on VMware 4, you will expect it to drift too fast for clients to handle. VMware Server had a natural drift of over 100%, for example (meaning it could drift by one second, every second, when idle!)
-
@DustinB3403 said in Time syncronisation in domain:
@BRRABill said in Time syncronisation in domain:
I think you two are actually saying the same thing, but for different systems.
You agree it might be a time shift, but @DustinB3403 is asking about the client and @scottalanmiller is asking about the server.
Since the clients are looking to the server, and the server needs a time source, it would make sense to know what that was.
Would also be know if it truly was CLIENT or CLIENTS.
But the client by default (as an Always) you set the time source for the client to be the DC. So even if the DC is of by 12 years, you're clients should be off as well.
No you do not set the windows workstations to the DC. I just said that. It is an automatic backend setting. You do not set a NTP server in Windows normally when joined to a domain.
Time will still be bad, but it's bad everywhere.
If time is too far off, it will not sync.
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
-
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
-
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
-
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
-
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
-
@Dashrender said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
I was under the impression that all Hypervisors did this now days.
-
@dafyre said in Time syncronisation in domain:
@Dashrender said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
I was under the impression that all Hypervisors did this now days.
Why would you not have been under this impression in the ESX 4 days? But clearly that wasn't the case as Scott mentioned above.
-
@Dashrender said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@Dashrender said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@dafyre said in Time syncronisation in domain:
@scottalanmiller said in Time syncronisation in domain:
@JaredBusch said in Time syncronisation in domain:
@JaredBusch if this is an Offline LAN, then there would be no "local" time source at all, and no point to discuss the domain. Set the server to a global time source, confirm the BIOS battery is good.
Of course there is a source. It is the local hardware.
Could be the virtual clock, too. Which might explain the drift.
It's possible, but pretty sure this isn't true here, that it would be something like a GPS adapter. Lots of larger companies wanting the offline LAN use a $50 GPS adapter to get really solid time for cheap without a network connection. It's accurate to a few milliseconds and cheap.
In the financial world, we used Cesium clocks. Tens of thousands of dollars and use a sensor to measure radioactive Cesium decay. Accurate to nanoseconds.
So this becomes a question for @meghal ... Do you have any kind of special hardware that provides a way for your DC to get its time without an internet conneciton -- or are you just using the time settings from the OS?
And is the OS seeing a physical clock or a virtual one? And is there a healthy battery on that clock?
Does VMWare 5, 6 or 7 use the hardware clock and pass that information along to the VMs?
I was under the impression that all Hypervisors did this now days.
Why would you not have been under this impression in the ESX 4 days? But clearly that wasn't the case as Scott mentioned above.
I'm not sure when they resolved a lot of that. I know is GSX / Server 2 days it wasn't there. I know that it is now. Somewhere in between it changed
-
We use a Meinberg in Stratum 1 mode, its good to a few microseconds.
-
Here are my command notes when i setup it up on our windows domain. Obviously replace {local time server} with the ip of your local time server if it exists.
net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"{local time server}, time.nist.gov"
w32tm /config /reliable:yes
net start w32timeI did not have to make any changes to users workstations, they automatically synced with the DC's.
-
I think that we've lost the OP here!
-
You know that thread we had once where someone was complaining about how a simple question here always digresses into a mutli-page discussion and then an argument?
-
@BRRABill said in Time syncronisation in domain:
You know that thread we had once where someone was complaining about how a simple question here always digresses into a mutli-page discussion and then an argument?
At least this one was completely focused on the OP's needs (or explaining what he had said.)
-
@scottalanmiller said in Time syncronisation in domain:
@BRRABill said in Time syncronisation in domain:
You know that thread we had once where someone was complaining about how a simple question here always digresses into a mutli-page discussion and then an argument?
At least this one was completely focused on the OP's needs (or explaining what he had said.)
Trains are pretty awesome!
-
@scottalanmiller said in Time syncronisation in domain:
@BRRABill said in Time syncronisation in domain:
You know that thread we had once where someone was complaining about how a simple question here always digresses into a mutli-page discussion and then an argument?
At least this one was completely focused on the OP's needs (or explaining what he had said.)
Uh....
