Time problem
jim lesurf (2082) 1343 posts |
Back in 2014 Rick kindly wrote some ‘C’ code to help me get a progam running which I’ve been using to set the ‘time of day’ for my machine clock. This worked fine until recently. However it now tends to freeze my ARMX6. This seems to have arisen in the same time period as other people have been reporting time fetching problems with other programs. I have no idea if the code I’m using can be fixed. But I would like to sort out a working version if it is possible. I know that some other people have used the program andm, like myself, prefer the way it allows the user to set the time of day. So if Rick (or someone else reading this) can help: A copy of the program I wrote using Rick’s code is at http://jcgl.orpheusweb.co.uk/temp/JimTime.zip Thanks, Jim |
Steve Pampling (1551) 7932 posts |
Would “recently” coincide with the last Sunday in October? Note: The nist time server info seems to suggest that time.nist.gov is diverted on a round robin style distribution to time-a.nist, time-b.nist, time-c.nist, time-d.nist on 129.6.15.28-30 and a IPv6 address respectively, but a ping shows it resolving to www.nist.gov On a PC2 a quick “telnet time-a.nist.gov 13” gives a response, whereas “telnet time.nist.gov” times out. Conclusion – server issue. Mind you, the nist web site does suggest that “Users of the NIST “DAYTIME” protocol on tcp port 13 are also strongly encouraged to upgrade to the network time protocol, which provides greater accuracy and requires less network bandwidth." That’s their emphasis. 1 Hardwired in to your code |
jim lesurf (2082) 1343 posts |
I can’t really answer you questions beyond saying that it may well be from the last Sunday in October. I did try making the return buffer bigger. (Following a suggestion from usenet.) This worked once. But hasn’t since. The reported size on another occasion was 51 bytes rather than the original 32. But apart from that it always freezes the machine, not even giving me a size for the received series of characters. However I didn’t write the time-fetching code, and I’m afraid I don’t understand it in any detail. Rick wrote it. It used to work, and I used it to get a value to compare with my local machine’s time. Then let the user ‘correct’ the local time if tey differed and the user wishes. All that said, is the implication that the server no longer sends the expected info? If so, I’d understood that Rick’s code should simply time out. It has done that in the past. I wrote my program to have 5 goes, then give up. That happened in the past on some occasions. But now it writes out a ‘1’ to indicate it is doing try 1, then freezes everything except the mouse pointer. Jim |
Mike Freestone (2564) 128 posts |
Works fine on my pandaboard, in a edit task window, reporting the time was 1s out so I answered no to the last question |
Steve Pampling (1551) 7932 posts |
The “server name” embedded in the code does resolves to the IP that reverse lookup shows to be www.nist.gov which does not appear to have a working daytime server instance. If you change the text time.nist.gov to time-c.nist.gov you are pointing at a working daytime server. Recompile with that and check the situation regarding the generic name at a later date.1 Testing the server(s) |
Rick Murray (539) 13405 posts |
Hmmm… Isn’t time.nist.gov one of the defaults of where Windows looks for time? Works for me:
FFS, still using a two-digit year. |
Steve Pampling (1551) 7932 posts |
The status page for NIST says various of the servers are busy (but not time-c) and time-a when tested produces intermittent failures or slow response while time-c responds quickly.
I think it times out if it can’t connect. The expectation is that a connection will produce a valid response which includes a disconnect forced by the server. |
Steve Pampling (1551) 7932 posts |
According to the page listing servers, time.nist.gov includes time-nw.nist.gov which is listed as located at Microsoft,Redmond with a note of “Site shutdown coming” – probably because Microsoft discovered NTP1
At least part of the issue is server load for the likes of time-a and time-b
daytime is an old standard and has been replaced, by NTP. Yes, two digit year can cause y2k problems, but updating it would be like updating a Ford Model-T with a hybrid engine or electric motor – sort of interesting that you could do it but of no practical use when you have better designed chassis to fit such power trains into. 1although it doesn’t quite behave like the standards compliant NTP and Cisco installers point at a Linux/Unix version instead for proper operation. Recent experience of our server crew is that it isn’t quite what VMWare wants to see either. |
jim lesurf (2082) 1343 posts |
I’ve just tried changing from time to time-c. This works in that I seem to consistently get a response and not a freeze. :-) However the returned string seems to always have 51 chars. So I assume from that and the above discussion that the syntax of the time given is now different to the old method(?) So I assume the next step is that I have to change the way I parse the results and then I can use them as before to report any time error, etc. (?) Is the advice that I should simply now assume time-c is needed and this should be OK in future? Or am I using a change that itself may lead into a blind alley? Thanks, Jim |
jim lesurf (2082) 1343 posts |
Done some experimenting and it looks like the syntax still seems to readable using the parsing I was using. The problem at that stage was that a response 51 chars long wasn’t been handed on for parsing as the program expected the old shorter length. Unless someone points out that I’m still making a mistake I’ll do some more tests then settle on the new version if all is OK. Jim |
Rick Murray (539) 13405 posts |
A better solution would be to read out NTP time and parse that into a *Time style string (so you can just use Territory SWIs to parse it). If I have time I’ll look into it. |
jim lesurf (2082) 1343 posts |
If you’ve seen program I’ve written you’ll know that I rarely get beyond the “minimal hack that just works” stage. 8-] |
jim lesurf (2082) 1343 posts |
Having used the modified version of ‘JimTime’ on a few occasions now I’ve got the impression that the response delays are longer and more variable than they used to be. The changes are that I now contact time-c rather than time, and get a 51 char response. Before the times I got seemed to vary by about a second at most. But now they sometimes vary by 3 seconds or more. The responses seem to be taking longer by a similar amount. Is this inherent in using time-c rather than time, or that the process is currently being loaded by other uses? Jim |
Steve Pampling (1551) 7932 posts |
Load. If you look at the NIST server status page it shows many of the servers under heavy load. There is a decreasing pool of servers to deal with the requests so I suspect that unless people move to using NTP the problems will continue to increase. Do note that time-d.nist.gov has already gone from use by anyone other than IPv6 users and Microsoft seem to be just doing a shutdown with no replacement. Bear in mind the history of the better scheme (NTP) |