If my mobile device has wrong time (more or less 5 minutes than actual time), the cosmosDB sdk never works on any query. But it works if the time difference is less than 5 minutes from actual time. Now, the problem is, some of our customers can set time, say 10 minutes ahead of actual time. So we can't use cosmosDB Sdk anymore?
This is expected behaviour and you'll find this with most secure systems.
SSL/TLS, for instance, which is what most web technologies use for secure transmission of data, relies heavily on clock synchronisation for certificate validation and revocation checks (amongst other things).
https://security.stackexchange.com/questions/72866/what-role-does-clock-synchronization-play-in-ssl-communcation
So it's pretty much the case that you're going to have to get your clocks synchronised or you're going to run into a lot of issues with this sort of thing.
The alternative, is to use unsecured systems. However, for the love of all that is holy, don't go down that route.
A potential workaround to all of this would be to containerise your solution and have an accurate clock within that container. That way your service knows the real time and what your customers have as their desktop clocks doesn't matter but it's really far from ideal.
I have to start a program on several computers at the same time (within ms).
The program read out of and write into a mysql database. To ensure the simultaneous start, I thought about the sql dependency but does it also work for mysql? Are there any other ways to guarantee the synchronous start?
It´s a project inside a laboratory. So it´s just a small network.
Greetz
Synchronyze Operating System clocks with and NTP and schedule the start (once loaded) to ensure real-time synchrony.
Run your program with a clocktime to start, and put some trigger to do it.
I'm working for years in distributed systems and is the most common solution.
Accuracy on todays clocks starts on nanosecs (10^-6 secs) and there's high accuracy clocks (10^-7 till 10^-8 secs)
You can read a discussion about clocks here and Time synchronization vs alternatives here
I want to generate a serial number for an application (to be used just in a period of time), this serial number based on the time, so it's will be unnecessary code if change the clock time in my computer so am asking you if is there any possibility to get the real DateTime even if i changes time on my computer using C# ?
(I assume that the user does not have an internet connection)
am asking you if is there any possibility to get the real DateTime even if i changes time on my computer using C# ?
(I assume that the user does not have an internet connection)
No. The system clock is the local source of time information. If you can't go to a reliable external source (due to a lack of internet connection) there's nothing else you can rely on.
I suggest you use an internet connection to check the time if there is one, otherwise fall back on the system clock, possibly detect time having been reversed significantly (if at one point you "see" the time as April 20th, and then at another you "see" the time as April 15th, you can assume something odd is going on) and accept that a sufficiently motivated user will bypass the check.
What people do: Record the time (of local clock) when your program was executed somewhere in the registry (or another hard to guess place).
If your program runs again and finds local time being before this recorded timestamp it refuses to start.
This is a method to prevent users from manipulating the clock in order to reactvate your license.
You'll have to consider chages in daylight saving time, so you should allow one hour of "time jumps"
Base Issue
I am having an issue with time stamps in my C# application. I receive data from a remote TCP connection asynchronously. Every time I receive data, I update a time stamp variable to DateTime.Now. On a separate thread, once a second, I check if it has been longer than a predefined timeout period since my last receive and if so, disconnect. This method has been working for many years, but now I have a situation where the application is installed on a machine with an unstable time source. Every few days, the machine time "auto-corrects" and I drop the connection prematurely. The code is basically as follows:
Receive Process
void OnReceiveComplete(IAsyncResult ar) {
...
mySocket.EndReceive(ar);
lastRxTime = DateTime.Now;
...
}
Check Process
void CheckConnection() {
TimeSpan ts = DateTime.Now.Subtract(lastRxTime);
if(ts.TotalMilliseconds > timeout) {
Disconnect(string.Format("No packet received from the server for over {0} seconds.", timeout / 1000));
}
}
I have valid Wireshark captures during the issue and right before the disconnect I see NTP traffic that culminates in what looks like a correction of at least 1 minute. This obviously causes the check process to fail.
Technical Details/Answers to Expected Questions
I have control of both ends of the connection, but not the physical layer in between (often a low quality satellite link), This is why this timeout check is in place.
Since the data is Asynchronous, there is a provision to send out a small heartbeat if no data has been sent from the server for a period of time equal to half the timeout.
There can be multiple instances of this process (i.e. on machine connecting to multiple different servers.
All communications use Asynchronous methods (which supposedly use completion ports).
The check process is run on a separate thread that is shared by all clients on a single machine.
Completed Research (i.e. Possible Solutions)
My Google searches to this point have lead to the following:
I realize I should have used DateTime.UtcNow instead of DateTime.Now for performance reasons. This would not affect the issue itself.
An implementation depending on Ticks would be a better solution.
There are two options for getting ticks - Environment.TickCount and Stopwatch.GetTimestamp()
According to my research, Environment.TickCount may be susceptible to time adjustments, but I am not sure under what circumstances. Also, since I use this same methodology in other higher performance circumstances, the 10-16 mSec resolution may be an issue (though not in the specific case I am presenting here).
The Stopwatch.GetTimestamp() can fallback to DateTime.Now.Ticks when a High Performance clock is unavailable. I am unsure how often that will occur (do any machines NOT come with a high performance clock anymore), but I am certain that if it resorts to Ticks the same issue will occur.
I have also read that Stopwatch.GetTimestamp() will use the QueryPerformanceCounter() API call, and that can be unstable when called from multiple threads.
Ultimate Question
I am curious what the best method to generate the lastRxTime time stamp would be? Am I worrying too much about low likelihood issues in the Environment.TickCount and Stopwatch.GetTimestamp() functions? I am open to alternative implementations as long as they take the multi-threaded nature of the application as well as the link quality issues into account.
UPDATE 7/17/2013 (A solution has been deployed!)
I have deployed a solution and want to let everyone in on the details. In general, there may not be one accepted answer, but after going through this experience I can say that the original solution was definately an issue. I will try to provide as much detail as possible:
First, the NTP issue was actually a symptom of a different issue. The network exhibiting the issue is AD Domain with the two servers running my code set up as Domain Controllers. It turns out DCs are time sources for the domain. It also turns out that the system time drifts from the real time clock on these systems by up to a minute over approximately 11 days, at which point Windows is correcting the slip. Once it corrects the slip on the first DC, the second DC syncs his time and both run into the problem described above.
Based on the feedback and my original research, I created a test program to run during a disconnect to log values for DateTime.Now, Environment.TickCount, and Stopwatch.GetTimestamp(). What I found was that during the correction, neither Environment.TickCount nor StopWatch.GetTimeStamp() slipped at all, meaning they were good candidates to use as a replacement for DateTime.Now(). I went with TickCount because it is guaranteed to be on all of my deployed servers (whereas the stopwatch could fall back to the DateTime object on some machines that I have yet to find). It is working so far without issue. I did due dilligence on the roll-over issue to prevent that form being a problem, but will need to wait for my system to be up that long be sure.
I want to note that if anybody else is experiencing similar problems, they should not discount the use of any of the other presented solutions in the list below. Each has its own merrit, in fact the simple counter is likely the best solution for most circumstances. The reason I did not go to this solution was that I have similar code in separate area that depends heavily on tight timings. I cna handle the 16 mSec or so resolution of the tick count there, but cannot handle the drift of time that the counter solutions incur (I used code like that in a separate product that wound up drifting by over a second an hour and bringing me out of spec for the project).
Again, thanks to all and if any more comes up I will be sure to update the question.
I don't see any problem with using Environment.TickCount. The documentation states that it returns:
A 32-bit signed integer containing the amount of time in milliseconds that has passed since the last time the computer was started.
It goes on to say:
The value of this property is derived from the system timer and is stored as a 32-bit signed integer.
I'm not seeing how NTP time correction can affect this. Do you have a link that suggests otherwise? The tricky part is dealing with the wrap-around. So, when comparing the current tick count to the previous, if you get a negative number, you'll know wrap-around occurred.
Personally, I think this is the superior mechanism to use, because the return value is in millisonds, so the conversion factor for your timeout will be straightforward. Otherwise, with Stopwatch.GetTimestamp you'll have to do some additional work to factor in the tick frequency.
Furthermore, I'm assuming this is implemented internally with a call to the Win32 GetTickCount function. (dotPeek shows that it's marked with MethodImplOptions.InternalCall, so I can't tell for sure) But the documentation for that states:
Remarks
The resolution of the GetTickCount function is limited to the
resolution of the system timer, which is typically in the range of 10
milliseconds to 16 milliseconds. The resolution of the GetTickCount
function is not affected by adjustments made by the
GetSystemTimeAdjustment function.
On second thought, since you're periodically checking only every second, the resolution of the timer only has to be < 1 sec. There is zero point in trying to do any better, so why use any API call at all?
private int m_conTimer;
void OneSecondThreadCallback() {
if (++m_conTimer >= TIMEOUT_VALUE)
// Connection timed out. React accordingly.
}
There are a few good reasons not to use DateTime.Now for this purpose
As you pointed out, there are performance issues. Mostly this is because it internally has to translate to the local time zone.
Since it is the "now" of the local time zone, it is unsuitable for comparison or calculation. This is because many time zones have discontinuities twice a year as Daylight Saving Time transitions occur. If you are comparing against your last event time, then when the clocks roll forward you would have an extra hour. When they roll back, you could be off anywhere from 0 to 60 minutes (depending on exactly when you did your comparison).
It has a much lower precision than Stopwatch or Environment.TickCount. While DateTime is capable of representing very small amounts of time, the system clock itself is only accurate to about 10 to 30 ms. (But perhaps that's not so important for your use case.)
Using DateTime.UtcNow does address the first two points, but not the third. For that, you need to stay away from DateTime completely.
Also - there is the concept of "clock drift". Clocks may slow down or speed up over extended periods. If the OS has a time synchronization source, it can actually adjust the amount of time that actually passes in a tick in order to compensate. You can read more in this article (see the "Time Adjustments" section).
You may also be interested in the ClockRes utility can be used to give you information about your system timer resolution.
HOWEVER - your use case is probably best served not by any of these techniques. You said you were interested in cancelling an event after a timeout period. You also said that you have a separate thread that checks periodically to see if the timeout period has elapsed. All of that is unnecssary. Instead, just use a Timer class.
Be careful, there are three different timers available in .Net. You probably want a System.Threading.Timer:
// start the timer, callback in 10000 milliseconds, and don't fire more than once
var timer = new Timer(TimerCallback, null, 10000, Timeout.Infinite);
// to reset the timer when you receive data
timer.Change(10000, Timeout.Infinite);
// to stop the timer completely
timer.Change(Timeout.Infinite, Timeout.Infinite);
// and in your callback
private void TimerCallback(object state)
{
// disconnect, or do whatever you want
}
If its possible you would be resetting the timer from multiple threads, then you should instead use a System.Timers.Timer - which is thread safe.
// to set up the timer
var timer = new Timer(10000) {AutoReset = false};
timer.Elapsed += TimerOnElapsed;
// to start the timer running
timer.Start();
// to reset the timer
timer.Stop();
timer.Start();
// and the callback
private void TimerOnElapsed(object sender, ElapsedEventArgs args)
{
// disconnect, or do whatever you want
}
Am I worrying too much about low likelihood issues in the Environment.TickCount and Stopwatch.GetTimestamp() functions?
Potentially, yes.
I would prefer the Stopwatch.GetTimestamp() option. This will use high performance timers if they are available on your system, and fallback to DateTime.Ticks if that isn't an option. As such, you'll get the best possible timing when available on your given hardware, and a good option as a fallback when high performance timers are not available.
While Environment.TickCount could be an interesting option, you would need to handle the case where this overflows if it's possible that your machine will be operational for more than 24.9 days.
One of the analytics that I had to have on my program was How much time do users spend on my program? It is basically a measure of how useful the users find my program that they actively keep on using it. and used to promote users to actively start using the application.
I initially thought of using Time Span between when they start the application to when they close it but the problem was that users could just keep the application open and not use it.
I currently use TotalProcessorTime (C#/VB .Net) to let management know how much time users actively spend on the application. TotalProcessorTime give the amount an application uses the CPU but this does not translate well to management because even when a user actively uses the application for a few minutes the TotalProcessorTime would be far less.
Any out of the box thinking / suggestions?
Since you want to know how much people use your software as opposed to how long your software uses the CPU (they aren't always the same thing), the way I'd do it (and I actually used this before) is to use GetLastInputInfo.
You can have a timer in your application and check every say.. 500ms if your application is the active application and GetLastInputInfo returns the system has been idle for less than some threshold (5-10sec depending on what your application does). As long as both of these two conditions hold, you can add 500ms to your application active usage.
Of course, you can still track total CPU usage as a separate statistic, but I think my way provides a more... focused usage counter for your application.