Activity for Mark Griffiths
-
Mark Griffiths posted a comment on ticket #45
There are command line options already to do that - just have a look on the web site. The NTP specification specifically prohibits clients from being configured to sync at fixed times so as to prevent excessive traffic at certain times of the day, so i would recommend against doing this, or at least use an odd time if you must.
-
It might be that I updated the installer to a newer version which doesn't support Windows 98, but I don't remember doing so. What happens if you try to install version 3.14?
-
OK, thanks for the suggestion. I'll probably change it to something like: User-Agent: NetTime/2.10 or something similar.
-
Hi Ken, Not retrying the server for 15 minutes after receiving a Kiss of Death from it is expected behavior. Under the NTP protocol standard, a Kiss of Death packet is a way for the server to tell clients to go away and use a different server if possible, so if the client has to retry, it should wait a while before doing so. You could perhaps set the NetTime service to run as a "Delayed start" to give the router a bit more time to start up. Let me know how you go with this suggestion.
-
OK, do you have another computer that is also running all of the time? If so, you could set that up with NetTime to act as a server and configure your laptop with this issue to sync to it.
-
Hi Marek, Thanks for that. I've taken a look at your log file and I've gone and taken a look at the NetTime source code as well: NetTime already actually works pretty much as you're suggesting: It stores the number of seconds until the next sync is due and decrements that counter every second until it reaches 0 and then does a regular sync then. From your log files, I'm guessing that you're right that there's something wrong with the real time clock in your laptop and the problem is coming about...
-
Hi Marek, That does seem rather odd. It sounds like the time has gone backwards, but NetTime should be detecting that and try to sync straight away. If the network is down at the time, it should detect when the network goes back up and then do a sync then. It might be worth emailing a full copy of your log file just so that I can get a better idea of what's actually going on. It might still be worth doing as you suggest, however it's also possible that something else is going on which is affecting...
-
You can effectively do this already by running the program with the /synconce command line parameter. Make sure that it is run with administrator privileges.
-
Yes, that's correct.
-
That's basically how NetTime already works.
-
Hi Joao, I'll look at adding NTS support to a future version of NetTime. If configured with multiple servers, NetTime will already check with additional servers if there is a large time disparity between the current time on the server and time returned by the first server and then ignore any time that is too far out.
-
Although I understand the reason for wanting this, I don't think that it really fits into the core functionality for NetTime. I think that it would be better implemented as a separate program rather than bloating NetTime with a feature that most people don't need.
-
Hi Rafael, Thanks for taking the time to make this suggestion. but I don't think that this fits within the scope of NetTime at all - sorry. IMHO, something like this could and should be done as a separate application. Are there no other programs out there that already do this?
-
OK, can you try enabling debug level logging in NetTime and then do a sync on your IOT device both with and without the Internet being connected and then send the resulting log file to me.
-
Just to clarify, it seems that you're configuring NetTime to sync to itself? Why are you wanting to do that? I can't think of any useful reason for wanting to do this.
-
I think that I know what's likely causing this issue. Do you see this problem if you set boinc to run at a lower priority, or set the NetTime service to run at a higher priority?
-
Sorry for the delay in replying - it's better to just send me an email directly. It should be just a case of calling nettime.exe with the required parameter - you can try that from the command line.
-
Hi Todd, Thanks for the update. I haven't run into that specific problem myself or even heard of anyone else running into it, so thanks for letting us all know.
-
OK, that rules out that possibility then. Would be good to see CPU usage graphs for the host and VM at the time that this happens...
-
I have seen/heard of this happening on real systems as well as VMs where the CPU is overloaded. Usually, VMs have software installed which keeps the time synchronized with the host time. If the VM time falls behind for some reason, the VM software will fix it and NetTime would then detect that as time jumping forward...
-
Hi Todd, This can occur because of the way that the program detects time jumping forward - if the CPU is busy (on either the host or the VM) it can starve the program of CPU cycles and it will detect that as time jumping forward. I have got plans for a future update to the way that this works which should fix this problem.
-
I'd say that the initial correction wasn't right - although it's possible that it's related to being the first sync since starting, I would say that it's more likely that the initial server that was used was just out by a bit. You would need to do more testing to confirm this one way or the other, but I don't think that adding a second sync 1 minute after starting would actually help (and there's the potential for causing overloading of servers in certain circumstances) If you're needing guaranteed...
-
Although I understand why you might like to do this, it's actually a really bad idea - no NTP client should be syncing on a set interval like that because it could lead to load spikes on the NTP servers and cause it to all fall into a heap. Sorry!
-
The default servers are provided by the NTP Pool Project: https://www.ntppool.org/en/ I'm not aware of any issues with the NTP Pool in general. There are a couple of likely causes for the problems that you're seeing: It might be that you're having local network issues or a firewall that is sometimes blocking the NTP protocol. Another possibility is that in some parts of the world, there are only a handful or less of NTP servers - if there are only a few servers in your area and they're all down,...
-
Just enable the option to "Allow other computers to sync to this computer" and ensure that you don't have a firewall blocking acces to UDP port 123 on your server.
-
As far as I recall, there isn't much difference between Delphi 5 and Delphi 7, so even though the latest version of NetTime is compiled with Delphi 7, there's a good chance that it should compile with Delphi 5 as well.
-
Making this code thread safe
-
Can you tell me what software is running on the server? Which other clients are working...
-
Hi John, Do you mean that the system doesn't automatically sync after waking up,...
-
It would be helpful if you can provide the actual error message that you're getting....
-
That should be possible - I'll look at adding that in the next update.
-
Sorry about the delay in responding - it's generally better to email me through the...
-
My understanding is that the system will get the time from the CMOS clock during...
-
Yes, you can do that by enabling the option "Always provide time" on the system that...
-
Yes, you can set the option "Always provide time" on that server and it will provide...
-
Hi Gerrit, Sorry for the delay in responding - for some reason, I didn't get a notification...
-
That makes a lot of sense so I think I'll do it that way.
-
That sounds like a reasonable idea to me - I'll most likely add that into the next...
-
The reason why it doesn't use an automatic stratum level is that the relevant RFC...
-
Yes, you can do that through the same configuration screen.
-
Yes, that should work. On the server PC, just click on the NetTime icon, then click...
-
Unfortunately, there isn't any easy way to do translations at this stage since the...
1
