Datetime Granularity between 32bit and 64bit Windows

Question

I have create a little engineering app for some network debugging. It takes a list of IP addresses and pings them, with user set timeout and rate. It logs the average round-trip time and every time one of the sends fails it logs it's duration of failure and a timestamp of when it happened...

That's the idea. I developed it on a Win7 machine with .Net4 and have had to put the thing on a set of XP laptops.

The problem is the duration values on my box during testing show nice ms durations, on the XP boxes when I look they show 0 or 15.625 (magic number?)... and have the funny square, box symbol in the string?

    public void LinkUp()
    {
        if (_isLinkUp) return;

        _upTime = DateTime.Now;
        var span = _upTime.Subtract(_downTime);
        _downTimeLog.Add(new LinkDown()
                            {
                                _span = span,
                                _status = _ipStatus,
                                _time = _downTime
                            });
        _isLinkUp = true;
    }

That's the bit that does the log. The _ipStatus is the ping failure reason (typically timeout).

    _downEventLog.AppendLine("  Duration-> " + linkDownLogEvent._span.TotalMilliseconds + "ms\n");

That's the bit that does the print... Can anyone shed any light on this apparent difference?

The question has been answered but I will include an edit here for some more info.

EDIT:

It seems that the difference was down not to the Win7 and WinXP difference but 32bit and 64bit.

In a 32 bit windows systems as Henk points out, the granularity of the system clock is 15-16ms, this is what gave me the value of 15.625 for every value less than 16ms for the timespan.

In a 64 bit system the system call is to a different set of methods that have a much finer granularity. So on my dev machine in x64 I had ms accuracy from my system clock!

Now, the stopwatch uses a hardware interface via the processor instrumentation to record a much finer granularity (probably not every processor tick, but I imagine something obscenely accurate in-line with this thinking). If the hardware underlying the OS does not have this level of instrumentation, it will however use the system time. So beware! But I would guess most modern desktops/laptops have this instrumentation... Embedded devices or things of that nature might not, but then the stopwatch class is not in the Compact Framework as far as I can see (here you have to use QueryPerformanceCounter()).

Hope all this helps. It's helped me a lot.

Somewhere around the _spanStopWatch initialiser:

    if (!_spanStopWatch.IsHighResolution)
    {
        throw new ThisMachineIsNotAccurateEnoughForMyLikingException("Find a better machine.");
    }

The nuts and bolts:

    public void LinkUp()
    {
        if (_isLinkUp) return;

        _spanStopWatch.Stop();
        var span = _spanStopWatch.Elapsed;
        _downTimeLog.Add(new LinkDown()
                            {
                                _span = span,
                                _status = _ipStatus,
                                _time = _downTime
                            });
        _isLinkUp = true;
    }

Answer 1

0 or 15.625 (magic number?)

Yes, using DateTime.Now is accurate only to the length of a CPU timeslice, 15-20 ms depending on your hardware and OS version.

Use System.Diagnostics.Stopwatch for more accurate timing.