We support our products for as long as you own them with FREE technical support by phone or email and free software upgrades as they become available. No maintenance contract required.
NOTICE: CDMA base stations throughout the U.S. are being repurposed, resulting in loss of timing synchronization signals for your Sonoma. For more information click here. Or, see this Field Service Bulletin.
240228Feb 28, 2024 | Security Vulnerability Announcements re: c_rehash script CVE-2022-1292 CVE-2022-2068 EndRun products are not vulnerable. |
180606Aug 3, 2018 | February 2018 NTP Security Vulnerability Announcement |
180104Jan 4, 2018 | January 2018 Meltdown and Spectre Vulnerabilities |
170328Mar 28, 2017 | March 2017 NTP Security Vulnerability Announcement |
161205Dec 5, 2016 | November 2016 NTP Security Vulnerability Announcement |
160606Jun 6, 2016 | June 2016 NTP Security Vulnerability Announcement |
160321Mar 21, 2016 | GNU glibc Vulnerability to Crafted DNS Responses |
151026Oct 26, 2015 | October 2015 NTP Security Vulnerability Announcement |
150414Apr 14, 2015 | NTP Client/Peering Vulnerabilities |
150130Jan 30, 2015 | Linux Ghost Vulnerability |
141222Dec 22, 2014 | NTP Remote Query and Crypto Vulnerabilities |
140926Sep 26, 2014 | Linux Bash Shellshock Vulnerability |
140409Apr 9, 2014 | OpenSSL Heartbleed Vulnerability |
140110Jan 10, 2014 | NTP Monlist Vulnerability |
220531Jun 19, 2022 | CDMA-Synchronized: Sonoma, Tempus LX, Meridian, Unison, Tempus Cntp, Praecis Cntp, Praecis. CDMA Base Stations throughout the U.S. are being repurposed, resulting in loss of timing synchronization signal for products listed above. |
151026Oct 26, 2015 | Sonoma, Tempus LX, Unison, Meridian, |
141222-01Dec 22, 2014 | Sonoma |
140926-01Sep 26, 2014 | Sonoma |
140110-01Jan 10, 2014 | Sonoma |
131216Dec 16, 2013 | Sonoma |
170101Jan 1, 2017 | Sonoma, Meridian II, Tycho II, Tempus LX, Unison, Meridian, Tycho, Praecis |
160707Jul 7, 2016 | Sonoma, Meridian II, Tycho II, Tempus LX, Unison, Meridian, Tycho, Praecis |
150701Jul 1, 2015 | Sonoma, Tempus LX, Unison, Meridian, Tycho, Praecis |
150106Jan 6, 2015 | Sonoma, Tempus LX, Unison, Meridian, Tycho, Praecis |
As long as your unit is still under its current warranty then yes, you can purchase an extended warranty. Contact EndRun Sales for information.
Yes - we will try. The problem may be that we no longer have parts for the old models. But, if we can still get the needed parts then we will repair your unit and charge for time and materials.
At EndRun, End-of-Life (EOL) means end of the production life cycle. We continue to provide free technical support (by phone or email) for as long as you own an EndRun product. In fact, we are still providing free support for products that we shipped in 2001.
Software upgrades for all our products are freely available for download from our website at: www.endruntechnologies.com/support/software-upgrades.
Current products (Sonoma, Meridian II, Tycho II, RTM3205) can be upgraded to the latest version of firmware straight from any older version. However, if you have modified either /etc/profile or /etc/rc.d/rc.M and your Linux Root File System (RFS) is prior to version 2.20 then please contact Support (support@endruntechnologies.com).
Legacy products (Tempus LX, Unison, Meridian, Tycho, RTM3204) can also be upgraded to the latest version of firmware straight from any older version. However, if your RFS is prior to version 2.60 then please read this.
In the United States, we expect CDMA service to sunset by the end of 2022. For background and details, click here.
The difference between PCS and cellular is the frequency band. PCS frequencies are at 1960 MHz and cellular frequencies are at 881 MHz. All our current CDMA-synchronized products use a dual-band CDMA receiver and can receive either cellular or PCS signals. Some of our earlier products use CDMA at cellular frequencies only.
CDMA coverage is throughout the USA, China, Korea, India, Japan and elsewhere. The best way to know if you have CDMA coverage is to find someone with a CDMA cellular or PCS phone and see if it indicates any signal level at all. Our products work in very poor signal level conditions.
If you are unsure that you have the appropriate CDMA coverage contact us. Also, since we offer a 60-Day Money-Back Guarantee there is no risk in trying it out. We have shipped thousands of units throughout the world and our return rate has been less than 1%.
No. Our CDMA-synchronized products merely receive the timing signals that are freely transmitted from basestations and which are used by the mobile handsets for synchronization. Since our units only receive the timing data and do not transmit any information, no subscriber fee is required to use our instruments.
The answer is positive because there is a delay between the antenna and the receiver.
Think about it like this: The antenna receives the time data x nanoseconds before the receiver. Therefore, the receiver is behind the antenna by x nanoseconds. By entering a positive delay, the clock will be advanced x nanoseconds to compensate.
CDMA basestation transmissions must be synchronous with UTC to within 10 microseconds, typically much better - less than 1 microsecond. This variation is due to the possibility that a basestation might have a GPS outage, a rare occurrence. Under these conditions the basestation must stay within 10 microseconds of UTC for as long as 24 hours. This ensures the smooth operation of the CDMA telecommunications system.
Our products are synchronous with the CDMA basestation transmissions from one to tens of microseconds, depending on location. This variation depends on the propagation delay from our receiver to the basestation. The propagation delay is about 5 microseconds per mile (about 3 microseconds per kilometer). In an urban environment, there are many basestations and you would probably be within a mile of one. Therefore the accuracy of the unit would be within 5 microseconds of the CDMA transmissions and typically within 6-7 microseconds of UTC. Our main facility is located in an urban environment and our products test here to within 2 microseconds of UTC. This is very typical for an urban environment.
In suburban or rural areas the basestations are spaced further apart. This increases the propagation delay and therefore the accuracy of the unit degrades. At our suburban test facility the units are synchronous with UTC to within 20-25 microseconds. At our rural test facility the best-case accuracy we have seen is 30 microseconds and the worst-case is nearly 90 microseconds. That would put the received basestation at nearly 18 miles away!
If you know approximately how far away the basestation is from your location you can eliminate this propagation delay component by using the CAL command via the serial I/O port. Refer to the user's manual for more details.
No. If the unit is able to acquire and decode the data, the accuracy is just as good as with a strong signal level. There is no gradual degradation of timing accuracy. The time data encoding scheme ensures that if the data is decodable, it will be valid.
The unit is able to receive and decode data even with very poor signal levels. It only has to be able to decode one low-speed CDMA channel, unlike cell phones that need to decode multiple high-speed data channels.
Unlike the timing outputs, the 10 MHz frequency output is not affected by propagation delay. Since both the basestation and the EndRun unit are stationary (they don't move in relation to each other) the frequency is extremely accurate, to parts in 10 to the 12th over 24-hour averaging times. On rare occasions, a basestation might experience a GPS outage, as when the GPS antenna is damaged. Under these conditions the basestation's GPS receiver would go into a holdover mode and its frequency could drift up to about a part in 10 to the 10th over 24 hours. An outage is rare, and one lasting 24 hours would be very rare.
Note that the requirement to maintain basestation synchronization during long GPS outages requires that each basestation have at least one high performance GPS time receiver controlling either an ultra high stability quartz oscillator or a rubidium vapor atomic frequency standard. Since it is very difficult to meet this performance using quartz oscillators, most base stations have rubidium units and redundant GPS receiver/oscillator units are common.
No.
Stratum is a term that means different things depending on the context. In the world of NTP, stratum is defined in RFC 1305. NTP uses a hierarchical structure in which Stratum 0 is the reference clock, linked via a time signal, to a reliable source of UTC. Stratum 1 is the time server with a direct link to the reference clock. Stratum 2 is a client that receives time over a network connection from a Stratum 1 clock. Stratum 3 is a client that receives time from a Stratum 2 clock. And so on, up to Stratum 15. For more details on strata in the NTP world, click here.
Over WANs (Wide Area Networks), up to 100 milliseconds is typical. It depends on how far away the public time server is, or more specifically, how many hops between you and the server. Within a LAN (Local Area Network) using a dedicated NTP Time Server, 0.5 to 2 milliseconds is typical. The internal accuracy of the CDMA Network Time Server is on the order of 10 microseconds. It can easily keep all clients on a LAN synchronized to typically within 0.5 to 2 milliseconds.
Client software is widely available as freeware and shareware. Setting up an NTP or SNTP client is relatively simple once you have installed the software on your workstation and communicated with the time server over the network. For a list of NTP client software click here.
Exclusive EndRun oscillator-control algorithms provide extended Stratum 1 holdover performance when the unit is not locked to the synchronization signal (GPS or CDMA). Typical NTP Stratum 1 holdover periods are:
24 hours - TCXO (standard)
35 days - OCXO (upgrade)
140 days - Rubidium (upgrade)
When two or more computers are involved, accurate time keeping is difficult, especially if they are not in the same physical location. A dedicated time server inside your network perimeter is the most accurate, reliable and secure way to ensure accurate timekeeping for all computers on your network. Accurate timekeeping is necessary to support eBusiness and other applications such as Stock Trades, Logs, B2B Transactions, File Operations, Packet Time Stamps, Software Configuration Management, Database Accuracy, Telecommunication Call Billing, etc. For a more detailed response to this question click here.
There are many public time servers available over the Internet. Access to these public time servers is free of charge. While public time servers are certainly less costly - accurate, reliable and secure time is best provided by a dedicated time server that resides under your control inside your network security perimeter. Using public time servers available over the Internet is not recommended for the following reasons:
1. Setting up your firewall to accept NTP packets (which is based on UDP/IP) introduces a security risk that many Network Administrators are not willing to take.
2. Time accuracy degrades because of indeterminate network latency, up to 100 milliseconds is typical.
Yes. For current models (Sonoma, Meridian II, Tycho II, RTM3205) use Linux command:
ntpq -c sysinfo
For legacy models use Linux command:
ntpdc -c sysinfo
For a detailed answer to this question click here.
Yes. NTS4NTP is in the draft standard level and when released we expect it will be integrated into the NTP distribution. The Time Servers are periodically upgraded with the latest distribution so when NTS4NTP is supported, then it will also be supported in our products. The standards process is lengthy so there is no telling when this capability will be in the NTP distribution.
EndRun NTP Servers are compliant with STIG ID: NET0813, Rule ID: SV-15326r5, Vuln ID: V-14671. The time servers support a FIPS-approved message authentication code and NIST-approved HMAC algorithms.
For our third generation units such as Sonoma, Meridian II, Tycho II, Ninja, RTM3205 and e-Series Distribution, run the command:
/etc/rc.d/rc.ntpd restart
For older models, the only way to restart the daemon is to reboot.
Precision Time Protocol (PTP) is a relatively new protocol that was developed to improve the time synchronization accuracy that is obtainable over a Local Area Network (LAN). Specifications for PTP are defined in the IEEE-1588 standard. In PTP terminology, the Grandmaster is the distributor of accurate time and the Slave is the receiver of this time. The Slave synchronizes itself to the Grandmaster.
The most common network timekeeping protocol is the Network Time Protocol (NTP). In NTP terminology, the Server is the distributor of accurate time and the Client is the receiver of this time. The Client synchronizes itself to the Server.
With NTP you can get client synchronization accuracies in the millisecond range. With PTP you can get slave synchronization accuracies in the nanosecond or microsecond range. Synchronization accuracy depends not just on the PTP Grandmaster, but also on the network topology such as switch and slave hardware.
Products listed below can be configured as a IEEE-1588/PTP Grandmaster Clock. Here are the timestamp resolution and accuracy specifications:
Model | Timestamp Resolution | Timestamp Accuracy to UTC (RMS) |
Sonoma (GPS) Network Time Server |
8 nanoseconds | 30 nanoseconds |
Sonoma (CDMA) Network Time Server |
8 nanoseconds | 10 microseconds (typical) |
Meridian II Precision TimeBase |
8 nanoseconds | 10 nanoseconds |
Tycho II Precision TimeBase |
8 nanoseconds | 25 nanoseconds |
The Grandmaster user interface allows you to modify the TTL Value (time-to-live value) in order to accomplish this. You will also need to modify the TTL Value on your PTP Slave.
The main difference is in the synchronization accuracy that can be achieved. With software timestamping as typically implemented (software-only approach), you can see slave synchronization accuracies between 10 and 100 microseconds. You can achieve this level of accuracy with commonly used network hardware such as standard switches, and computers with software PTP slaves.
With hardware timestamping as implemented on a Sonoma it is possible to achieve time synchronization accuracies of 30 nanoseconds with an 8 nanosecond resolution. However, in order to get this level of accuracy, both the Grandmaster and the Slave must be capable of hardware timestamping. This means you will need to purchase specialized hardware to install in each Slave. In addition, network switches must configured as transparent clocks or boundary clocks.
PTP Version 2 has been designed to span over a WAN. However, performance is dependent on the network configuration. For example, a network switch would need to be configured as a transparent clock or boundary clock in order to realize the superior synchronization capability. Otherwise, synchronization of PTP becomes equivalent to NTP.
Yes. All Sonoma, Meridian, Tycho II, Tempus LX, and Unison Time Servers are capable of operating PTP. PTP is a relatively low-cost option that can be installed by you at any time. All that is needed from you is the Ethernet address (MAC) and we can supply a software key and instructions for turning on PTP. For older products, you may need to upgrade your software first.
The Precision Time Protocol (PTP) is a relatively new protocol (compared with NTP). As such, there are fewer options available for you to use for PTP Slave software. The options that do exist range from software-only solutions to software with hardware timestamping solutions. For further information click here.
Over 2000. But it depends on various settings and configurations that can increase or decrease the number of slaves that Sonoma can support. Consider the following:
1. If using a Boundary Clock, the Sonoma only interfaces with the network switch Boundary Clock. In this case the capacity is limited by the Boundary Clock switch.
2. When using a Transparent Clock, the capacity is limited by the frequency of the delay requests and the sync rate. Sonoma will be able to provide all the slaves with the Sync Packets and Announce Packets. But, there will be a limit for processing delay requests issued by the slaves. Our implementation requires about 10 microseconds to handle a delay request / response. The delay request is used to calculate the slave-to-master delay. If your network is static the delay should not change and the Sonoma will announce to the slave to use 32-second delay request interval.
Even though the slaves randomize the delay request packets, the request can come in simultaneously. What happens if delay requests show up simultaneously? In this case, the Sonoma will not issue a delay response. The slave will then randomize the delay request interval and issue the request again. Some slaves will log a notification that a delay response was not received.
This string:
Sonoma_D12 GPS 6010-0065-000 v 2.40 - Tue Sep 19 02:19:38 UTC 2017
which is displayed immediately after login simply means that firmware 6010-0065-000 version 2.40 was released on Tuesday September 16, 2017 at 02:19:38 UTC. It has nothing to do with current UTC.
Yes.
No. To see a list of EndRun's product commands that you can easily use, type:
help
To get help on a particular command type "help EndRun-command-name". For example:
help gpsstat
This will show you details regarding the gpsstat command.
Edit the file /etc/profile and modify the definition of PS1. After making the change, copy the file to the non-volatile area:
cp /etc/profile /boot/etc
Serious vulnerabilities that cannot be mitigated with a reasonable workaround will be addressed with a new firmware update as soon as possible. For remaining vulnerabilities, please see Network Security Bulletins for mitigation steps.
Also, we recommend reading this: Best Practices to Secure Your Time Server. Taking the steps outlined in this paper will eliminate most, if not all, vulnerabilities. It was written for the Sonoma Time Servers but the same general steps apply to our other Linux-based products.
Yes. Follow these instructions:
1. Open the sshd_config file for editing.
For current models (Sonoma, Meridian II, Tycho II, RTM3205) open this file:
/etc/ssh/sshd_config
For legacy models open this file:
/etc/sshd_config
2. Uncomment and edit the lines in sshd_config with ClientAliveInterval and ClientAliveCountMax settings as follows:
ClientAliveInterval <session timeout in seconds>
ClientAliveCountMax 0
3. Don't forget to make the modified file persistent, by copying it to FLASH:
For current models (Sonoma, Meridian II, Tycho II, RTM3205):
cp -p /etc/ssh/sshd_config /boot/etc/ssh
For legacy models:
cp -p /etc/sshd_config /boot/etc/
4. Reboot the unit using this command:
reboot
If you are uploading via SSH, do not use WinSCP! WinSCP does not work well with a raw flash partition. We have had great success using PuTTY's pscp utility, which is executed from the Windows command line and uses the same syntax as the Linux-based scp utility. You can download pscp from putty.org.
You will need to configure a gateway for both the Ethernet ports. The user manual indicates that only one port can be configured with a default gateway (using the front panel or netconfig). However, with advanced routing you can configure a gateway for both ports (eth0 and eth1). You must add commands to set up static routes in the /etc/rc.d/rc.M startup script. There is an easily spotted comment in the rc.M file showing where to add the commands. For more information, read this Product Note or contact EndRun Technical Support.
No. Products manufactured by Endrun Technologies are not affected because none of them include any version of Apache Log4j.
For our third-generation units such as Sonoma, Meridian II, Tycho II, Ninja, RTM3205 and e-Series Distribution Chassis run the command below to invoke interactive script:
accessconfig
Then, when prompted enter a hostname, host address or range of host addresses to be given telnet/ssh/snmp access (name, IP address or IP address range, 0 to quit). You enter:
192.168.1.0/255.255.255.0