Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Automatich System Time correction - possible? 2
- Thread starter MPH123
- Start date
-
1
- #2
you can use network time sync, then clock the main site off of your network.. ld 2 has the commands and the timezone offsets.. here's a procomm script that sync's anysite from the pc when you logi.. i use this to keep this site in sync with the users pc.. this one works here because i log in 10 times a day, if it were a less active site i would schedule it to run via a master script.. i have built those for other sites that run all the time, they do a few stat's, capture midnight, inv prt, etc.. then i make my save path a network drive.. that gives a main site access to standard maint screen captures to watch for pending trouble.. here's the logi and sync time script..
if you don't want to use that as a logi script, then just use myproc and do the call from any script..
john poole
bellsouth business
columbia,sc
Code:
proc main
set txpace 50
transmit "****^M"
waitfor ">"
transmit "john^M"
transmit "****^M"
waitfor ">"
transmit "logi xxxxx^M"
pause 1
transmit "xxxxxxx^M"
call myproc
endproc
proc myproc
integer iDay, iMonth, iYear, iMin, iHour, iSec
string sSend
ltimeints $LTIME iYear iMonth iDay iHour iMin iSec
strfmt sSend "STAD %02d %02d %d %02d %02d %02d" iDay iMonth iYear iHour iMin iSec
set txpace 30
transmit "****^M"
waitfor ">"
; pause 6
transmit "ld 2^M"
waitfor "."
transmit "TTAD^M"
waitfor "."
transmit sSend
transmit "^M"
waitfor "."
pause 2
transmit "TTAD^M"
pause 2
transmit "****^M"
endprocif you don't want to use that as a logi script, then just use myproc and do the call from any script..
john poole
bellsouth business
columbia,sc
- Thread starter
- #3
John,
We do not use Procom at all. The sites are all 'stand alone' and have no interconnects, they only have carrier network.
If I read the NTPs correctly, we will have to monitor the drift over a period to ascertain the drift, then do the 'correction' in LD2, so the clock is adjusted accordingly. Is this correct? Looks/Sounds horrendous!
If there is a method of using network time sync then I would prefer to use it. Can you assist?
I'm out of my depth here, so your help is appreciated.
Regards
Jimbo
We do not use Procom at all. The sites are all 'stand alone' and have no interconnects, they only have carrier network.
If I read the NTPs correctly, we will have to monitor the drift over a period to ascertain the drift, then do the 'correction' in LD2, so the clock is adjusted accordingly. Is this correct? Looks/Sounds horrendous!
If there is a method of using network time sync then I would prefer to use it. Can you assist?
I'm out of my depth here, so your help is appreciated.
Regards
Jimbo
You can adjust time by 10ms increments/decrements by day. The best is to implement Network Time Synchro with a Master site and all other slaves sites. You will only have to adjust the Master...
Read LD 2 NTPs for details
With Signaling Server, i have just see that it's possible to synchronize time with SNTP. I will try it next week.
Read LD 2 NTPs for details
With Signaling Server, i have just see that it's possible to synchronize time with SNTP. I will try it next week.
************************************************
For network time Synchro:
LD 2 Site 1 Site 2 Site 3
STSS MAST SLAV SLAV
STSC 0 0 0
SLDN 110991 110992 110993
SMDN 110992 110991 110991
SDEL 0 00 00 0 00 00 0 00 00
SMOD BKGD BKGD BKGD
Then each slave site must have DSC=110991 in that example
Master must have DSC 110992 and 110993
************************************************
For daily time adjustement:
To print the current adjustment: TDTA X y
To set the adjustment: SDTA X y -- X Y
Legend
x = 0 (negative increment) or 1 (positive increment)
y = 0-60 second adjustment in increments of 100 ms
************************************************
For network time Synchro:
LD 2 Site 1 Site 2 Site 3
STSS MAST SLAV SLAV
STSC 0 0 0
SLDN 110991 110992 110993
SMDN 110992 110991 110991
SDEL 0 00 00 0 00 00 0 00 00
SMOD BKGD BKGD BKGD
Then each slave site must have DSC=110991 in that example
Master must have DSC 110992 and 110993
************************************************
For daily time adjustement:
To print the current adjustment: TDTA X y
To set the adjustment: SDTA X y -- X Y
Legend
x = 0 (negative increment) or 1 (positive increment)
y = 0-60 second adjustment in increments of 100 ms
************************************************
-
1
- #7
Firebird Scrambler
Systems Engineer
Is this of any help to you jimbo?
Network Time Synchronization
The Network Time Synchronization feature is designed to ensure that all time
stamps in a network are synchronized from one source.
One switch becomes the master for this purpose.
In a private network environment, each switch in the network has an
individual system clock. These system clocks can, under certain conditions,
lose or gain time, causing inaccurate time stamps for different features.
Also, in a private network, several switches can be located in different time
zones. As features become more centralized in a network environment, it is
useful to have time stamps based on one time zone.
To provide Time Synchronization on a network-wide basis, Meridian
Customer Defined Integrated Services Digital Network (ISDN) nodes can
request Time Synchronization from another node, using D-channel messages.
Therefore, Slave switches can request the time from the Master switch, while
the Master switch can do the same to a Backup node.
A time difference (or delta) is provided for every node, in order to distinguish
time zones for time usage by local features (e.g., Automatic Wake-up) and
centralized ones (e.g., Centralized Call Detail Recording).
The Time Synchronization request messages are composed of:
• the message identifier
• the requester's ID
• the time
• the date
• the time-adjust factor
IDs are virtual DNs, and are used to route the messages.
On the Slaves, Time Synchronization requests are sent automatically under
the background routines (default setup) or with the daily routines (optional
setup), every time a time change is performed (to accurately set the seconds),
and on every SYSLOAD and initialization.
On the Master, Time Synchronization requests are sent to a Backup node
upon initialization and, therefore, after SYSLOAD. The Master will be
forbidden to synchronize Slave switches during these backup periods. In the
rare event where Master and Backup nodes would start requesting
synchronization at the same time, the real time will be considered to be on the
Slave node, if it is not initializing. If both nodes are only initializing,
the real time would be considered to be carried by the Master switch. If a SYSLOAD occurs at the Master and the Slave is initializing, the real time would be considered to be carried by the Slave switch. A warning message will be
printed if both switches SYSLOAD, and all Time Synchronization would be
put to a halt until the Master’s clock is reset.
If no answer is received on the first time synchronization request (by the end
of the request time-out), extra Time Synchronization requests will be sent. If
there is still no answer on the third time synchronization request, a warning
message will be issued.
Note 1: Upon SYSLOAD, the clock starts on time zero, while upon
initialization, only the seconds are lost.
Note 2: Through service change (LD 2) or through an Attendant
Console, the clock can be reset to the correct time if desired. If the
Network Time Synchronization feature is on, then the Master will be
requested for synchronization upon these service changes (to permit fine
synchronization).
Operating parameters
This feature uses D-channel messaging over a Meridian Customer Defined
Integrated Services Digital Network (ISDN).
Feature interactions
Time-of-day Adjustment
Every time LD 2 is used to change the system time, a request for
synchronization will be made of the Master to accurately set the seconds.
Time and Date (TAD) Attendant key
As done with LD 2, every time the TAD key is used to change the system
time, a request for synchronization will be made to the Master to accurately
set the seconds.
Call Detail Recording (CDR)
Upon receipt of synchronization messages, Slave switches will issue CDR
records (if so equipped) for monitoring the feature. These CDR records will
be identical to those issued by a time change performed in LD 2 or by an
attendant’s TAD key.
Feature packaging
This feature is included with the Integrated Services Digital Network
Supplementary Features (ISDNS) package 161.
Feature implementation
The following parameters are used to configure Network Time
Synchronization:
• Node Status: Can either be Master, Slave, or standard stand-alone node
(MAST, SLAV or STDA).
• Customer Number: Customer that will issue and receive the Network
Time Synchronization messages. The default value is “0”. For a change
(only possible on switches with the multi-customer package) to be
accepted, the customer should already exist. Furthermore, the Local DN
has to be reentered.
• Local DN: Virtual DN (access code included) dedicated for
synchronization services on the Local node; up to 16 digits. A call with
these routing digits should terminate on the previously designated
customer.
• Master or Backup DN: Virtual DN (access code included) dedicated for
synchronization services on the Master or Backup node; up to 16 digits.
• Time Delta: Time difference added to the local time in order to get the
Master or Backup time. The entry is prefixed with the digit 1 for positive
and 0 for negative.
• Requesting mode: Operating mode used to request the time
synchronization messages (i.e., with the background routines (default
setup) or with the daily services (BKGD or DSVC)).
Note: The Node Status, Customer Number, Local DN, and Master or
Backup DN parameters must be configured for the Network Time
Synchronization feature to be operational.
Task summary list
The following is a summary of the tasks in this section:
1 LD 2 – Define entries for the Network Time Synchronization feature.
2 LD 22 – Print the DN type for the Network Time Synchronization
Virtual DN. The DN type is “TIME”.
LD 2 – Define entries for the Network Time Synchronization
feature.
The following commands are Network Time Synchronization feature
specific:
Query Node Status (Type Time Synchronization Status).
The command format is:
INPUTOUTPUT
.TTSS.TTSS (STATUS)
Example:
.TTSS.TTSS MAST
Set Node Status (Set Time Synchronization Status).
The command format is:
.STSS (status)
where status can be:
STDA — stand-alone (default)
MAST — Master
SLAV — Slave
Example:
.STSS SLAV
Query Customer in charge (Type Time Synchronization Customer).
The command format is:
INPUTOUTPUT
.TTSC.TTSC (CUSTOMER NUMBER)
Example:
.TTSC.TTSC 5
Set Customer in charge (Set Time Synchronization Customer).
The command format is:
.STSC (customer number)
where customer can be:
0 - 99 — 0 is default.
Example:
.STSC 5
Query Local Virtual DN (Type Local DN).
The command format is:
INPUTOUTPUT
.TLDN.TLDN (DN)
Example (for 6 = ESN access code, 613 = ESN location code, 5999 = DN):
.TLDN.TLDN 66135999
.SLDN (dn)
Example:
.SLDN 66135999 DN).
INPUTOUTPUT
Set Local Virtual DN (Set Local DN).
The command format is:
Query Master or Backup Time Synchronization Number (Type Master
The command format is: .TMDN.TMDN (DN)
Example (for 6 = Outside line, 514 = ESN code, 3999 = DN):
.TMDN.TMDN 65143999
Set Master or Backup Time Synchronization Number (Set Master DN).
The command format is:
.SMDN (dn)
Example:
.SMDN 65143999
Query Time Delta.
The command format is:
INPUT OUTPUT
.TDEL.TDEL (SIGN) (HR) (MIN)
Example:
.TDEL.TDEL 0 01 30
Set Time Delta.
The command format is:
.SDEL (sign) (hr) (min)
where:
sign – is the time-adjust factor direction indicator which can be:
0 — to indicate the Master switch is behind in time.
or
1 — to indicate the Master switch is ahead in time.
hr – is the number of hours the time must be adjusted by and can
be any number from 0 to 23, and
min – is the number of minutes the time must be adjusted by and
can be any number from 0 to 59.
0 is the default for the SDEL parameters.
Example:
.SDEL 1 23 00
Note: The hour and minute entries are two digits. The minute entry is
defaulted to zero if not entered. “1” identifies a positive delta (Master is
ahead in time), “0” identifies a negative delta.
Example:
Query Requesting Mode (Type MODe).
The command format is:
INPUT OUTPUT
.TMOD.TMOD (MODE)
.TMOD.TMOD BKGD
Set Requesting Mode (Set MODe).
The command format is:
.SMOD (mode)
where mode can be:
BKGD — Background (default)
or
DSVC — Daily Service (midnight)
Example:
.SMOD DSVC
LD 22 – Print the DN type for the Network Time Synchronization
Virtual DN. The DN type is “TIME”.
Feature operation
Each node of the network that is to be synchronized sets its status (i.e.,
Master, Slave, or Standard stand-alone (the feature is not used)). The
craftsperson also sets the node's customer in charge of synchronizing the
switch (that customer will request Time Synchronization and receive the time
from the Master or Backup switch). The customer must already exist, prior to
referencing it, and then sets the local access codes with the virtual DN, the
Master (or Backup) routing digits, the time difference between local and
Master nodes, and the requesting mode (for example, performed under the
background routines (default) or the daily services. The time delta and the
requesting mode are optional entries).
The time synchronization feature is designed to work in a Meridian Customer
Defined Integrated Services Digital Network (ISDN) environment, using
D-channel messages. The synchronization messages are carried by TCAP
facility messages on a Meridian Customer Defined ISDN, and routed
according to the configuration defined in LD 2.
Once the configuration is defined in LD 2, the Slaves will automatically start
requesting “time-stamps” from the Master periodically, upon initialize, and
when the time and date is changed in LD 2. The message to be sent is
identified as being a time synchronization request. The stored Master's
routing digits (access codes + virtual DN) are used to route the
synchronization requests. As part of the request, the requester's access
codes + virtual DN is sent to provide the Master with a way back to the
requesting node.
Upon receipt at the Master node, the terminating DN is recognized as being a
time synchronization virtual DN, and the request is then processed. The
processing consists of constructing a message, identified as being a time
synchronization response and originating from that virtual DN, which
includes:
• time
• date, and
• time-adjust factor (if used).
The message is then routed to the Slave using the access codes and virtual DN
provided with the request. The time-adjust factor is sent to all Slaves in order
to have the whole network correct any inaccurate clock settings in unison, if
any slippage correction is necessary.
Up to three requests will be sent at one minute intervals, to allow the system
to overcome possible temporary malfunctions. On receipt of the time
message, the requester verifies the originator's ID (its virtual DN), and
updates its clock accordingly (i.e., equal to the time sent minus the time delta
between the two switches). If equipped with the CDR package, a time change
record is provided with every time synchronization occurrence.
All the best
Firebird Scrambler
Meridian Programmer in the UK
Network Time Synchronization
The Network Time Synchronization feature is designed to ensure that all time
stamps in a network are synchronized from one source.
One switch becomes the master for this purpose.
In a private network environment, each switch in the network has an
individual system clock. These system clocks can, under certain conditions,
lose or gain time, causing inaccurate time stamps for different features.
Also, in a private network, several switches can be located in different time
zones. As features become more centralized in a network environment, it is
useful to have time stamps based on one time zone.
To provide Time Synchronization on a network-wide basis, Meridian
Customer Defined Integrated Services Digital Network (ISDN) nodes can
request Time Synchronization from another node, using D-channel messages.
Therefore, Slave switches can request the time from the Master switch, while
the Master switch can do the same to a Backup node.
A time difference (or delta) is provided for every node, in order to distinguish
time zones for time usage by local features (e.g., Automatic Wake-up) and
centralized ones (e.g., Centralized Call Detail Recording).
The Time Synchronization request messages are composed of:
• the message identifier
• the requester's ID
• the time
• the date
• the time-adjust factor
IDs are virtual DNs, and are used to route the messages.
On the Slaves, Time Synchronization requests are sent automatically under
the background routines (default setup) or with the daily routines (optional
setup), every time a time change is performed (to accurately set the seconds),
and on every SYSLOAD and initialization.
On the Master, Time Synchronization requests are sent to a Backup node
upon initialization and, therefore, after SYSLOAD. The Master will be
forbidden to synchronize Slave switches during these backup periods. In the
rare event where Master and Backup nodes would start requesting
synchronization at the same time, the real time will be considered to be on the
Slave node, if it is not initializing. If both nodes are only initializing,
the real time would be considered to be carried by the Master switch. If a SYSLOAD occurs at the Master and the Slave is initializing, the real time would be considered to be carried by the Slave switch. A warning message will be
printed if both switches SYSLOAD, and all Time Synchronization would be
put to a halt until the Master’s clock is reset.
If no answer is received on the first time synchronization request (by the end
of the request time-out), extra Time Synchronization requests will be sent. If
there is still no answer on the third time synchronization request, a warning
message will be issued.
Note 1: Upon SYSLOAD, the clock starts on time zero, while upon
initialization, only the seconds are lost.
Note 2: Through service change (LD 2) or through an Attendant
Console, the clock can be reset to the correct time if desired. If the
Network Time Synchronization feature is on, then the Master will be
requested for synchronization upon these service changes (to permit fine
synchronization).
Operating parameters
This feature uses D-channel messaging over a Meridian Customer Defined
Integrated Services Digital Network (ISDN).
Feature interactions
Time-of-day Adjustment
Every time LD 2 is used to change the system time, a request for
synchronization will be made of the Master to accurately set the seconds.
Time and Date (TAD) Attendant key
As done with LD 2, every time the TAD key is used to change the system
time, a request for synchronization will be made to the Master to accurately
set the seconds.
Call Detail Recording (CDR)
Upon receipt of synchronization messages, Slave switches will issue CDR
records (if so equipped) for monitoring the feature. These CDR records will
be identical to those issued by a time change performed in LD 2 or by an
attendant’s TAD key.
Feature packaging
This feature is included with the Integrated Services Digital Network
Supplementary Features (ISDNS) package 161.
Feature implementation
The following parameters are used to configure Network Time
Synchronization:
• Node Status: Can either be Master, Slave, or standard stand-alone node
(MAST, SLAV or STDA).
• Customer Number: Customer that will issue and receive the Network
Time Synchronization messages. The default value is “0”. For a change
(only possible on switches with the multi-customer package) to be
accepted, the customer should already exist. Furthermore, the Local DN
has to be reentered.
• Local DN: Virtual DN (access code included) dedicated for
synchronization services on the Local node; up to 16 digits. A call with
these routing digits should terminate on the previously designated
customer.
• Master or Backup DN: Virtual DN (access code included) dedicated for
synchronization services on the Master or Backup node; up to 16 digits.
• Time Delta: Time difference added to the local time in order to get the
Master or Backup time. The entry is prefixed with the digit 1 for positive
and 0 for negative.
• Requesting mode: Operating mode used to request the time
synchronization messages (i.e., with the background routines (default
setup) or with the daily services (BKGD or DSVC)).
Note: The Node Status, Customer Number, Local DN, and Master or
Backup DN parameters must be configured for the Network Time
Synchronization feature to be operational.
Task summary list
The following is a summary of the tasks in this section:
1 LD 2 – Define entries for the Network Time Synchronization feature.
2 LD 22 – Print the DN type for the Network Time Synchronization
Virtual DN. The DN type is “TIME”.
LD 2 – Define entries for the Network Time Synchronization
feature.
The following commands are Network Time Synchronization feature
specific:
Query Node Status (Type Time Synchronization Status).
The command format is:
INPUTOUTPUT
.TTSS.TTSS (STATUS)
Example:
.TTSS.TTSS MAST
Set Node Status (Set Time Synchronization Status).
The command format is:
.STSS (status)
where status can be:
STDA — stand-alone (default)
MAST — Master
SLAV — Slave
Example:
.STSS SLAV
Query Customer in charge (Type Time Synchronization Customer).
The command format is:
INPUTOUTPUT
.TTSC.TTSC (CUSTOMER NUMBER)
Example:
.TTSC.TTSC 5
Set Customer in charge (Set Time Synchronization Customer).
The command format is:
.STSC (customer number)
where customer can be:
0 - 99 — 0 is default.
Example:
.STSC 5
Query Local Virtual DN (Type Local DN).
The command format is:
INPUTOUTPUT
.TLDN.TLDN (DN)
Example (for 6 = ESN access code, 613 = ESN location code, 5999 = DN):
.TLDN.TLDN 66135999
.SLDN (dn)
Example:
.SLDN 66135999 DN).
INPUTOUTPUT
Set Local Virtual DN (Set Local DN).
The command format is:
Query Master or Backup Time Synchronization Number (Type Master
The command format is: .TMDN.TMDN (DN)
Example (for 6 = Outside line, 514 = ESN code, 3999 = DN):
.TMDN.TMDN 65143999
Set Master or Backup Time Synchronization Number (Set Master DN).
The command format is:
.SMDN (dn)
Example:
.SMDN 65143999
Query Time Delta.
The command format is:
INPUT OUTPUT
.TDEL.TDEL (SIGN) (HR) (MIN)
Example:
.TDEL.TDEL 0 01 30
Set Time Delta.
The command format is:
.SDEL (sign) (hr) (min)
where:
sign – is the time-adjust factor direction indicator which can be:
0 — to indicate the Master switch is behind in time.
or
1 — to indicate the Master switch is ahead in time.
hr – is the number of hours the time must be adjusted by and can
be any number from 0 to 23, and
min – is the number of minutes the time must be adjusted by and
can be any number from 0 to 59.
0 is the default for the SDEL parameters.
Example:
.SDEL 1 23 00
Note: The hour and minute entries are two digits. The minute entry is
defaulted to zero if not entered. “1” identifies a positive delta (Master is
ahead in time), “0” identifies a negative delta.
Example:
Query Requesting Mode (Type MODe).
The command format is:
INPUT OUTPUT
.TMOD.TMOD (MODE)
.TMOD.TMOD BKGD
Set Requesting Mode (Set MODe).
The command format is:
.SMOD (mode)
where mode can be:
BKGD — Background (default)
or
DSVC — Daily Service (midnight)
Example:
.SMOD DSVC
LD 22 – Print the DN type for the Network Time Synchronization
Virtual DN. The DN type is “TIME”.
Feature operation
Each node of the network that is to be synchronized sets its status (i.e.,
Master, Slave, or Standard stand-alone (the feature is not used)). The
craftsperson also sets the node's customer in charge of synchronizing the
switch (that customer will request Time Synchronization and receive the time
from the Master or Backup switch). The customer must already exist, prior to
referencing it, and then sets the local access codes with the virtual DN, the
Master (or Backup) routing digits, the time difference between local and
Master nodes, and the requesting mode (for example, performed under the
background routines (default) or the daily services. The time delta and the
requesting mode are optional entries).
The time synchronization feature is designed to work in a Meridian Customer
Defined Integrated Services Digital Network (ISDN) environment, using
D-channel messages. The synchronization messages are carried by TCAP
facility messages on a Meridian Customer Defined ISDN, and routed
according to the configuration defined in LD 2.
Once the configuration is defined in LD 2, the Slaves will automatically start
requesting “time-stamps” from the Master periodically, upon initialize, and
when the time and date is changed in LD 2. The message to be sent is
identified as being a time synchronization request. The stored Master's
routing digits (access codes + virtual DN) are used to route the
synchronization requests. As part of the request, the requester's access
codes + virtual DN is sent to provide the Master with a way back to the
requesting node.
Upon receipt at the Master node, the terminating DN is recognized as being a
time synchronization virtual DN, and the request is then processed. The
processing consists of constructing a message, identified as being a time
synchronization response and originating from that virtual DN, which
includes:
• time
• date, and
• time-adjust factor (if used).
The message is then routed to the Slave using the access codes and virtual DN
provided with the request. The time-adjust factor is sent to all Slaves in order
to have the whole network correct any inaccurate clock settings in unison, if
any slippage correction is necessary.
Up to three requests will be sent at one minute intervals, to allow the system
to overcome possible temporary malfunctions. On receipt of the time
message, the requester verifies the originator's ID (its virtual DN), and
updates its clock accordingly (i.e., equal to the time sent minus the time delta
between the two switches). If equipped with the CDR package, a time change
record is provided with every time synchronization occurrence.
All the best
Firebird Scrambler
Meridian Programmer in the UK
- Thread starter
- #8
All,
Many thanks for the replies. I will be keeping them all! A little light reading for the weekend!!
I'm still not sure how a PBX set to standalone (STDA) will time sync with the carrier network, but I will need to read up on this.
Once again, many thanks.
Have a good Easter.
Jimbo
Many thanks for the replies. I will be keeping them all! A little light reading for the weekend!!
I'm still not sure how a PBX set to standalone (STDA) will time sync with the carrier network, but I will need to read up on this.
Once again, many thanks.
Have a good Easter.
Jimbo
- Status
Similar threads
- Locked
- Question
- Locked
- Question