1. Crestron
  2. Теми

any working NTP servers

 

Anyone have a working NTP server?
 
I've used "us.pool.ntp.org", "time.nist.gov" and "http://worldtimeapi.org/api/timezone/EST" and each are timing out, no response, or too many request.
 

The first two of those should be working; also time.windows.com has been an option in the past. 


NTP is on Port 123 and is not in any way like HTTP so if you're literally using http://worldtimeapi.org/... that certainly won't work 


If you are on a corporate network it is typically best practice to use local NTP servers (any Windows Domain Controller, for example) 


Lincoln 

From: crestron@groups.io <crestron@groups.io> on behalf of Brad Wykoff via groups.io <bradwykoff@...>
Sent: Friday, December 13, 2024 10:10 AM
To: crestron@groups.io
Subject: [crestron] any working NTP servers
 
Anyone have a working NTP server?
 
I've used "us.pool.ntp.org", "time.nist.gov" and "http://worldtimeapi.org/api/timezone/EST" and each are timing out, no response, or too many request.
 

I was using the Crestron module "Network Time Sync v1.0" with the default servers and getting errors in text console with debugging enabled.
 

Are you on an older 2-series processor? All of the newer ones (3 and 4 series) don't need a module for NTP, you set the time zone/NTP in the Processor itself.
 
I generally use a local one or googles (time.google.com or 216.239.35.0)
 

It was a 2 series processor that I ended up just upgrading to a 4 series to use the internal NTP.
 

Side question… do NTP servers adjust for daylight savings?

Tim Greenbank

Control Systems Engineer


On 14 Dec 2024, at 06:21, Brad Wykoff via groups.io <bradwykoff@...> wrote:


It was a 2 series processor that I ended up just upgrading to a 4 series to use the internal NTP.
 

NTP servers provide UTC.
Clients need to apply their timezone and daylight-saving offset.
That's a general statement - haven't looked into how Crestron handle it, but the NTP side of things should definitely be UTC.
 

Pretty sure Crestron processors only allow for time zone adjustment, as far as I’m aware there’s no DST offset in the web interface.

I have a site that relies heavily on schedules so I’m keen to get this correct.

Tim Greenbank

Control Systems Engineer


On 14 Dec 2024, at 09:13, Paul Dengate via groups.io <paul.dengate@...> wrote:


NTP servers provide UTC.
Clients need to apply their timezone and daylight-saving offset.
That's a general statement - haven't looked into how Crestron handle it, but the NTP side of things should definitely be UTC.
 

They do support DLST. I had a CP2E running a small lighting system that would shut off nvram every year when it returned to normal time.
 

Crestron processors definitely do support DST offsets. When you set the time-zone, DST is automatically factored in.
 
On 2-series, this was done via the CLOCK symbol. For 3 and 4-series, you can use the TIMEZONE console command or Toolbox or the web interface to set this.
 
--
Josh Winn
The LiquidPixel Group
 

The 3- and 4- series apply DST (Summer/Winter Time) based on the selected/configured timezone.

 

The 2-series have no intrinsic concept of time zones but can configure DST (from among ‘none’, ‘US’, ‘southern hemisphere’, ‘European’, ‘Egypt’, or ‘Australian Eastern’) based on a parameter on the CLOCK or CLOCK2 symbol) and the offset from UTC needs to ne handled internally by the clock sync module because as Palul noted NTP provides only UTC

 

I didn’t think the XGEN supported DST but if you drop a CLOCK symbol in the program the parameter is there (with the help entry for it stating that the parameter is not supported on the XGEN) so… But how many XGENs are still running around out there? (Probably more than a few).

 

And of course its probably not important to note that there’s at least three widely understood ‘time’ protocols: NTP, SNTP, and DAYTIME.

 

DAYTIME provides the date/time in a loosely defined plain-text format that is really easy to parse against a single server but because the format is loosely defined parsing it can fall apart easily as various OSes have slightly different implementations with no clear indication other than looking at what the returned value is and guessing how its formatted.

 

SNTP and NTP both provide the same data from the server in a very predictable format that is not at all human readable. The only difference between SNTP and NTP is on the client side with the S standing for simple. ‘Pure’ NTP provides the greatest accuracy by requiring querying at least 3 servers [IIRC] and averaging the time while SNTP is content to just take the time provided by a single server and use that – but the data provided by the server is the same in either case.

 

Lincoln

--

Lincoln King-Cliby

Commercial Market Director
Sr. Systems Architect | Crestron Certified Master Programmer (Diamond)
ControlWorks Consulting, LLC
Direct: (+1)440.771.4807 | Cleveland: (+1)440.449.1100  | Boston: (+1)508.695.0188 | DC: (+1)202.381.9070 | London: (+44) (0)20 4520 4600 
Crestron Services Provider | Biamp Authorized Independent Programmers | Extron Qualified Independent Programmer

 

 

 

From: crestron@groups.io <crestron@groups.io> On Behalf Of Tim Greenbank via groups.io
Sent: Friday, December 13, 2024 5:20 PM
To: crestron@groups.io
Cc: crestron@groups.io
Subject: Re: [crestron] any working NTP servers

 

Pretty sure Crestron processors only allow for time zone adjustment, as far as I’m aware there’s no DST offset in the web interface.

 

I have a site that relies heavily on schedules so I’m keen to get this correct.

 

Tim Greenbank

Control Systems Engineer



On 14 Dec 2024, at 09:13, Paul Dengate via groups.io <paul.dengate@...> wrote:



NTP servers provide UTC.

Clients need to apply their timezone and daylight-saving offset.

That's a general statement - haven't looked into how Crestron handle it, but the NTP side of things should definitely be UTC.
 

Fantastic, thanks Josh that’s good to know. I had a feeling they did but certain “cheap and cheerful” devices shall we say seem to give the option to set the dates of DST 😅

Tim Greenbank

Control Systems Engineer


On 17 Dec 2024, at 00:23, josh@LiquidPixel via groups.io <jwinn@...> wrote:


Crestron processors definitely do support DST offsets. When you set the time-zone, DST is automatically factored in.
 
On 2-series, this was done via the CLOCK symbol. For 3 and 4-series, you can use the TIMEZONE console command or Toolbox or the web interface to set this.
 
--
Josh Winn
The LiquidPixel Group
 

Cheers Lincoln, I appreciated the comprehensive answer!! 

Tim Greenbank

Control Systems Engineer


On 17 Dec 2024, at 00:30, Lincoln King-Cliby via groups.io <lincoln@...> wrote:



The 3- and 4- series apply DST (Summer/Winter Time) based on the selected/configured timezone.

 

The 2-series have no intrinsic concept of time zones but can configure DST (from among ‘none’, ‘US’, ‘southern hemisphere’, ‘European’, ‘Egypt’, or ‘Australian Eastern’) based on a parameter on the CLOCK or CLOCK2 symbol) and the offset from UTC needs to ne handled internally by the clock sync module because as Palul noted NTP provides only UTC

 

I didn’t think the XGEN supported DST but if you drop a CLOCK symbol in the program the parameter is there (with the help entry for it stating that the parameter is not supported on the XGEN) so… But how many XGENs are still running around out there? (Probably more than a few).

 

And of course its probably not important to note that there’s at least three widely understood ‘time’ protocols: NTP, SNTP, and DAYTIME.

 

DAYTIME provides the date/time in a loosely defined plain-text format that is really easy to parse against a single server but because the format is loosely defined parsing it can fall apart easily as various OSes have slightly different implementations with no clear indication other than looking at what the returned value is and guessing how its formatted.

 

SNTP and NTP both provide the same data from the server in a very predictable format that is not at all human readable. The only difference between SNTP and NTP is on the client side with the S standing for simple. ‘Pure’ NTP provides the greatest accuracy by requiring querying at least 3 servers [IIRC] and averaging the time while SNTP is content to just take the time provided by a single server and use that – but the data provided by the server is the same in either case.

 

Lincoln

--

Lincoln King-Cliby

Commercial Market Director
Sr. Systems Architect | Crestron Certified Master Programmer (Diamond)
ControlWorks Consulting, LLC
Direct: (+1)440.771.4807 | Cleveland: (+1)440.449.1100  | Boston: (+1)508.695.0188 | DC: (+1)202.381.9070 | London: (+44) (0)20 4520 4600 
Crestron Services Provider | Biamp Authorized Independent Programmers | Extron Qualified Independent Programmer

 

 

 

From: crestron@groups.io <crestron@groups.io> On Behalf Of Tim Greenbank via groups.io
Sent: Friday, December 13, 2024 5:20 PM
To: crestron@groups.io
Cc: crestron@groups.io
Subject: Re: [crestron] any working NTP servers

 

Pretty sure Crestron processors only allow for time zone adjustment, as far as I’m aware there’s no DST offset in the web interface.

 

I have a site that relies heavily on schedules so I’m keen to get this correct.

 

Tim Greenbank

Control Systems Engineer



On 14 Dec 2024, at 09:13, Paul Dengate via groups.io <paul.dengate@...> wrote:



NTP servers provide UTC.

Clients need to apply their timezone and daylight-saving offset.

That's a general statement - haven't looked into how Crestron handle it, but the NTP side of things should definitely be UTC.
 

From an old-timer: 
… the CN2 series did have limited DTS availability, as in not all time zones were available, however these devices were pre internet so relied totally on the internal clock.
The CNMSX series essentially used the same symbol set as the CN2 series but had the option of installing a network card, but needed to have the Crestron module (or home grown) to query a time server.
 
Lindsay

1 - 14 з 14