NetTime has no effect on bootup

NetTime has done its stuff before anything else can be run

Before any WIMP tasks, yes. So to put it into Predesk should be OK, no?

In fact, just after the completion of network start.

might slow things down.

That’s why it should be option (both for startup and shutdown syncs).

The fact is that some people want more precision.

I just try to find a solution :)

Can I just be clear here: you were killing RTCAdjust on your RiscPC?

Nope. I was using a different clock. One on the DSP card. And by ‘clock’ I mean in this context a source of a regularly-spaced series of events.

And yes, I’ve understood for some time that the way NetTime functions is fine for many people for many purposes. Although I still think 127 sec is absurdly large leeway for not *setting the clock time.

However that doesn’t change the main points I’ve made. There are cases where it would cause a problem and the absence of user documentation – plus the misleadinly ambiguous GUI – may mean a user is caught unwares. I was, despite repeately asking people to explain how to use it and point out where I might be going wrong. No-one explained the critical points.

The idea that people “don’t need to know” strikes me as rather a worrying absolute generalisation. Many people won’t. But some may. However without any user documentation, they may have no way to find out. One of the points for me of raising this has been so people at least become aware of that.

Jim

Although I still think 127 sec is absurdly large leeway for not *setting the clock time.

128ms seconds is the default step threshold for ntp. Perhaps someone misread milliseconds as seconds?

128ms seconds is the default step threshold for ntp. Perhaps someone misread milliseconds as seconds?

A comment in the source suggests that 127s is a convenient “round number” in binary, due to the way the calculation is done.

Well, today it happened again. Fortunately, no holiday was involved this time, so we lost much less email.

I tried following David Feugey’s advice of deleting Boot:Choices.Internet and reconfiguring, which didn’t help.

And yes, I am and have always been using version 0.43 of NetTime.

Why is the command NetTime_Kick a no-op, if and only if it is issued as part of the boot sequence? Alternatively, how does everyone else manage to get NetTime to do a sync immediately on bootup, instead of 15 minutes later, when I can’t?

I gave up having found that I couldn’t get to to even correct the time on some occasions when the offset was far more than a couple of mins. Even the assumed ‘127 sec’ tolerance isn’t obeyed here. The idea that even 127 secs is ‘convenient’ presumably mean “for the programmer” rather than mere users! However I’m not programmer enough to understand why improving this may be difficult.

I just gave up and wrote a simple wget-based way to find the time offset and correct time, then set the clock accordingly. Run it occasionally when I want to check/set.

Jim

Well, today it happened again. Fortunately, no holiday was involved this time, so we lost much less email.

In your first posting, you said this: Suffice to say, shortly after a vast backlog of emails had been downloaded and datestamped in 1970, NetTime finally woke up and synchronised for the first time. The apparently 44-year-old emails were then promptly expired.

Your mail client is crap if it reads the “current” date of a message from when the message was debatched (1970, apparently) and not from the Date: header in the message.

Sorry. Your NetTime and/or machine is obviously not working correctly to be doing this, but your email software is fundamentally broken as well.

Why is the command NetTime_Kick a no-op, if and only if it is issued as part of the boot sequence? Alternatively, how does everyone else manage to get NetTime to do a sync immediately on bootup, instead of 15 minutes later, when I can’t?

This pretty much just strengthens my call for a “-force” option, so you can issue (boot sequence or whatever) the command NetTime_Kick -force and it will set the current time. Absolutely. No arguing. And, yes, let the user be held responsible if this has side effects, but at least it should be an option.

Oh the other hand, you could do something to mitigate this problem and the loss of emails (other than use a better mail package). What? A simple line in an Obey file somewhere in the boot up after NetTime gets a look-in.

If Sys$Year < “2014” Then Error System date failure!

The boot will abort at that point. Sometimes my machine doesn’t read its DHCP address (WiFi adaptor not synced) so I read the gateway IP and if it isn’t set, I bomb out the boot. If stuff isn’t right (DHCP for me, date for you) there is no point continuing, especially if it can lead on to a known problem that results in loss of data.

It would be interesting to see what you get if you unplug the router before booting. That forces nettime to fail. If a 1970s date is set then the operating system is failing. Even if the RTC thinks it is actually 1970 the OS should intervene surely? It can, in principle, know the date of the last shutdown and so should give a message on boot like ‘This computer has encountered a temporal anomaly and has set the date to xx.xx.xxxx please confirm’.

the OS should intervene surely?

It depends upon the OS having this functionality built in, though.

If a 1970s date is set then the operating system is failing.

So-so. The OS is probably just asking the RTC (or whatever) and is trusting it to return valid information.

It can, in principle, know the date of the last shutdown and so should give a message on boot like ‘This computer has encountered a temporal anomaly and has set the date to xx.xx.xxxx please confirm’.

Or if just the year was read as being prior to 2014. You can do this check yourself (see my previous post). I can think of few normal reasons why a system date would come up as prior to 2014; but I can think of several abnormal reasons.
That said, it should be pointed out that my Beagle has no battery on-board, and I think that it defaults to 1970 or something. It would be… annoying… if that prompt happened on every single boot. Perhaps the OS being dumb and the ability to write an Obey file would be a reasonable compromise?

Your mail client is crap if it reads the “current” date of a message from when the message was debatched (1970, apparently) and not from the Date: header in the message.

I’ve since learned that that wasn’t the full story; AntiSpam has a rule where it deletes messages which appear to have been sent from the future (since that usually indicates a broken spam script), and in this case, the messages in question were 44 years in the future.

This pretty much just strengthens my call for a “-force” option, so you can issue (boot sequence or whatever) the command NetTime_Kick -force and it will set the current time.

This assumes that the NetTime_Kick command is getting as far as NetTime in the first place. I have verified that it is being executed, it just doesn’t seem to do anything.

I strongly doubt that Jim’s FUD over the gradual time adjustment is an issue (and I’d rather this thread not get derailed again), given that that (1) this only applies for small corrections and (2) the command NetTime_Kick does work… just only if it was manually typed in a TaskWindow, and not when run from an Obey file during bootup. Which makes no sense. How can it even tell how it was invoked?

And there cannot possibly be any official policy against allowing large adjustments on bootup, because for many people that’s the only way to set their clock they have.

I just can’t work out why it doesn’t work for me.

I strongly doubt that Jim’s FUD over the gradual time adjustment is an issue (and I’d rather this thread not get derailed again),

People don’t seem to understand where and why NTP does step or slew. So you’re right, until they do it’s best not discussed here.

I can’t help wondering whether the way forward for instances like yours is having a small utility that:
checks the system date against the OS date to ensure that the system date is greater than the OS date
checks whether the NTP server is accessible

Pops up a warning message and sets a system variable if either is false

Time critical items can then be set to not run if the variable is set.

AntiSpam has a rule where it deletes messages which appear to have been sent from the future

This, of course, highlights the problems of automated deletion of messages. It would be better for undesired messages to be debatched into a valid format mail file in !Scrap (can be replaced by the subsequent debatch) so they can be recovered if something goes wrong.

since that usually indicates a broken spam script

How far in the future? I forget who, but one of the larger Asian mail systems (circa Y2K) used to send messages timed from some Chinese time zone or other, identifying itself as being UTC; so messages were always about seven odd hours in the future. And this was legitimate mail (mostly).

I found the best way to get rid of a lot of spam is three simple rules:

• if message sender name is Yahoo and email address is not Yahoo’s
• if message says “aleikum”, “Nigeria”, or “Burkina Faso”, “medication”, or “viagra” and isn’t from somebody in my address book
• any message whatsoever from LinkedIn (and other social networks as applicable)
  Mail gets moved to “Trash” where it is expired after a while (in case it was a misfire).

just only if it was manually typed in a TaskWindow, and not when run from an Obey file during bootup. Which makes no sense. How can it even tell how it was invoked?

It is possible that something just isn’t “ready” in time to allow the NTP server to be contacted? Try inserting a little program just after the network is initialised to do nothing while counting down 10 seconds, see if that makes any difference.
And, absolutely, insert the little bit of Obey script I gave to bomb out if the year is prior to 2014.

And there cannot possibly be any official policy against allowing large adjustments on bootup,

Not so much an official “policy”, more a worry that currently running applications might suffer a nervous breakdown at finding the system time changing on them.
Kind of hard to understand how this can trump having the system clock days, months, years, or even decades incorrect…

People don’t seem to understand where and why NTP does step or slew.

Skewing isn’t really a factor when the year is 1970 (or whatever). That ought to be a jump correction, and for some reason this doesn’t appear to be reliably happening for Martin.

can’t help wondering whether the way forward for instances like yours is having a small utility that:

…how is this much different from If Sys$Year < “2014” Then Error System date failure!? Something more useful would be a little utility that knows it is at least 2014 right now (reading OS build date is an optional extra), so will keep attempting to contact an internet time server (timing out with an error after n retries) to read the network time and force-set it to the known current time.
Don’t you think, perhaps, this is a job that NetTime could be capable of, given that it already has both pieces of information to hand?

Don’t you think, perhaps, this is a job that NetTime could be capable of, given that it already has both pieces of information to hand?

Save last known active date/time at intervals, check at boot time, if last known > current then change current to last known – worst case your clock is set to the time you last used the machine.

Just thinking – haven’t looked – when in the boot sequence is the network and name resolve active, and when does nettime run?
Just thinking “race condition”.

Just thinking – haven’t looked – when in the boot sequence is the network and name resolve active, and when does nettime run? Just thinking “race condition”.

Hmm. I’m getting a feeling of deja vu from the first page of this thread.

I was told I was wrong then, but if Martin’s checked David’s suggestions regarding possible !Boot broken-ness then I wonder if I was?

I’ve still not seen the problem here, despite relying on NetTime to set the clock on the Beagle, but I’ve just realised that there’s probably one other obvious difference between my setup and Martin’s. My time server is on the local network and NetTime gets the IP address from the Hosts file and not via DNS. If Martin’s using the default uk.pool.ntp.org, then DNS will have to get involved. I’m not sure how the timing’s organised, but there are indeed a whole set of potential race conditions in that sequence.

I should probably add that I’ve just reconfigured my system to use combinations of static IP and DNS for the NetTime connection, and it’s still worked OK. Martin implies that it isn’t failing every time, though.

Hmm. I’m getting a feeling of deja vu from the first page of this thread.

and:

My time server is on the local network and NetTime gets the IP address from the Hosts file and not via DNS.

and:

If Martin’s using the default uk.pool.ntp.org, then DNS will have to get involved.

Resolver?
It’s not seen development work in many years and has many known deficiencies – like a hardwired element in the reverse DNS – hence the special module written by F-d-B for DNS blacklist operation in AntiSpam.

The theory about DNS resolve would be easy for people to test by adding the IP of specific NTP servers they use to their hosts file.

Martin implies that it isn’t failing every time, though.

Varying response times on the DNS resolve? Server offline and fall through to secondary time server? The two combined could be just enough to make it marginal.

I strongly doubt that Jim’s FUD over the gradual time adjustment is an issue (and I’d rather this thread not get derailed again),

That’s why I didn’t mention it in my last posting, ‘FUD’ or not. I was pointing out that I can’t consistently get NetTime to correct the time even when the time is wildly wrong. So gave up and wrote something that works OK instead. Despite what people tell me should happen, the Kick here doesn’t reliably set the time correctly as people say here – even when the offset is well above 128 sec and issued in a TaskWindow. Afraid I have no idea why practice differs from theory, though.

Jim

People don’t seem to understand where and why NTP does step or slew. So you’re right, until they do it’s best not discussed here.

It might help if people adopted the useage I’m familiar with when dealing with scientific clock standard:

Set – means changing the time displayed to agree with a standard reference clock’s displayed time.

Regulate – means adjusting the clock rate to get agreement with a standard reference clock’s rate.

However unless they’ve read these discussions I suspect most user will have no idea what the module does… unless and until they find it isn’t giving them the correct time reliably and have to investigate.

BTW might be worth pointing out that the fairly crude way I’ve adopted to get and set time from the net does sometimes fail due to getting no response from the reference source. No idea if that is relevant to the problems people are discussing. I just run the wget again.

Jim

It might help if people adopted the useage I’m familiar with

I’m just using the terminology used in the NTP documentation

BTW might be worth pointing out that the fairly crude way I’ve adopted to get and set time from the net does sometimes fail due to getting no response from the reference source. No idea if that is relevant to the problems people are discussing. I just run the wget again.

Are you using a URL or an IP?
If the former, does the URL actually equate to a cluster resource and actually use a different IP at different times?

An option in many client implementations is to specify several server IP’s and fail through.

Despite what people tell me should happen, the Kick here doesn’t reliably set the time correctly as people say here – even when the offset is well above 128 sec and issued in a TaskWindow.

It won’t. Unless the clock is way out (how do we define “way out”?), the module appears unwilling to do step changes on an operating system. Instead, it will slew the internal clock (your terminology = regulate) to speed it up. Over a course of time, the clock will drift closer to what is correct. So say you are 128 secs out and the clock is sped up (or slowed down) by about 5%. 5% of 60 is 3. So there will be a disparity of 3 seconds every minute. This means your clock will have drifted to be correct in 40 minutes. Without you ever really noticing. Then the clock slew will be adjusted to a much smaller value to keep the clock in line with reality.

NOTE : the 5% value has been plucked from the air, I can’t be bothered reading the source code to see what values it actually uses and when.

Just think how many discussions could have been avoided if NetTime had a “just ****** well DO IT” option? ;-)

I think Steve might have hit the nail on the head, however. NTP lookups could fail. You might have an obnoxious router that intercepts NTP and replies itself. Sometimes things just don’t work like what they’re s’posed ta.
So if your only clock source is NetTime, I would strongly recommend the way posted above to fail the boot if the system year is earlier than 2014.

Unless the clock is way out (how do we define “way out”?), the module appears unwilling to do step changes on an operating system.

Hmm, defining “way out” is normally a preset variance between the NTP source server and the client. However if the server lookup doesn’t work there’s nothing to compare.

I think Steve might have hit the nail on the head, however. NTP lookups could fail. You might have an obnoxious router that intercepts NTP and replies itself. Sometimes things just don’t work like what they’re s’posed ta.

Network timeouts, failed lookups and things not quite doing what the oughta is the story of my working day. Diagnosing and altering to working state is the hoped for outcome.

BTW. Slew rates are normally modifiable, to an extent.

Network timeouts, failed lookups and things not quite doing what the oughta is the story of my working day.

Does this affect you, or is that part “NMFP”?
http://www.theregister.co.uk/2014/11/10/thousands_of_patient_records_at_risk_from_hackers/

Does this affect you, or is that part “NMFP”?

Same office, and story not applicable. So, more a case of NOFP.
Main user complaint at work in the last fortnight: big block of updates to Win7 and XP (on the older installs) Didn’t pay much attention to the conversations as I was rebooting my machine a few times…

Are you using a URL or an IP?

I use wget to fetch http://tycho.usno.navy.mil/cgi-bin/timer.pl

I then compare the UT it provides with the timestamp on the resulting file. I don’t know the dotquad. Would that be faster and more reliable? If so I’d like to try it. Ditto if there’s a closer/better source of a simply wgettable text of the time.

At the moment I do the actual correct by reading the above and then making the change by hand. If I can make the process reliable with a timeout/optout it could then presumably be used via a child task handoff to autoset the time.

(your terminology = regulate)

Its not actually ‘my’ terminology. Its the one adopted by those who work in areas where scientific reference clocks are needed. And in the clocks / watches / horology area. Standard terms so far as I know.

Using ‘set’ to mean ‘regulate’ or both simply can cloud the issue. The two actions are quite different. At the moment even when NetTime ‘works’ all it does it tell you your clock might be right at some unspecified future time. I doubt many people would innocently assume that’s what ‘set’ actually means when clicking the button. Might as well ‘set’ a clock by stopping it so it is ‘right twice a day’. At least that guarantees is will be right at some time. 8-]

This all reminds me of Eccles knowing the correct time because he had it written down on a piece of paper. :-)

Jim

I then compare the UT it provides with the timestamp on the resulting file. I don’t know the dotquad.

All the details you need are in the pages on their site. Start at This page and read around. They list their time servers.

All the details you need are in the pages on their site. Start at This page and read around. They list their time servers.

Sorry, but I’m not using NTP and frankly don’t understand the details on the site you referred me to. I was asking about the dotquad of the address I’m using because it gives me a text file I can read/parse without having a clue about NTP from a plain wget for a file.

I appreciate this is an idiot-simple way to go about it from the POV of an experienced programmer, and might not suffice for those with always up intranets to synch. But I can do it and it delivers what I actually want. A way to reliably set the clock. If NetTime did this, I wouldn’t be bothering at all.

Jim