DTSS time drift

[Robert Manning_2]

Hi,

I have 8 OpenVMS servers of varying platforms and OS revisions, all of which run DTSS to sync their time.

The system time on all 8 is approximately 15 minutes fast, and so far I've been unable to correct it on any of them.

I was considering stopping the DTSS processes on all nodes, manually setting the system time on each and then restarting DTSS, but I'm uncertain whether this would be effective, or even advisable.

From reading the DECdts Management Guide, it looks as if I'm supposed to have 3 DTSS servers, however it appears I only have one. I don't know whether it's getting its time from an external server or if it's using its own system clock to synchronise the clerks.

The attached file shows each system and its respective role - If anybody had any suggestions I'd appreciate it...

Thanks,

Bob

[Robert Manning_2]

This attached file...

Bob

[Hoff]

DECdts DTSS clerks are usually configured to require three or more servers. There should be messages logged about this pretty regularly, unless your configuration has been reset to expect fewer, or DECdts has been disabled.

Recent DECdts releases have the NTP provider source code module added back (it was removed for a while, and then fixed and re-added to the kit), which allows DECdts to retrieve its time from NTP. That can provide more DECdts servers, using an NTP source.

The DECdts UPDATE TIME command invoked on the DECdts server is likely the one you want here, as it looks like the server has the wrong time. The command will alter (drift) the server time, and the clerk(s) will then follow.

There's another recent thread here in ITRC on UPDATE TIME over the last couple of weeks, IIRC. The ITRC search engine is seemingly on redirect holiday today, however.

The following has the DECdts planning guide:
http://h71000.www7.hp.com/doc/73final/6495/6495pro.html

Stephen Hoffman
HoffmanLabs

[Robert Manning_2]

Stephen,

Thanks for that - the redirect's working now, BTW...

I tried the UPDATE command as suggested but no joy. A series of errors was returned which leads me to believe the server was trying to make a connection but failed.

NCL>update node hqmvx6 dtss time 2007-02-06-16:01:00.00
%NCL-E-REQUESTFAILED, command failed due to:
-CML-E-SESSPROB, error returned from session control
-IPC-E-BADUSER, access control rejection
-NET-F-REMOTEDISCONN, connection disconnected by remote user

Either it's attempting a DECnet connection to one of the clients or it's trying to make an external connection, I'm not sure which.

Is there a logfile or something I can check to see what it was trying to do?

Rgds,

Bob

[Hoff]

The update node hqmvx6 asks for the command to be issued on hqmvx6. Log into the time server. (Is the time server here hqmvx6?)

Check the time on the time server. Is it wrong?

I'd log in and issue the update time on the time server -- locally, and for the local time-server node. Let DECdts itself propagate the new time value around for the other nodes; for the nodes running DECdts clerks.

I'll assume the username in use here has the various DECnet-Plus identifiers. The username should be granted NET$MANAGE, and probably a few others.

[Robert Manning_2]

Hi,

Yes, HQMVX6 is the time server. The time is wrong, and all the clerk nodes are out by the same interval.

I logged on as SYSTEM, which has pretty much everything in terms of NET$ identifiers, and retried the UPDATE operation but got the same result as before.

Any reason not to disable DTSS and update the clock, then reenable the service?

Bob

[Volker Halle · Accepted solution]

Bob,

on HQMVX6, you just need to issue the command:

$ MC NCL UPDATE DTSS TIME 2007-02-06-16:01:00.00

Do not add the 'node hqmvx6' parameter, as this will cause a DECnet connection to be established to the local node using some default account, which will not have the required privileges.

Volker.

[Hoff]

The NODE nodename stuff in NCL speak is like TELL nodename in NCP speak. It aims the NCL particular command else-node; at node nodename.

I wouldn't choose to shut down and restart, I'd let DECdts do what it was intended, and I'd let the time then propagate to the clerks as intended.

I would look for an external timebase for HQMVX6, either directly or LAN-attached attached WWV or GPS receiver, or (for access to an Internet time base) the NTP provider module, or such. Or a cesium clock, if you've got the budget for it. Something that has a higher accuracy than the in-built clock. This if the drift is really an issue.

I'll add the UPDATE TIME stuff into the next FAQ, as that's arising rather regularly of late.

[Robert Manning_2]

Volker,

Thanks - that appears to have been successful (I didn't get an error message back, anyway). I imagine the time will change gradually over a number of hours, so I'll check it periodically and see what happens.

I'll post again on Tuesday when I'm back in the office.

Stephen,

I take your point about an external timesource. It'll be something of a moot point in a few weeks as I expect to be decommissioning a system or two, and HQMVX6 will be one of them, but something will have to take its place so I'll do my homework in the meantime...

Rgds,

Bob

[Robert Manning_2]

Volker,

Okay, looks like I'm sorted for now - my DTSS server has adjusted to the new time setting and has propagated out to the clerks.

It took a couple of days, but at least it worked. I'll review it every two weeks and run the update operation as necessary, which ought to keep things running until the server is decommissioned later this year.

Thanks again for the help.

Rgds,

Bob

[Robert Manning_2]

Okay - it's been almost a month and so far there's no sign of any drift. I'll continue to monitor it until the server is decommissioned, but it looks good for now...

Thanks again to all,

Bob