What is the GetTickCount() equivalent in C#?

[EOS]

Hi,

As the title indicated, does anyone know the equivalent of GetTickCount()
function in C/C++ for C#?

The function is supposed to return time elapsed since the computer/device is
booted in milisecond.

By te waym thanks for all the previous help. It is really not easy to
convert current C/C++ codes into the new C# as it is more than different
syntax. I am having headache converting a simple few pages of C/C++ into
C#... At times, I would like to have a simple memcpy in C#.

 

[David Smith]

Easy. Use the Ticks property of the static DateTime.Now, as in DateTime.Now.Ticks.

 

[Peter Rilling]

You should still be able to use it using p/invoke.

It is part of the kernel32.dll.

 

[Mattias Sjögren]

As the title indicated, does anyone know the equivalent of GetTickCount()

function in C/C++ for C#?
System.Environment.TickCount


The function is supposed to return time elapsed since the computer/device is
booted in milisecond.

Then the above is no good since it will wrap around after ~50 days.
Consider checking the System Up Time performance counter instead.


Mattias

 

[Guest]

Use Environment.TickCount property.

 

[Stoitcho Goutsev \(100\) [C# MVP]]

David,

DateTime.Now.Ticks will return the time elapsed since Jan 1st 0001 12:00 AM
in tick units where each unit is 100 nanoseconds. Nothing to do with the
time ellapsed since last time the system has started.

The property to look at is System.Environment.TickCount

I'd suggest reading the help for this property carefully because there might
be some gotchas.
Keep in mind that the C++ methods returns the result in DWORD, which is 32
bit unsigned integer. System.Environment.TickCount is Int32, which is 32 bit
signed integer. That means System.Environment.TickCount will wrap around to
zero sooner than the C++ method - Int32 is half smaller that DWORD in terms
of positive numbers.

 

[EOS]

I am confussed here.

Since GetTickCount() return miliseconds in DWROD (32-bits) and will reach
its limit after around 49 days... and started again.

While how could a higher accuracy of 100 nanoseconds start with Jan 1st 0001
12:00AM? Unless it is 64 bit then...

David,

DateTime.Now.Ticks will return the time elapsed since Jan 1st 0001 12:00
AM in tick units where each unit is 100 nanoseconds. Nothing to do with
the time ellapsed since last time the system has started.

The property to look at is System.Environment.TickCount

I'd suggest reading the help for this property carefully because there
might be some gotchas.
Keep in mind that the C++ methods returns the result in DWORD, which is 32
bit unsigned integer. System.Environment.TickCount is Int32, which is 32
bit signed integer. That means System.Environment.TickCount will wrap
around to zero sooner than the C++ method - Int32 is half smaller that
DWORD in terms of positive numbers.



--
HTH
Stoitcho Goutsev (100) [C# MVP]

Easy. Use the Ticks property of the static DateTime.Now, as in
DateTime.Now.Ticks.

 

[EOS]

I am sorry that I did not specify it is meant for PDA, compact .net

 

[EOS]

Thanks for the straight answer.

I guess 49~50 days is perfectly acceptable since I am developing for PDA,
which usually require re-boot within the duration. Lame but truth.

 

[Stoitcho Goutsev \(100\) [C# MVP]]

EOS,

System.Environment.TickCount has nothing to do with DateTime and its
100-nanoseconds accuracy. They are implemented differently and they
expilicitly state this in MSDN:

MSDN:
" Remarks
The value of this property is derived from the system timer and is stored as
a 32-bit signed integer. Therefore, the elapsed time will wrap around to
zero if the system is run continuously for 24.9 days.

The resolution of the TickCount property cannot be less than 500
milliseconds.

The TickCount property handles an overflow condition by resetting its value
to zero. The minimum value returned by TickCount is 0.

TickCount is different from the Ticks property, which is the number of
100-nanosecond intervals that have elapsed since 1/1/0001, 12:00am.

Use the DateTime.Now property to obtain the current local date and time on
this computer. "


--

Stoitcho Goutsev (100) [C# MVP]

I am confussed here.

Since GetTickCount() return miliseconds in DWROD (32-bits) and will reach
its limit after around 49 days... and started again.

While how could a higher accuracy of 100 nanoseconds start with Jan 1st
0001 12:00AM? Unless it is 64 bit then...

David,

DateTime.Now.Ticks will return the time elapsed since Jan 1st 0001 12:00
AM in tick units where each unit is 100 nanoseconds. Nothing to do with
the time ellapsed since last time the system has started.

The property to look at is System.Environment.TickCount

I'd suggest reading the help for this property carefully because there
might be some gotchas.
Keep in mind that the C++ methods returns the result in DWORD, which is
32 bit unsigned integer. System.Environment.TickCount is Int32, which is
32 bit signed integer. That means System.Environment.TickCount will wrap
around to zero sooner than the C++ method - Int32 is half smaller that
DWORD in terms of positive numbers.



--
HTH
Stoitcho Goutsev (100) [C# MVP]

Easy. Use the Ticks property of the static DateTime.Now, as in
DateTime.Now.Ticks.

Hi,

As the title indicated, does anyone know the equivalent of
GetTickCount() function in C/C++ for C#?

The function is supposed to return time elapsed since the
computer/device is booted in milisecond.

By te waym thanks for all the previous help. It is really not easy to
convert current C/C++ codes into the new C# as it is more than
different syntax. I am having headache converting a simple few pages
of C/C++ into C#... At times, I would like to have a simple memcpy in
C#.

 

[Stefan Simek]

Hi,

I just want to correct the fact about wrapping. The
Environment.TickCount indeed is of type int (which is CLS compliant)
instead of uint/DWORD for GetTickCount() (which is non-compliant), but
it is a direct wrapper of GetTickCount() otherwise. The old MSDN
documentation didn't state that it wraps to zero - because it wraps to
int.MinValue. This is corrected in the new MSDN, which states:

The value of this property is derived from the system timer and is
stored as a 32-bit signed integer. Consequently, if the system runs
continuously, TickCount will increment from zero to Int32.MaxValue for
approximately 24.9 days, then jump to Int32.MinValue, which is a
negative number, then increment back to zero during the next 24.9 days.

The standard (Environment.TickCount - tStart > tDelay) test wouldn't
work if the value wrapped to zero.

Just my 2c.

 

[Danny Tuppeny]

MSDN:
" Remarks
The value of this property is derived from the system timer and is stored as
a 32-bit signed integer. Therefore, the elapsed time will wrap around to
zero if the system is run continuously for 24.9 days.

So even Microsoft don't have faith in their machines being up for 25
days? That's just great!

 

[Danny Tuppeny]

System.Environment.TickCount has nothing to do with DateTime and its
100-nanoseconds accuracy. They are implemented differently and they
expilicitly state this in MSDN:

MSDN:
" Remarks
The value of this property is derived from the system timer and is stored as
a 32-bit signed integer. Therefore, the elapsed time will wrap around to
zero if the system is run continuously for 24.9 days.

Wrap around to 0? I thought a signed in would go to negatives when it
overflowed?

eg. 24.8 -> 24.9 -> -24.9 -> -24.8 ??
(I've never written anything that relies on this "fact", it was just my
understanding!)

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Reading carefully you'll see they explain this:
"... The TickCount property handles an overflow condition by resetting its
value ..."

Well regarding the faith in the system.... I don't see much difference.
System working for only 50 days is as bad as system working for 25. I
rather think that they use Int32 because usnigned types are not CLS
compliant.

Anyways, as I said 50 is not much better than 25, so I believe if you look
for bigger accuracy you'll be better off with reading *System Up Time*
performance counter.

using System.Diagnostics;
.....
PerformanceCounter upTime = new PerformanceCounter("System","System Up
Time");
// You've got to call this twice. First time it returns 0 and
// second time it returns the real info.
upTime.NextValue();
MessageBox.Show(String.Format(TimeSpan.FromSeconds(upTime.NextValue()).ToString()));

You need to keep in mind the following:
1. Performance counters are part of WMI and as such they are protected by
their own security settings (user rights are privileges). It won't be a
problem for desktop applications, but it might be for web application when
using impersonation.
2. Reading performance counters is not one of the fastest operations and
you might run into performance problems if you do this very often
3. "Syste Up Time" takes into consideration only the time when the system is
running that is the time that the system spend in hibernation does no count.
Thus this counter cannot be used to calculate the exact system boot date and
time.

--

Stoitcho Goutsev (100) [C# MVP]


to zero. The minimum value returned by TickCount is 0.

 

[Danny Tuppeny]

Reading carefully you'll see they explain this:
"... The TickCount property handles an overflow condition by resetting its
value ..."

I thought it probably did, right after posting!

 

[Danny Tuppeny]

The value of this property is derived from the system timer and is
stored as a 32-bit signed integer. Consequently, if the system runs
continuously, TickCount will increment from zero to Int32.MaxValue for
approximately 24.9 days, then jump to Int32.MinValue, which is a
negative number, then increment back to zero during the next 24.9 days.

Now I'm confused! Does it wrap to MinValue, or reset to 0? :-\

 

[Stefan Simek]

Now I'm confused! Does it wrap to MinValue, or reset to 0? :-\

It wraps to MinValue. If you think of it in hex, 0x7fffffff is
int.MaxValue, and next is 0x80000000 which is int.MinValue. The counter
is simply continuously incremented without any special cases like
wrapping from 0x7fffffff to 0.

Stefan

 

[Danny Tuppeny]

It wraps to MinValue. If you think of it in hex, 0x7fffffff is
int.MaxValue, and next is 0x80000000 which is int.MinValue. The counter
is simply continuously incremented without any special cases like
wrapping from 0x7fffffff to 0.

But what Stoitcho Goutsev posted says MSDN says the opposite! :\

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Dany,

The one that I've posted comes from the docs for .NET1.x the one that Stefan
posted is from the .NET2.0 docs. It is possible that they've made one of
these "minor" changes that can make one's life miserable .
Unfortunately it is hard to test. Even the method is implented internally in
the CLR and reflector tools and ILDasm won't help.

I personally still think that majority of the programmers hasn't switched
yet to VS2005 and .NET 2.0 so if the version is not specified I assume
..NET1.x.

 

[Mattias Sjögren]

The one that I've posted comes from the docs for .NET1.x the one that Stefan

posted is from the .NET2.0 docs. It is possible that they've made one of
these "minor" changes that can make one's life miserable .

No it was the documentation that was incorrect. Even in 1.x it was no
more than a straight call to GetTickCount().


Mattias