Meinberg LANTIME M600 User manual

MANUAL
LANTIME M600 GPS PTP
Network Time Server and
PTP Grandmaster Clock
27th October 2011
Meinberg Radio Clocks GmbH & Co. KG

Table of Contents
1 Impressum 1
2 Quick Start 2
3 Network Timeserver with GPS synchronized time base 4
4 The Modular System LANTIME 5
4.1 SupportedNetworkServices...................................... 6
4.2 AdditionalFeatures .......................................... 6
4.3 UserInterface ............................................. 6
4.4 Options ................................................ 7
4.5 Why to use a Network Time Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Network Time Protocol (NTP) 8
5.1 NTPTarget .............................................. 8
5.2 NTP-ClientInstallation ........................................ 8
6 Precision Time Protocol (PTP) / IEEE1588 10
6.1 GeneralInformation.......................................... 10
6.2 Functionality in Master Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3 Functionality in Slave Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4 PTPv2 IEEE 1588-2008 Conguration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4.1 GeneralOptions........................................ 12
6.4.2 Network Layer 2 or Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4.3 MulticastorUnicast...................................... 12
6.4.4 Two-SteporOne-Step .................................... 13
6.4.5 End-To-End (E2E) or Peer-To-Peer (P2P) Delay Measurements . . . . . . . . . . . . . . 13
6.4.6 ModeRecommendations ................................... 13
6.4.7 MessageRateSettings .................................... 13
6.4.8 ANNOUNCEMessages .................................... 14
6.4.9 SYNC/FOLLOWUP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.10 (P)DELAY_REQUEST Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.11HQFilter ........................................... 15
7 GPS satellite controlled clock 16
7.1 GPS170Features ........................................... 16
7.2 Time Zone and Daylight Saving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8 Mounting the GPS Antenna 17
8.1 Example:................................................ 17
8.2 Antenna Short-Circuit Assembly with surge voltage protection . . . . . . . . . . . . . . . . . . . 18
8.3 AntennaShort-Circuit......................................... 19
9 Booting the GPS receiver 20
10 Booting the Single Board Computer 21
11 Configuration User Interface 22
11.1ThemenusinDetail.......................................... 22
11.2Menu:ReferenceTime ........................................ 24
11.2.1 Description of the Gracal Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.2.2MenuSetupMRS....................................... 24
11.2.3 Menu IRIG Input Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2.4InfoGPSReceiver....................................... 27
0

11.2.5GPSReceiverPosition .................................... 27
11.2.6 GPS Satellite Constellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.2.7GPSStatusandVersion.................................... 28
11.2.8 Setup GPS Receiver Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.2.9InitGPSReceiver ....................................... 28
11.2.10Init Receiver Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2.11InitReceiverTime....................................... 29
11.2.12Initiate Cold Boot of GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2.13Initiate Warm Boot of GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2.14Set Antenna Cable Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2.15Set GPS Receiver Simulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2.16SetupGPSOutputs...................................... 30
11.2.17EnableOutputs ........................................ 30
11.2.18SetupSerialOutputs ..................................... 31
11.2.19SetupTimeZone ....................................... 31
11.2.20TIMECODE(IRIG)...................................... 32
11.2.21Synthesizer Frequency Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.3MenuTimeService .......................................... 33
11.3.1 Menu NTP Current State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.2 Menu: NTP Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.3 Menu: Stratum of local clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.4 Menu: PTP State / Setup PTPv1 (Option) . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.4Menu:NTPConguration ...................................... 35
11.4.1 Menu: External NTP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.4.2 Menu: Stratum of local clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.5 Programmable pulse (Option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.5.1SETUPPOUTX ....................................... 36
11.5.2Mode ............................................. 37
11.5.3TimerMode.......................................... 37
11.5.4SinglePulse.......................................... 37
11.5.5Cyclicmode.......................................... 37
11.5.6PPS,PPM,PPHModes ................................... 38
11.6Menu:Network ............................................ 39
11.6.1 Menu: Global Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.6.2 Menu: Setup Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.6.3 Menu: Setup IPv4 LAN Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.6.4 Menu: Setup IPv6 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.6.5Menu:LinkMode....................................... 41
11.6.6Menu:NetworkServices ................................... 41
11.7Menu:System............................................. 42
11.7.1Menu:Settimezone ..................................... 42
11.7.2Menu:RestartNTP...................................... 43
12 The graphical user interfaces 44
13 The WEB Interface 45
13.1Conguration:MainMenu ...................................... 45
13.2Conguration:Ethernet........................................ 47
13.2.1SYSLOGServer........................................ 48
13.3 Network interface specic conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.3.1 IPv4 addresses and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.3.2 IPv6 addresses and autoconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
13.3.3 High Availability Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
13.3.4 Additional Network Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.4Conguration:Notication ...................................... 51
13.4.1Alarmevents.......................................... 51
13.4.2E-mailmessages........................................ 52
13.4.3 Windows Popup Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.4.4SNMP-TRAPmessages.................................... 53
13.4.5 VP100/NET wall mount display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.4.6 User dened Alarm scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

13.4.7 NTPClientMonitoring .................................... 53
13.4.8Alarmmessages........................................ 54
13.5Conguration:Security ........................................ 55
13.5.1Password............................................ 56
13.5.2HTTPAccessControl..................................... 56
13.5.3SSHSecureShellLogin.................................... 56
13.5.4 Generate SSL Certicate for HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.5.5 NTP keys and certicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.5.6SNMPParameter....................................... 58
13.6Conguration:NTP.......................................... 59
13.6.1NTPAuthentication...................................... 61
13.6.2NTPAUTOKEY ....................................... 62
13.7Conguration:Local.......................................... 65
13.7.1 Administrative functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.7.2UserManagement....................................... 66
13.7.3 Administrative Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.7.4SoftwareUpdate........................................ 68
13.7.5 Automatic conguration check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.7.6 Get Diagnostics Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.7.7ReceiverInformation ..................................... 70
13.7.8Webinterfacelanguage.................................... 70
13.8Conguration:Statistics........................................ 71
13.8.1 Statistical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.9Conguration:Manual ........................................ 73
13.10Conguration:PTP.......................................... 74
13.10.1PTPv2 - Global Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
13.10.2PTP Network Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
13.10.3PTPStateFiles........................................ 78
14 The Command Line Interface 79
14.1CLIEthernet.............................................. 80
14.2CLINotication............................................ 82
14.3CLISecurity.............................................. 84
14.4CLINTPParameter.......................................... 86
14.4.1CLINTPAuthentication ................................... 87
14.5CLILocal ............................................... 87
15 SNMP Support 90
15.1CongurationoverSNMP....................................... 91
15.1.1 Examples for the usage of the SNMP conguration features . . . . . . . . . . . . . . . . 91
15.1.2 Further conguration possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
15.1.3 Send special timeserver commands with SNMP . . . . . . . . . . . . . . . . . . . . . . . 92
15.1.4 Conguration of the timeserver with SNMP: Reference . . . . . . . . . . . . . . . . . . . 94
15.2SNMPTraps.............................................. 98
15.2.1SNMPTrapReference .................................... 99
16 Attachment: Technical Information 100
16.1 Skilled/Service-Personnel only: Replacing the Lithium Battery . . . . . . . . . . . . . . . . . . . 100
16.2 Technical Specications M600/300 Multipac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
16.3 Safety instructions for building-in equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
16.3.1CE-Label............................................101
16.4RearPanelConnectors ........................................102
16.5ConnectorAssignments ........................................103
16.6TERMINAL(Console).........................................103
16.7ErrorRelay...............................................104
16.7.1 Technical Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
16.8 Technical Specications GPS receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16.8.1 Oscillator specications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
16.8.2 Technical Specications GPS Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
16.8.3 Signal Description GPS170 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
16.8.4 Rear Connector Pin Assignments GPS170 . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Page 0
16.9 Technical Specications LAN CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
16.9.1 Rear Connector Pin Assignments LAN CPU . . . . . . . . . . . . . . . . . . . . . . . . . 111
16.9.2 VGA, Keyboard Connector Pin Assignments . . . . . . . . . . . . . . . . . . . . . . . . . 111
16.10Technical Specications Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
16.11TimeCode...............................................112
16.11.1Abstract of Time Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
16.11.2PrincipleofOperation.....................................112
16.11.3Block Diagram Time Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
16.11.4IRIGStandardFormat.....................................114
16.11.5AFNOR Standard Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
16.11.6Assignment of CF Segment in IEEE1344 Code . . . . . . . . . . . . . . . . . . . . . . . . 116
16.11.7GeneratedTimeCodes ....................................117
16.11.8Selection of Generated Time Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
16.11.9Outputs ............................................118
16.11.10TechnicalData ........................................118
16.12TimeStrings..............................................119
16.12.1Format of the Meinberg Standard Time String . . . . . . . . . . . . . . . . . . . . . . . . 119
16.12.2Format of the Meinberg Capture String . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
16.12.3Format of the SAT Time String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
16.12.4Format of the Uni Erlangen String (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . 122
16.12.5Format of the NMEA 0183 String (RMC) . . . . . . . . . . . . . . . . . . . . . . . . . . 124
16.12.6Format of the NMEA 0183 String (GGA) . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.12.7Format of the ABB SPA Time String . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
16.12.8Format of the Computime Time String . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.12.9Format of the RACAL standard Time String . . . . . . . . . . . . . . . . . . . . . . . . . 128
16.12.10Format of the SYSPLEX-1 Time String . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
16.13Manual VP100/NET Display conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
16.14GlobalCongurationFile .......................................131
16.15GlobalOptionFile...........................................133
16.16Thirdpartysoftware..........................................133
16.16.1Operating System GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
16.16.2Samba.............................................133
16.16.3Network Time Protocol Version 4 (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . 133
16.16.4mini_httpd ..........................................134
16.16.5GNU General Public License (GPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.17Reference ...............................................139
0 Date: 27th October 2011 LANTIME M600 GPS PTP

Page 1
1 Impressum
Meinberg Radio Clocks GmbH & Co. KG
Lange Wand 9, 31812 Bad Pyrmont - Germany
Phone: + 49 (0) 52 81 / 93 09 - 0
Fax: + 49 (0) 52 81 / 93 09 - 30
Internet: http://www.meinberg.de
Mail: [e-mail]
Date: 2010-09-16
LANTIME M600 GPS PTP Date: 27th October 2011 1

Page 2 2 Quick Start
2 Quick Start
When booting the system the following message will be displayed while dots will be counted up in the lower line.
Approximately one minute after power up display will change to the following screen to wait for OCXO HQ
oscillator warmed up:
MEINBERG LANTIME
is booting... please wait...
.......
Main Menu will be displayed with some important status informations after booting has nished:
NTP: Offs. 1ms Stratum: 1
MRS: sync to GPS XTL:SYNC SVs:9/10
PTP: ok PTP_SLAVE GM:00:00:00:00:00:00
Press F1 for help or F2 for setup overview
F1
UTC
Tue, 01.01.2008
12:00:00
The internal reference clock (HQ OCXO) is either controlled by an installed GPS receiver or by external time
sources (depending on Options like IRIG in or PPS in). The priorities for this regulation can be dened in the
settings. Press the following buttons to set up the MRS mode: i,g,g,g
MRS Status
-> Setup Input Priorities <-
Setup Fixed Offsets
Setup Precisions
The priorities for the external reference sources will be setup in the next menu. The reference source with the
highest priority and has been synchronized will be the master to discipline the internal OCXO of the GPS/MRS
module:
1.GPS is master : -10ns
2.PPS in is available : -20ns
3.IRIG no signal : n/a
4.NTP is available : -30.000us
2.PTP (IEEE1588)is available : -300ns
F1
MRS Input Priorities
If the GPS receiver remains asynchronous the number of satellites in view and the good satellites are to check
2 Date: 27th October 2011 LANTIME M600 GPS PTP

Page 3
(press buttons i,g,i,g,i,g from main menu). The antenna has to be installed without any obstructions to the sky.
GPS Receiver Position
-> Satellite Constellation <-
GPS Status & Version
SATELLITE CONSTELLATION
satellites in view: 5
good satellites : 5
selected set: 04 09 21 17
For rst time installation enter TCP/IP address, netmask and default gateway. To get an overview of the current
conguration press F2 from main menu. Press F2 again to enter SETUP conguration page. Please ask your
administrator for proper TCP/IP conguration:
Global Configuration
->Network Interfaces <-
Network Services
Then press 3 times the OK button to change to IPV4 ETH0 conguration page to enter the IP address, netmask
and the default gateway:
ETH0: -> DHCP:disable <-
ADDRESS: 192.168.10.20
NETMASK: 255.255.255.000
DEF.GATEWAY: 192.168.10.1
NOTE: These settings are related to the rst Ethernet connection (ETH0).
After this all further settings can be done via network interface, either by using a WEB browser or a Telnet Session.
Default user: root
Default password: timeserver
LANTIME M600 GPS PTP Date: 27th October 2011 3

Page 4 3 Network Timeserver with GPS synchronized time base
3 Network Timeserver with GPS synchronized
time base
LANTIME (Local Area Network Timeserver) provides a high precision time base to a TCP/IP network (Stratum-
1-Server). The NTP (Network Time Protocol) is used to synchronize all NTP clients with the reference. The
several LANTIME variants dier from each other by the time reference. A GPS receiver, a DCF77 receiver or an
IRIG time code receiver can be integrated as an internal reference as well as a combination of these references
(hybrid system). External references are also possible.
The time server M600/GPS/PTP is a set of equipment composed of a satellite controlled clock GPS170, a
single-board computer with integrated network board and a power supply, all installed in a metal 19" modular
chassis and ready to operate. Optionally a additional network port with hardware timestamping for the Precision
Time Protocol (PTP) IEEE1588 will be integrated. A simplied LINUX operating system is installed on the
single-board computers ash disk. Eight push buttons and a VF-Display can be used to congure and monitor
the time server. After the network connection has been established the time server can also be congured and
monitored remotely from a workstation via TELNET or FTP. An integrated HTTP server enables access to the
LANTIME by using an ordinary WEB browser.
4 Date: 27th October 2011 LANTIME M600 GPS PTP

Page 5
4 The Modular System LANTIME
LANTIME is a set of equipment composed of a satellite controlled clock GPS170, a single-board computer SBC
LX800 500 MHz with integrated network card, and a power supply unit, all installed in a metal desktop case and
ready to operate. The interfaces provided by LANTIME are accessible via connectors in the rear panel of the
case. Details of the components are described below.
ENGLISH
1. VF Display
2. Function buttons: 4-way navigation
Button; F1, F2, OK, ESC
3. Status LEDs: Ref. Time, Time Service,
Network, Alarm
4. Terminal port, RS232 Time String output
5. USB connector
6. Brackets for 19” Mounting Rack
1. VF Display
2. Function keys: 4 - way buttons;
F1, F2, OK, ESC
3. Status LEDs: Ref. Time, Time Service,
Network, Alarm
OK
ESC
Time Service
Ref. Time
Network
Alarm
Terminal
USB
5
9
1
6
F1
F2
GPS
NTP
Time
Date
: Normal Operation
: Sync. to PPS
: 16:12:35
: 12.01.2006
(hh:mm:ss)
(dd.mm.yyyy)
1 2 3 4 5 6
4. Terminal port, RS232 timestring output
5. USB connector
6. Bracket for 19” rack mount
ETH0 ETH2
ETH1 ETH3 O
I
100-240V AC
50/60Hz
Synth.
PPM
COM1
COM 0
Error
CO NO NC
16
59
16
59
PPS
TC-DCLS
10MHz
TC-mod
100M 10M100M 10M 100M 10M100M 10M
GPS
Antenna
1. Power supply 85 ... 264 V AC, 47... 63 Hz,
1 A/230 V, 2 A/115 V
2. Mains socket
3. RS232 output, serial interface, time telegram
4. Error relais output
5. GPS antenna, BNC
6. 10MHz output
7. Pulse Per Second output
8. Pulse Per Minute output
9. Frequenzy synthesizer output
10. Time code output - AM (modulated)
11. Time code output - DCLS (unmodulated)
12. IEEE1588 PTPv2, RJ-45 connector
1 x Network connector: ETH4 - 10/100 Mbit, RJ45
13. 4 x Network connectors: ETH0, ETH1,
ETH2, ETH3
10/100 Mbit, RJ45
13 12 11 10 9 8 7 6 5 4 3 2 1
100M 10M100M 10M
PTP0
IEEE1588
ETH4
The implemented NTPD distributes the reference time from the GPS receiver cyclic in the network. Information
on the NTPD is monitored on the LC display or can be inquired via the network.
The installation of LANTIME is very easy for the system/network administrator. The network address, the
netmask and the default gateway have to be congured from the front panel of LANTIME. The network address
or the equivalent name of LANTIME has to be shown to all NTP clients in the TCP/IP network.
As well as NTP the Linux system also supports a number of further network protocols: HTTP(S), FTP, SSH and
Telnet. Because of this remote conguration or status requests can come from any WEB browser. This access via
the network can be deactivated. Changes in the receiver status, errors or other important events are logged either
on the local Linux system or on an external SYSLOG-Server. In addition messages can be sent to a data center
via SNMP traps or automatically generated e-mails where they can be recorded. Furthermore all alarm messages
can be displayed by the large display VP100/20/NET that is accessed via network connection. In order to avoid
a service interruption several LANTIME NTP servers can be installed in the same network to obtain redundancy.
LANTIME M600 GPS PTP Date: 27th October 2011 5

Page 6 4 The Modular System LANTIME
4.1 Supported Network Services
The following network services are provided via RJ45 10/100Base-T Ethernet (Auto sensing):
- NTP v2, v3, v4
- NTP broadcast mode
- NTP multicast
- NTP symmetric keys
- NTP Autokey
- Simple Network Time Protocol (SNTP)
- TIME
- SNMP v1,2,3 with extended SNMP-Agent and SNMP-Traps
for NTP and reference clock status
- DHCP Client
- NFS
- TELNET
- FTP
- HTTP
- HTTPS with Openssl2
- SSH2 Secure Shell Login
- Alarm messages via e-mail
- IPv6 3 global IPv6 addresses congurable
Autoconf Feature to be disabled
supported network services: NTP, HTTP, HTTPS, SNMP, SSH
- Windows net time via NETBIOS
- Winpopup (Window Mail)
4.2 Additional Features
• external NTP timeserver
• free conguration of NTP: thereby MD5 authentication and access control via address & mask restriction
• extended menu guidance for conguration and monitoring via Telnet, SSH or serial terminal interface
• extended HTTP statistic support with long-term graphic and access statistic to NTP
• alarm messages can be displayed on external large display VP100/20/NET
• USB memory stick slot for extended functionality: software update, transfer of secure certicates, log les
and congurations, keypad locking
4.3 User Interface
• Terminal connection via serial interface, status LED
• Web browser interface with graphical statistic of the one-day cycle osets
• Telnet or Secure Shell Login for password protected operation of the Linux operating system
• FTP access for updating the operating system and downloading log les
• Simple Network Management Protocol for automatically SNMP-Traps in case of alarm
• SYSLOG messages can be passed to dierent computers
• Congurable e-mail notication
• Simulation of a synchronous radio clock in order to operate without antenna
6 Date: 27th October 2011 LANTIME M600 GPS PTP

4.4 Options Page 7
4.4 Options
• Additional Ethernet RJ45 connectors available (eight in 3U housing, four in 1U housing and eight additional
connectors in HS - XL railmount housing)
• Frequency and pulse outputs via BNC connectors (e.g. 10 MHz, 2.048 MHz, PPS)
• Higher free running accuracy with optional oscillators (OCXO)
• IRIG-B outputs
• ANZ14NET or VP100/20/NET as display connected via network
4.5 Why to use a Network Time Server?
In principle it is possible to synchronize your computers with time servers on the internet. However, a lot of our
customers rely on their own time server in their network environment for security and/or maintainability reasons.
• Particularly in the case of our LANTIME you or a responsible person can be notied by mail or SNMP trap
if there is a malfunction in your time synchronization.
• The clients on the network do not depend on an active internet connection.
• The clients on the network do not depend on the availability of an external time server.
• A test of other freely available time servers reported that many NTP servers distributed a signicantly
wrong time, although they were classied as stratum-1 time servers. This is the responsibility of the server's
administrators.
• If an internet connection is working properly then NTP can determine and account for the packet transmis-
sion delays quite reliable. However, if the internet connection is at its capacity limit, time synchronization
can be signicantly degraded due to high dispersion in packet transmission delays. Reasons for this may be
hacker attacks, which must not address your own network, or new viruses causing a huge ood of emails,
like it has already happened in the past.
In the United States the U.S. Naval Observatory (USNO) has a similar function to spread the legal time as the
PTB in Germany, and also operates publicly available NTP servers for a long time. Those NTP servers are more
and more constrained by "bad" clients, which makes the future of the public service questionable. There are
already precautions to limit the aect of such clients. Dave Mills, the originator of NTP, cooperates with the
USNO and has already adverted this in the NTP news group.
The topics outlined above should provide some arguments to install an own time server, if an accurate time
is a requirement for the reliable operation of a local network.
LANTIME M600 GPS PTP Date: 27th October 2011 7

Page 8 5 Network Time Protocol (NTP)
5 Network Time Protocol (NTP)
NTP is a common method for the synchronization of hardware clocks in local and global networks. The basic
concept, version 1 [Mills88], was published in 1988 as RFC (Request For Comments). Experiences acquired from
its practical use on the Internet was followed by version 2 [Mills89]. The NTP software package is an implemen-
tation of the actual version 3 [Mills90], based on the specication RFC-1305 from 1990 (directory doc/NOTES).
Permission to use, copy, modify and distribute this software for any purpose and without fee is hereby granted
(read File COPYRIGHT).
NTP operates in a way that is basically dierent from that of most other timing protocols. NTP does not
synchronize all connected clocks; instead it forms a hierarchy of timeservers and clients. Each level in this hier-
archy is called a stratum, and Stratum 1 is the highest level. Timeservers at this level synchronize themselves by
means of a reference time source such as a radio controlled clock, satelliet receiver or modem time distribution.
Stratum 1 Servers distribute their time to several clients in the network which are called Stratum 2.
Highly precise synchronization is feasible because of the several time references. Every computer synchronizes
itself with up to three valued time sources. NTP enables the comparison of the hardware times and the adjustment
of the internal clock. A time precision of 128 ms, and often better than 1 ms, is possible.
5.1 NTP Target
The NTP software package was tested on dierent UNIX systems. Many UNIX systems have an NTP client pre-
installed. Only some basic congurations need to be done (/etc/ntp.conf). NTP clients as freeware or shareware
are also available for most other operating systems like Windows 7/Vista/XP/NT/2000/98/95/3x, OS2 or MAC.
The following WEB site is recommended to get the latest version of NTP:
http://www.eecis.udel.edu/ ntp/
You can nd more information on our web page at: http://www.meinberg.de/english/sw/ntp.htm
5.2 NTP-Client Installation
The following example shows the installation of a NTP client under UNIX. First make sure that there is no NTP
installed on your computer because many UNIX operating systems include NTP already.
The shipped source code of the NTP daemon has to be compiled on the target system. Using the enclosed
script le congures the compilation of the NTP daemon and all tools.
congure
All necessary information from the system will be collected and the corresponding make les will be generated in
the subdirectories.
After that the NTP daemon and all needed utilities will be generated. Therefore type:
make
While compiling the NTP daemon several warnings may appear. These warnings are mostly unimportant. In case
of problems during the compilation read the system dependent notes in the subdirectory `html'.
Afterwards the generated programs and tools have to be moved in the corresponding directories. Therefore type:
make install
The time adjustment can occur in dierent ways. Either the system time can be set once by using the tool "ntp-
date lantime" or the NTPD daemon is started. In the rst case it is recommended to set the time automatically
with "cron" or once when booting the system. The second case is described below.
8 Date: 27th October 2011 LANTIME M600 GPS PTP

5.2 NTP-Client Installation Page 9
First a le named /etc/ntp.conf has to be generated with an editor. Adapting the le to Meinberg LANTIME it
should contain the following:
# Example for /etc/ntp.conf for Meinberg LANTIME
server 127.127.1.0 # local clock
server 172.16.3.35 # TCPIP address of LANTIME
# optional: Driftle
# driftle /etc/ntp.drift
# optional: activate all messages in syslogle
# logcong =all
The NTP daemon is started with 'ntpd' or, using 'rc.local', while booting the system. Status messages during
operation are saved in /var/adm/messages and /var/adm/syslog (corresponding to the syslog conguration).
e.g.: tail /var/log/messages
Shows the last lines from the le messages . The status messages can also be redirected in a log le by using the
following option:
ntpd -llogle
The command 'ntpq' in the directory ntpq requests the actual status of the NTP daemon (see also doc/ntpq.8).
e.g.: ntpq/ntpq
An interpreter appears; Type "?" for a list of all available commands. The command 'peer' is used to list all
active reference clocks:
         

         
         
with the following meaning:
- remote: list of all valid time servers (ntp.conf)
- red: reference number
- st: actual stratum value (hierarchy level)
- when: last request (seconds)
- poll: period of requesting the time server (seconds)
- reach: octal notation of the successful requests, shifted left
- delay: delay of the network transmission (milliseconds)
- oset: dierence between system time and reference time
(milliseconds)
- jitter: variance of the osets (milliseconds)
Repeatedly 'peer' commands lets the user observe the accuracy of the NTP daemon. Every 64 seconds (value
of -poll) a new time string is red in from the radio clock. The NTP daemon needs approx. 3...5 minutes for
initialisation. This is indicated by a wildcard (*) on the left side of the remote name.
The NTP daemon terminates itself if the system time diers from the UTC time by more than 1024 seconds.
This often happens when the time zone is not correctly set (see also system manual "zic" or "man zic").
LANTIME M600 GPS PTP Date: 27th October 2011 9

Page 10 6 Precision Time Protocol (PTP) / IEEE1588
6 Precision Time Protocol (PTP) / IEEE1588
Precision Time Protocol (PTP or IEEE 1588) is a time synchronization protocol that oers sub-microsecond ac-
curacy over a standard Ethernet connection. This accuracy can be achieved by adding a hardware timestamping
unit to the network ports that are used for PTP time synchronization. The timestamping unit captures the exact
time when a PTP synchronization packet is sent or received. These timestamps are then taken into account to
compensate for transfer delays introduced by the Ethernet network.
In PTP networks there is only one recognized active source of time, referred to as the Grandmaster Clock.
If two or more Grandmaster Clocks exist in a single network, an algorithm dened in the PTP standard is used to
determine which one is the best source of time. This Best Master Clock algorithm must be implemented on
every PTP/IEEE1588 compliant system to insure that all clients (Slave Clocks) will select the same Grandmas-
ter. The remaining deselected Grandmaster Clocks will step back and enter a passive mode, meaning that they
do not send synchronization packets as long as that is being done by the designated Grandmaster.
The existing network infrastructure components play a big role in a PTP network and directly inuence the
level of accuracy that can be achieved by the clients. Asymmetric network connections degrade the accuracy,
therefore classic layer 2 and 3 Ethernet switches with their store and forward technology are not suitable for
PTP networks and should be avoided. With activating the HQ-Filter (see chapter HQ-Filter) the Jitter can be
eliminated. Simple Ethernet hubs with xed pass-through times are not a problem. In large networks, special
switches with built-in PTP functionality help to maintain high accuracy even over several subnets and longer
distances. These components act as "Boundary Clocks" (BC) or "Transparent Clocks" (TC). They compensate
their internal packet processing times by using timestamping units on each port. When acting as a Boundary
Clock, they synchronize to the Grandmaster clock, and in turn act as a Master to the other subnets they are
connected to. When acting as a Transparent Clock, then the "residence time" of the Masters' Sync-Packet is
measured and added to the packet as a correction value. Internally the PTP timescale TAI (see chapter Timescale
in Global Parameters).
6.1 General Information
The internal PTP card acts as a network interface card (10/100MBit) with an integrated hardware time stamp
unit to obtain time stamps in PTP compatible networks. In conjunction with a single board computer running
the PTP protocol stack and a reference time source (PTP master only) the module is capable of building a PTP
Master or Slave system:
10/100MBit
LAN
Network Interface Card
PTP Time Stamp Unit
Single Board Computer
PTP Protocol Stack
Reference Time Source
GPS Receiver
PTP Master System only
USB
PPS10MHz
10 Date: 27th October 2011 LANTIME M600 GPS PTP

6.2 Functionality in Master Systems Page 11
The Time Stamp Unit, integrated in an FPGA (Field Programmable Gate Array, a programmable logic device),
checks the data trac on the MII-interface between the PHY receiver (physical connection to the network) and
the Ethernet controller (MAC) on the PTP module. If a valid PTP packet is detected, the time stamp unit takes
a time stamp of that packet which is read by a single board computer (SBC) running the PTP software. The
conguration and status trac between the PTP board and main SBC is done over a USB connection.
6.2 Functionality in Master Systems
10/100MBit
LAN
10 Mhz from GPS
RJ45 with
magnetics
and LEDs
PHYceiver MAC
controller USB hub
FPGA
microcontroller
with integrated
progr. memory
10M/activity
100M/activity
Rx/Tx
MII interface USB
USB 1.1
to computer
module
Time Stamp Unit PTP Master
FPGA
configuration
memory
PPS from GPS
control
adr/data
control
data
USB
After power up, the module accepts the absolute time information (PTP seconds) of a reference time source
(GPS reference clock) only once, and the PTP nanoseconds are set to zero. If the oscillator frequency of the
reference time source has reached its nominal value, the nanoseconds are reset again. This procedure leads to a
maximum deviation of 20 nsec of the pulse per second (1PPS) of the PTP Master compared to the 1PPS of the
GPS reference clock. The reference clock of the PTP board's time stamp unit (50 MHz) is derived from the GPS
disciplined oscillator of the reference time source using a PLL (Phase Locked Loop) of the FPGA. The achieves
a direct coupling of the time stamp unit to the GPS system.
6.3 Functionality in Slave Systems
10/100MBit
LAN
10 MHz
PPS
programmable
outputs
modulated
time code
RJ45 with
magnetics
and LEDs
PHYceiver MAC
controller USB hub
status LEDs
driver
circuits
FPGA
filter and
driver circuit oscillator DAC
microcontroller
with integrated
progr. memory
FPGA
configuration
memory
10M/activity
100M/activity
Rx/Tx
MII interface
USB
USB
data control
control
control
voltage
PWM time code
clock
adr/data
control
USB 1.1
to computer
module
clock
status
Time Stamp Unit PTP Slave
After decoding valid time information from a PTP Master, the system sets its own PTP seconds and nanoseconds
accordingly. The PTP oset calculated by the PTP driver software of the single board computer is used to adjust
the master oscillator of the TSU-USB. This allows the PTP Slave to generate very high accuracy output signals
(10 MHz/1PPS/IRIG).
LANTIME M600 GPS PTP Date: 27th October 2011 11

Page 12 6 Precision Time Protocol (PTP) / IEEE1588
6.4 PTPv2 IEEE 1588-2008 Configuration Guide
Setting up all devices in a PTP synchronization infrastructure is one of the most important parts in a network
time synchronization project. The settings of the involved Grandmaster clocks as the source of time and the end
devices (Slaves) have to match in order to allow them to synchronize and avoid problems later, when the PTP
infrastructure is deployed to production environments. In addition to that, the use of PTP aware network infras-
tructure components, namely network switches, introduces another set of parameters that have to be harmonized
with the masters and slaves in a PTP setup.
It is therefore very important to start with making decisions how the to-be-installed PTP synchronization so-
lution should operate, e.g. should the communication between the devices be based on multicast or unicast
network trac or how often should the masters send SYNC messages to the slaves.
This chapter lists the most important options and their implications on a synchronization environment in general.
A detailed explanation of the conguration settings within the LANTIME conguration interfaces can be found
later within this documentation.
6.4.1 General Options
The following general mode options have to be decided before deploying the infrastructure:
1) Layer 2 (Ethernet) or Layer 3 (UDP/IPv4) connections
2) Multicast or Unicast
3) Two-Step or One-Step Operation
4) End-to-End or Peer-to-Peer Delay Mechanism
The above options need to be dened for the whole setup, if devices do not stick to the same settings, they will
not be able to establish a working synchronization link.
6.4.2 Network Layer 2 or Layer 3
PTP/IEEE 1588-2008 oers a number of so-called mappings on dierent network communication layers. For
Meinberg products you can choose between running PTP over IEEE 802.3 Ethernet connections (network Layer
2) or UDP/IPv4 connections (Layer 3).
Layer 3 is the recommended mode, because it works in most environments. For Layer 2 mode the network
needs to be able to provide Ethernet connections between master and slave devices, which is often not the case
when your network is divided into dierent network segments and you have no layer 2 routing capabilities in your
network infrastructure.
The only benet of using Layer 2 mode would be a reduced trac load, because the transmitted network frames
do not need to include the IP and UDP header, saving 28 bytes per PTP packet/frame. Due to the fact that PTP
is a low trac protocol (when compared to other protocols), the reduced bandwidth consumption only plays a
role when low-bandwidth network links (e.g. 2Mbit/s) have to be used or in pay-per-trac scenarios, for example
over leased-line connections.
6.4.3 Multicast or Unicast
The initial version of PTP (IEEE 1588-2002 also known as PTPv1) was a multicast-only protocol. Multicast
mode has the great advantage that the master clock needs to send only one SYNC packet to a Multicast address
and it is received by all slave devices that listen to that multicast address.
In version 2 of the protocol (IEEE 1588-2008) the unicast mode was introduced in addition to the multicast
mode. In unicast mode, the master has to send one packet each to every slave device, requiring much more CPU
performance on the master and producing orders of magnitudes more trac.
On the other hand, some switches might block multicast trac, so that in certain environments, Unicast mode
has to be used.
12 Date: 27th October 2011 LANTIME M600 GPS PTP

6.4 PTPv2 IEEE 1588-2008 Conguration Guide Page 13
6.4.4 Two-Step or One-Step
The PTP protocol requires the master to periodically send SYNC messages to the slave devices. The hardware time
stamping approach of PTP requires that the master records the exact time when such a SYNC packet is going on
the network wire and needs to communicate this time stamp to the slaves. This can be achieved by either sending
this time stamp in a separate packet (a so-called FOLLOW-UP message) or by directly manipulating the outgo-
ing SYNC message, writing the hardware time stamp directly into the packet just before it leaves the network port.
At the time of delivery of this product, Meinberg devices support only the former approach, called Two-Step
(because two packets are required).
6.4.5 End-To-End (E2E) or Peer-To-Peer (P2P) Delay Measurements
In addition to receiving the SYNC/FOLLOWUP messages a PTP slave device needs to be able to measure the
network delay, i.e. the time it took the SYNC message to traverse the network path between the master and
the slave. This delay is required to correct the received time information accordingly and it is measured by the
slave in a congured interval (more about the message intervals later). A delay measurement is performed by
sending a so-called DELAY_REQUEST to the master which timestamps it and returns the timestamp in a DE-
LAY_RESPONSE message.
IEEE 1588-2008 oers two dierent mechanisms for performing the delay measurements. A slave can either
measure the delay all the way to the master, this is called End-To-End (or E2E in short) or to its direct network
neighbors (which would in almost all cases be a switch  or two in a redundant setup), using the Peer-To-Peer
delay measurement mechanism (P2P). The delay measurements of all links between the master and the slave are
then added and accumulated while a SYNC packet is traversing the network.
The advantage of this method is that it can dramatically reduce the degradation of accuracy after topology
changes. For example: in a redundant network ring topology the network delay will be aected when the ring
breaks open and network trac needs to be redirected and ows into the other direction. A PTP slave in a sync
infrastructure using E2E would in this case apply the wrong delay correction calculations until it performs the
next delay measurement (and nds out that the network path delay has changed). The same scenario in a P2P
setup would see much less time error, because the delay of all changed network links were already available.
The drawback: the P2P approach requires that all involved PTP devices and all switches support this mech-
anism. A switch/hub without P2P support would in the best case simply pass the so-called PDELAY messages
through and as a result degrade the accuracy of the delay measurements. In the worst case it would block/drop
the PDELAY messages completely, which eectively would result in no delay measurements at all.
So, E2E is the only available choice if you are running PTP trac through non-PTP-aware switches. It is a
reasonable choice if you are not using redundant network topologies or can accept that the delay measurements
are wrong for a certain amount of time.
6.4.6 Mode Recommendations
Meinberg recommends to set up your PTP infrastructure to use Layer 3, Multicast, Two-Step and End-To-
End Delay measurements if that is possible. This will provide the largest possible compatibility and reduces
interoperability problems.
6.4.7 Message Rate Settings
The decision between the dierent general mode options is mainly dictated on the network environment in which
the PTP infrastructure is installed.
In addition to the mode selection, a number of intervals for certain types of PTP network messages needs to be
dened. In most cases, the default values as dened in the standard are a safe bet, but there are applications and
scenarios where a custom message rate is required.
A possible example is a situation where the PTP infrastructure is integrated within an environment with high
network load. In this case, the PTP packets can be aected by the eect of packet delay variation (PDV). An
increase of the PTP message rate(s) can avoid synchronization problems due to packet queuing within non-PTP
compliant switches which might cause false measurements. At higher rates, these false measurements can be
detected and corrected faster as compared to lower rates at the cost of increased trac.
LANTIME M600 GPS PTP Date: 27th October 2011 13

Page 14 6 Precision Time Protocol (PTP) / IEEE1588
The message rates for the following message types can be changed:
1) ANNOUNCE messages
2) SYNC/FOLLOWUP messages
3) (P)DELAY_REQUEST messages
6.4.8 ANNOUNCE Messages
These PTP messages are used to inform the PTP network participants about existing and available master clock
devices. They include a number of values that indicate the potential synchronization accuracy.
The procedure used to decide which of the available devices (that could become masters) is selected is called the
best master clock algorithm (BMCA). The values that are used in this BMCA are read from the ANNOUNCE
messages that potential masters send out periodically.
The rate at which these messages are sent out are directly aecting the time that is required by a slave de-
vice to select a master and to switch to a dierent master in case the selected one fails.
Multiple devices can simultaneously transmit ANNOUNCE messages during periods in which no master has
been selected (yet). This happens for example when a PTP network is powered up, i.e. all devices are starting
to work at the same time. In this case all devices that consider themselves (based on their conguration and
status) being capable of providing synchronization to all the other PTP devices will start to send out ANNOUNCE
messages. They will receive the other candidates' ANNOUNCE messages as well and perform the BMCA. If they
determine that another candidate is more suitable to become the master clock, they stop sending ANNOUNCE
messages and either become slave devices or go into "PASSIVE" mode, waiting for the selected master to stop
sending ANNOUNCE messages. This is determined to be the case when no ANNOUNCE message is received
within 3 ANNOUNCE message intervals.
As an example, if the ANNOUNCE interval has been congured to be 2 seconds (one message every 2 sec-
onds, the default value), the master is considered to have failed when no message has been received for 6 seconds.
In order to choose a master (a backup master clock or the primary one during initialization) the devices re-
quire to receive at least two consecutive ANNOUNCE messages. Continuing our example, it would take the 6
seconds to determine that the current master has failed and another 4 seconds to select the new one. That
means an ANNOUNCE interval of 2 seconds translates into at least 10 seconds of switching time and 4 seconds
of initial master clock selection time. So, choosing a shorter ANNOUNCE message interval will allow a faster
switching to a backup master clock, but it can lead to false positives when the chosen interval is too short for
the network environment.
6.4.9 SYNC/FOLLOWUP Messages
The selected master clock sends out SYNC (and, in Two-Step environments, the corresponding FOLLOWUP)
messages in a congured interval. This interval (default value is one SYNC/FOLLOWUP packet every second)
determines how often the slave devices receive synchronization data that allows them to adjust their internal
clocks in order to follow the master clock time. Between receiving two SYNC messages, a slave clock runs free
with the stability determined by its own internal time base, for example a crystal oscillator. One important factor
for deciding on the SYNC interval is the stability of this oscillator. A very good oscillator requires a lower SYNC
message rate than a cheaper, low-accuracy model. On the other hand you directly aect the required network
bandwidth by changing the SYNC interval.
For Meinberg slave devices, the default one-SYNC-every-second setting is more than enough to achieve the
highest possible synchronization accuracy.
6.4.10 (P)DELAY REQUEST Messages
As explained in the General Mode Options chapter (see the End-To-End or Peer-to-Peer section), the delay
measurements are an important factor for achieving the required accuracy. Especially in E2E mode, the network
path delay measurements play a crucial part in the synchronization process. Per default, the slaves will perform
delay measurements every 8 seconds, resulting in sending and receiving one packet. This can be increased in case
the network path delay variation in the network is relatively large (i.e. the time it takes for the SYNC message
14 Date: 27th October 2011 LANTIME M600 GPS PTP