> On June 28, 2012, 5:55 p.m., Chug Rolke wrote: > > My experience with the filetime TIMEOFDAY methods is that they have clunky > > granularity. When I run the proposed solution in a test I get: > > > > 2012-06-28 13:44:47.739508 > > 2012-06-28 13:44:47.739508 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.755108 > > 2012-06-28 13:44:47.770708 > > 2012-06-28 13:44:47.770708 > > > > The time does not increment smoothly but takes discrete (1/64th second?) > > steps. > > > > The performance counter method being replaced uses high frequency free > > running clock and gets better resolution of sub-second time. > > > > I would approve the proposed method if we print only two significant digits > > of sub-second time (down to 100ths of a second).
Good point - it takes about 15ms jumps... let me look more at using QueryPerformanceCounter... it used to vary depending on which CPU it was executed, but I believe that's been resolved for long enough to safely use it. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5624/#review8721 ----------------------------------------------------------- On June 28, 2012, 12:11 a.m., Steve Huston wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/5624/ > ----------------------------------------------------------- > > (Updated June 28, 2012, 12:11 a.m.) > > > Review request for qpid and Alan Conway. > > > Description > ------- > > This patch changes from seconds-since-start format to time-with-microseconds > time when --log-highres-timestamp yes is supplied. This is closer to the > Linux output, though Linux logs with nanoseconds while Windows logs with > microseconds. > > The output on Windows will change from something like this: > > 0000000.00000798s [Security] error Failed to initialise SSL listener: > Locating c > ertificate smokey-win7 in store My Cannot find object or property. > (E:\qpid\tru > nk\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp:193) > 0000000.07750290s [Network] notice Listening on TCP/TCP6 port 5672 > 5672 > 0000000.10241085s [Broker] notice Broker running > 0000005.32722109s [Broker] notice Shut down > > to this: > > 2012-06-27 19:55:25.403936 [Security] error Failed to initialise SSL > listener: L > ocating certificate smokey-win7 in store My Cannot find object or property. > (E: > \qpid\trunk\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp:193) > 2012-06-27 19:55:25.497537 [Network] notice Listening on TCP/TCP6 port 5672 > 5672 > 2012-06-27 19:55:25.528737 [Broker] notice Broker running > 2012-06-27 19:55:42.891551 [Broker] notice Shut down > > > This addresses bug QPID-4084. > https://issues.apache.org/jira/browse/QPID-4084 > > > Diffs > ----- > > trunk/qpid/cpp/src/qpid/sys/windows/Time.cpp 1354301 > > Diff: https://reviews.apache.org/r/5624/diff/ > > > Testing > ------- > > Build, run qpidd with --log-highres-timestamp yes enabled. Sanity check the > times displayed. > > > Thanks, > > Steve Huston > >
