Page 1 of 1

A few iTimeSync suggestions/comments

PostPosted: Sun Apr 19, 2009 10:17 pm
by Unregistered
1. It took me by surprise that the iTimeSync GUI and service each used their own log files. I understand why this is done (they run under different user contexts), but to me, it would make more sense to have a single, combined log.

2. I'd appreciate having separate GUI/service "On iTimeSync start" options. That is, let me configure the service to perform a "Correct Time" action when it starts, but let me run the GUI without doing anything (i.e. "Do Nothing"). The reason for this suggestion is that I always have the service running, yet sometimes I run the GUI just to check or change a setting, and I don't want to hit the time servers each time I do. Also, having the GUI perform a "Correct Time" upon start (when all you really want is for the service to do a "Correct Time" when it starts) also imposes an annoying delay before the options can be accessed in the GUI.

3. When the "On iTimeSync start" option is set to "Correct Time", and the iTimeSync service is started, the log says "Started Service, XX Mns until AutoSync", but immediately after that, it reports the results of the time sync that was performed at service start. In other words, saying "XX Mns until AutoSync" is not accurate, because a sync is being performed right away. (I would simply change the string to say "AutoSync will be performed every XX Mns", as that would be accurate whether or not the service did a "Correct Time" upon start.)

4. When the "Average" option is set (on the "Misc" tab), iTimeSync checks multiple time servers (four different servers, to be exact). However, the log only reports one of these four servers (e.g. "Server used was"). I'd like to be able to see, in the log, what's actually going on--which servers were checked, and the result for each. If four servers are checked and an average is taken, I don't see what sense it makes to list one of those four servers as the time source.

5. Regarding the "Average" feature, please consider adding the ability to specify the number of servers to average over. For example, poll two servers and take an average, or three servers...

6. I'm pretty sure that the iTimeSync service should have TCP/IP as a dependency. That is, under HKLM\SYSTEM\CurrentControlSet\Services\itimesync, there should be a REG_MULTI_SZ value named "DependOnService", and it should be set to "Tcpip".

7. The iTimeSync uninstaller is set to use the /SYNC parameter. I haven't tested this, but is that correct? Along the same lines, the "Remove iTimeSync" shortcut that is (optionally) created uses the SYNC parameter, but it uses a backslash (i.e. "\SYNC") instead. Again, I haven't tested this, I'm just running it by you for accuracy.

8. The directory %AppData%\Sinner\iTimeSync gets created upon installation, but it remains empty. My assumption is that this directory was formerly used and has been phased out, and thus should not be created on new installations.

9. Please consider adding the ability to log to the system event log, rather than (or in addition to) the existing text log. (This would simplify not only checking of local log(s), but also remote system iTimeSync log entries.)

10. Please consider adding the ability to alert (via email, msgbox, etc.) when all time synchronization attempts have failed for a certain amount of time. If iTimeSync hasn't been able to set the time for a day or two or ten (for whatever reason--DNS issues, firewall, etc.), I want to know about it.

11. Please consider adding the ability to adjust the clock frequency, rather than simply setting the time.

12. When I use the "Scan" function, I get a slew of errors and timeouts. I don't understand why, since the exact same server list works 100% fine in a competitor's product. In particular, "" always appears as "Error" (what "error" I have no idea...). I can sync to "", so I don't understand this. Also, the scan always shows "Time out" for "", even with the timeout setting at 10 seconds (which is ridiculously generous). I can always sync to "", so the "timeout" being reported is a real mystery.

13. When I select a server using the "Use List" option, then set the "Default server only" option, iTimeSync still tries other servers if the "Average" option is checked. These options contradict each other, in a sense.

14. Is there some way to always start at the beginning of the server list? (If not, please consider such a feature.) From looking at the logs, it seems that iTimeSync cycles through the entire list.

15. The iTimeSync 1.500 About box looks just a little askew on systems running 120 DPI:

iTimeSync 1.500 About Box at 120 DPI
0001.png (12.31 KiB) Viewed 10418 times

PostPosted: Mon Apr 20, 2009 7:50 am
by Siegfried
Wow! Thanks for taking the time to make so many comments.

1. Separate log files. Yes, this is an issue. Work on the niceties of the service mode was one of the plans for 1.5 but due to various reasons (mostly timing of user requests) SNTP server mode won out. The server mode should be tweaked next version.

2. Separate service settings. Yes, this is on the list.

3. Autosync/sync on start inconsistencies. Well, sync on start isn't seen as a an AutoSync, but I understand why you'd see it as inaccurate. The problem with your suggestion is that the display isn't a constant so "AutoSync will be performed every XX Mns" would be big change and many users like the countdown. I'll give it some though.

4. and 5. Average. So you like the average mode? It came very close to being removed this version actually. It seems redundant considering the accuracy of SNTP and the protection offered by date ranges. Even so, your suggestion will be looked into.

6. TCP/IP dependency. You're probably right. I've never encountered or heard of any problems without that set but it wouldn't be a hard addition.

7. Un-installer paths. They both work (I just tested them) but I agree they should be consistent. It will be changed ASAP.

8. Sinner Dir. The "Sinner" dir is used if it's there is data there, and it's created to mark that it's been checked. Not hugely neat I know, but in terms of software annoyances this is a pretty small one. We'll stop doing this soon and move data to the ACAPsoft directory.

9. System log. This has been requested before, and we are considering it. I personally find the system log too overused to be useful these days so I personally wouldn't use that setting.

10. Long term sync error. Yes, this has been on the list for a while. We want to add a "desperate" mode where iTimeSync alerts the user and/or tried more if there are repeated errors.

11. Adjust frequency. Also on the list.

12. Scan. Are the errors with TIME or SNTP? I found that fails (time out) on TIME, but not on SNTP. If that's the case for you chances are doesn't run a TIME server anymore. Looking though the current list most have TIME errors but only 3 have SNTP problems.The server scan window is due for an enhancement though. (I couldn't get an "error" for, I could only get a "Time out" for TIME.)

13. Average/Default server only. Yes. It would make more sense to disable that option as together they make no sense.

14. Start at server list beginning. No, that option isn't there, but it's an easy addition.

15. DPI. Yes. We are rather slack in the DPI support. It's an area we need to put more work into with most of our programs.

Thanks again for the feedback and suggestions. Many of these will happen next version, but since we just released one it won't be in the next few months. If you want further clarification or if I answered a question wrong feel free to post again!

Re: A few iTimeSync suggestions/comments

PostPosted: Mon Apr 20, 2009 1:54 pm
by Unregistered
3. Autosync/sync on start inconsistencies I was talking about only the log file itself, not the countdown in the GUI. I understand that when the service starts, if the startup sync isn't considered an "AutoSync", it's accurate to say "Started Service, XX Mns until AutoSync". But as a new user, when I ran the service and checked the log, I thought something was wrong (because I thought--reasonably, I think--that every automated sync was an "AutoSync").

4. and 5. Average. I like the idea of averaging, yes. I try not to use stratum 1 servers, and being that I'm using non-official, non-stratum-1 servers, I like to check at least two of them and do a sanity check. Actually, far better than averaging, I like the idea of being able to check three (or more) servers, and throw out the result from any one of them that represents a significant discrepancy from that of the others (perhaps greater than 500 ms or so). (If you check two or more servers, and one of them is significantly off, it's not a great solution to simply average in the discrepancy. Better to simply ignore it. If there is a significant discrepancy between two or more of them, then you'd probably want to average--or check more servers!)

6. TCP/IP dependency. Yes, the iTimeSync service does depend on the "TCP/IP Protocol Driver" (which is how it appears in services.msc once the "DependOnService" is set to "Tcpip"). I've also seen other NTP service software add this dependency. It's pretty unusual for TCP/IP not to be up and running, but...

9. System log. I understand your point about the system log being overused, but there are lots of nice utilities out there that let you filter (and manage, alert on, etc.) system log entries. My own system log is pretty trim. I love being able to see all the application logs I'm interested in all in one place, and being able to easily check my other computers (over the LAN).

12. Scan. I apologize, I didn't realize what I was looking at. When I saw the "TIME (ms)" column, I thought it was referring to round-trip time, not the TIME protocol! Sorry about that.

On a separate note, I just noticed that in the About box, when "Prog Dirs" is selected, the C:\Documents and Settings\NetworkService\Application Data\ACAPsoft\iTimeSync directory isn't shown (or opened), even when the service is installed.

Thank you very much for taking the time to read and reply to my message! I'm about to register iTimeSync right now, and I'll buy more registrations down the road as well.

PostPosted: Mon Apr 20, 2009 2:40 pm
by Siegfried
Glad to be of service! We do try to offer good support, especially on this forum as it's a more efficient in terms of time expenditure.

More points on points!

3. Autosync/sync on start inconsistencies. Ahh! Sorry about that; I thought I was reading you wrong there but I couldn't work out what you meant. (You even said log too... :-$ ) Yes, I agree. To explain, that logging is mostly there to indicate that the server started correctly. We were testing iTimeSync on a computer and there were some odd results. To help us know if iTimeSync was running correctly that was added. Since we had someone translate the text of GigAlarm we were reluctant at that late stage to add new text so we re-used that one. (In the end the problem was caused the computer; it loses around 5 minutes a day...) We will re-word that ASAP.

4. and 5. Average. It'll stay in then and a odd-time-out average mode will be looked into.

9. System log. Yes, the network access ability is a good reason alone.

12. Scan. It's OK. It was a good excuse for some extra testing!

Re: A few iTimeSync suggestions/comments

PostPosted: Tue Apr 21, 2009 2:36 pm
by Unregistered
I hope you're not getting annoyed with me!

Another idea occurred to me just now, after finding I may have had my IP address blocked by a server because it thinks I was being abusive. I accidentally had the same NTP server listed twice in ServFile.txt, with one other server in between:

I can no longer access "", so I'm wondering if it didn't like that I was checking it so repeatedly.

I'm only making an assumption, and I am not asking you what happened. I'm just framing the feature suggestion: A "Scan for duplicates" function! :wink:

In my opinion, it's a good idea (generally speaking) to remove dupes, even if you don't get banned.

[slightly crazy mode]

A basic duplicate-finding function would be really nice, but what would also be really neat is a "DNS duplicate" function. That is, resolve each domain-baesd entry in the list, and flag as a duplicate any matching entry that is listed as an IP address. For example, let's say you have this in your list:

It doesn't look like a standard dupe, but since "" resolves to "" (in this example), it's a duplicate, even though the strings aren't equal... Hence, "DNS duplicates". (I'm really tired, so I'm sure there is a better name for it than "DNS duplicates"...)

[/slightly crazy mode]

OK, before you read on (if you still are...), please understand that I'm not trying to find ways to take up your time and efforts. I'm just throwing this out there because you have a really good attitude and an open mind, not to mention programming skill. I never call these things "requests". I mean them as "ideas" or "suggestions".

On that note, yet another idea: NTP server statistics. I have a pretty big server list, and there are a few servers that time out sometimes, but not all the time. If I could see stats on the servers, I'd know if it was worth keeping these servers in the list. For example, if a server timed out 90% of the time, it's gone. If it timed out 10% of the time, we'll put up with it. (It would be even better if iTimeSync could automatically skip servers that had a bad track record.)

In any case, thanks for reading.

PostPosted: Wed Apr 22, 2009 3:43 pm
by Siegfried
Unregistered wrote:I hope you're not getting annoyed with me!

Not at all; all feedback is good.

Unregistered wrote:In my opinion, it's a good idea (generally speaking) to remove dupes, even if you don't get banned.

Yes, that would be a good idea.

Unregistered wrote:A basic duplicate-finding function would be really nice, but what would also be really neat is a "DNS duplicate" function.

This would be harder as many servers don't have a constant IP. Some services even assign different servers depending on load. Thus you would need a history function to make this work well.

Unregistered wrote:On that note, yet another idea: NTP server statistics.

Actually this is already on the list. We want to give iTimeSync a server database with history. Things like average connection time, average deviation, average error, even the last few IPs :wink: . Then we could use that data to give iTimeSync an auto server select function.

Unregistered wrote:In any case, thanks for reading.

Not a problem. Thanks for sharing your thoughts. :D


PostPosted: Wed Apr 22, 2009 4:31 pm
by Unregistered
Siegfried wrote:
Unregistered wrote:A basic duplicate-finding function would be really nice, but what would also be really neat is a "DNS duplicate" function.

This would be harder as many servers don't have a constant IP. Some services even assign different servers depending on load. Thus you would need a history function to make this work well.

I understand, but I think if you do an ad-hoc scan of the list and find a domain that resolves to an IP that is currently on the list, you can be pretty sure they're dupes. But it's OK, I knew this was kind of an over-the-top suggestion.

Re: A few iTimeSync suggestions/comments

PostPosted: Tue Dec 26, 2017 3:05 am
by rainahuang