Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Wed, 30 Aug 2000 17:28:58 -0400 (EDT)
Message-Id: <200008302128.RAA13218@zingy.ncsl.nist.gov>
From: Joe Konczal <joe DOT konczal AT nist DOT gov>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: gettimeofday is 1000 us slow

In cygwin-1.1.1/winsup/cygwin/times.cc, line 180, s.wMilliseconds is
set to 1, but it should be zero.  This is used to obtain the 64 bit
value corresponding to the epoch, defined in line 29 as FACTOR, which
is subtracted from MS FILETIME values when converting to a Unix
timeval.  This makes all the timevals 1 ms slow.  The correct value
for factor is 0x19db1ded53e8000LL, not 0x19db1ded53ea710LL.

In line 175, the correct value for s.wDayOfWeek is 4, not 5, but it
appears to be ignored.  According to "cal 1 1970" on Solaris 8,
January 1, 1970 was a Thursday, and the Windows PSDK documentation for
SYSTEMTIME says that wDayOfWeek starts with 0 for Sunday.

The resolution of gettimeofday() is also limited, in Windows 2000 at
least, by obtaining the time as a SYSTEMTIME with GetSystemTime() and
converting it to a FILETIME with SystemTimeToFileTime() in lines
142--144.  The resolution of SYSTEMTIME is limited to milliseconds,
but FILETIME has a resolution of 100 ns.  If the time is obtained
directly as a FILETIME with GetSystemTimeAsFileTime(), then Windows
2000 gives you fractions of milliseconds, although I have not verified
their accuracy.

I tested cygwin cygwin-1.1.4 and found the same error in the time
obtained by gettimeofday().

-- 
Joseph C. Konczal     <joe DOT konczal AT nist DOT gov>    (301) 975-3285       TECH A228
Computer Scientist                                 NIST
Visualization and Virtual Reality Group            100 Bureau Dr., Stop 8940
National Institute of Standards and Technology     Gaithersburg, MD 20899-8940

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com