Internet Time and Cortex

Usually I don't look at the Cortex logs or even watch the comms window very much, but I was looking at it the other day just after I had come upstairs and the lights had waited some seconds before coming on. I had happened to reduce logging verbosity to the barest minimum and I noticed a message about the internet time server update failing. Normally the density of Idranet messages would most likely obscure this message.

Cortex's "clock" object includes the facility to update the system time from the Internet. Given that XP has an NTP client built-in I am not sure of the advantages of using the Cortex option. However, since my database originated from ye olde days of Windows 2000, the option was enabled. And at some point in time it had stopped working.

I initially thought that maybe the selected time server (a specific Ip address) had gone offline, so I set the server to uk.pool.ntp.org, but it still did not update on a manual request. Similarly my ISP's NTP server also wouldn't work. However, I found that the XP NTP client was successfully updating from the same server pool. Weird.

I tried the specific time server from the example dialog in the Cortex help, not really expecting that it would work, but it did.

OK, I'm now in dog with bone mode, so I break out Wireshark and start watching the packets. After some messing about with packet filtering and trying to find out whether my firewall was blocking NTP I finally discover that the Cortex object is using the "time" protocol (UDP 37) whereas the XP client is using NTP.

I was led up a bit of a blind alley, since the Cortex online help suggests searching for public "NTP servers". And I also noticed a warning in the Cortex online help that a failed time server can stall Cortex until the timeout completes. Hmmm. Because of this they suggest quite infrequent (daily) updates, whereas I had 30mins set for no particular reason.

A bit more experimentation and I found that the timeout on the pool.ntp.org is about 1 second whereas my ISP server times out after about 20 seconds. This may be because the pool.ntp.org servers responds with a TCP RST and the ISP server doesn't respond at all.

Perhaps this was the cause of my mysterious delays ... it's difficult to tell, since there is still bi-directional flow of packets reported from the comms windows during the period waiting for the timeout. I will just have to wait and see if I ever notice the delays again now that I have disabled the Cortex update.

I've concluded several things from this :-

1. It's a good idea to turn off the most verbose logging and keep an eye out for occasional anomalies
2. Cortex time update appears to use time/37 protocol, even though the help file implies searching for NTP servers to use
3. Some NTP servers may also support the time/37 protocol
4. the NTP server pool from pool.ntp.org rotate through various servers, some that may support time/37 and some that may not
5. Cortex may stall for the timeout period if the server is unavailable/unresponsive
6. It appears that my chosen NTP server used to support time but no longer does
7. Using XPs NTP client may be a better option assuming it doesn't stall anything if there is a server problem
8. I would only actually notice the timeout if I did something that would require a Cortex action and this correlated with the timeout period and Cortex does stall. With a update frequency of 24 hours I think I would quite possibly never noticed this

If you do use the XP NTP client the default update period is quite long. It can be altered using a registry tweak documented here.

My guess is that the Cortex Internet time update is a vestigial feature from Windows 98 platform days, where it was helpful since there was no pre-installed NTP client.

Update
I thought I had another instance of the hiccup ... but then I discovered I had partially knocked out a connector at Node-I whilst working in the loft and Cortex was indicating troubles talking to the bedroom modules. So not conclusive.