Mauricio wrote:

But benchpress uses Data.Time.Clock.getCurrentTime. I understand that is dependent from configuration. It's okay to benchmark a fast application, but mine will be running for days, so it would not be reliable.

benchpress also uses System.CPUTime -- is that what you are looking for? Martijn.

Hello Mauricio, Friday, January 9, 2009, 4:01:18 PM, you wrote:

computer has been turned on would do all I need. Or, maybe, how much has elapsed since the program started.

i think you should look into system counters (if you on windows). for example, task managet in vista shows time since reboot, i think that in registry it should be available in previous windowses too. at the cpu level, there is cpu ticks counter, it should be readable via special libraries -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Cetin, Friday, January 9, 2009, 4:29:04 PM, you wrote: yes, i mean this lib but forget its name :) thank you

Don't know if it might help but: http://en.wikipedia.org/wiki/RDTSC cabal install rdtsc http://hackage.haskell.org/packages/archive/rdtsc/1.1.1/doc/html/System-CPUT...

Regards, CS

2009/1/9 Bulat Ziganshin Hello Mauricio,

Friday, January 9, 2009, 4:01:18 PM, you wrote:

...

computer has been turned on would do all I need. Or, maybe, how much has elapsed since the program started.

i think you should look into system counters (if you on windows). for example, task managet in vista shows time since reboot, i think that in registry it should be available in previous windowses too. at the cpu level, there is cpu ticks counter, it should be readable via special libraries

-- Best regards,  Bulat                            mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Cetin Sert ha scritto:

Don't know if it might help but: http://en.wikipedia.org/wiki/RDTSC cabal install rdtsc http://hackage.haskell.org/packages/archive/rdtsc/1.1.1/doc/html/System-CPUT...

Note that the use of RDTSC register has some issues on multicore CPU. More info at: http://en.wikipedia.org/wiki/Rdtsc Regards Manlio Perillo

On Fri, 09 Jan 2009 11:01:18 -0200, you wrote:

I'm writing a program that will read medical signs from many patients. It's important to have a precise measure of the time interval between some signs, and that can't depend on adjustments of time. (Supose my software is running midnight at the end of a year with leap seconds. I would get wrong time intervals.)

If you really need that level of accuracy, there is nothing available on an off-the-shelf machine that will do the job. You need an independent timekeeping source of some kind, one that is not subject to the vagaries of reboots and other upsets. Perhaps the simplest and least expensive of these is a computer-compatible GPS time receiver. Since GPS works on GPS time (which has a constant offset from International Atomic Time), rather than UTC, you avoid having to deal with leap seconds and the like. I haven't tried doing it myself, but I know that most recent-vintage GPS units have a computer interface over which you can download the current GPS time from the device. There are many other kinds of GPS time receivers available, including ones that plug directly into a PC slot. Here's one that I found using a Google search on "GPS time receiver": http://www.franklinclock.com/gps_receivers.htm The prices range anywhere from a couple of hundred dollars for consumer-grade equipment to many thousands for high-reliability devices. The only drawback to this approach that I can think of is if the hospital is in an urban area with lots of tall buildings, it might be difficult to obtain a GPS signal of high enough quality. Some of the purpose-built GPS time receivers have better antennas than a consumer-grade GPS device. Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/

John Goerzen ha scritto:

Steve Schafer wrote:

...

On Fri, 09 Jan 2009 11:01:18 -0200, you wrote:

...

I'm writing a program that will read medical signs from many patients. It's important to have a precise measure of the time interval between some signs, and that can't depend on adjustments of time. (Supose my software is running midnight at the end of a year with leap seconds. I would get wrong time intervals.) If you really need that level of accuracy, there is nothing available on an off-the-shelf machine that will do the job. You need an independent timekeeping source of some kind, one that is not subject to the vagaries

I'm not sure that the original question implied *that* level of need.

Linux has High-Resolution Timers (HRTs) that may be appropriate. See the manpage for clock_gettime(), which defines these HRTs:

[...]

CLOCK_MONOTONIC, in particular, looks suitable. Using it could be a matter of just a few quick likes in FFI.

There is also an available package on Hackage: posix-realtime.

I don't know if Windows has similar features.

http://msdn.microsoft.com/en-us/library/ms632592(VS.85).aspx and QueryPerformanceCounter, in detail. Unfortunately, documentation is really bad, and it is not really clear what "high-resolution performance counter" means.

-- John

Manlio Perillo

Here's a basic draft project for clock_gettime(CLOCK_MONOTONIC, ...) http://sert.homedns.org/hs/mnsec/ http://sert.homedns.org/hs/mnsec/dist/mnsec-1.0.0.tar.gz It could be extended to cover other clock types than just monotonic. Regards, CS 2009/1/9 John Goerzen

Steve Schafer wrote:

...

On Fri, 09 Jan 2009 11:01:18 -0200, you wrote:

...

I'm writing a program that will read medical signs from many patients. It's important to have a precise measure of the time interval between some signs, and that can't depend on adjustments of time. (Supose my software is running midnight at the end of a year with leap seconds. I would get wrong time intervals.)

If you really need that level of accuracy, there is nothing available on an off-the-shelf machine that will do the job. You need an independent timekeeping source of some kind, one that is not subject to the vagaries

I'm not sure that the original question implied *that* level of need.

Linux has High-Resolution Timers (HRTs) that may be appropriate. See the manpage for clock_gettime(), which defines these HRTs:

CLOCK_REALTIME System-wide real-time clock. Setting this clock requires appropriate privi- leges.

CLOCK_MONOTONIC Clock that cannot be set and represents monotonic time since some unspeci- fied starting point.

CLOCK_PROCESS_CPUTIME_ID High-resolution per-process timer from the CPU.

CLOCK_THREAD_CPUTIME_ID Thread-specific CPU-time clock.

CLOCK_MONOTONIC, in particular, looks suitable. Using it could be a matter of just a few quick likes in FFI.

I don't know if Windows has similar features.

-- John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Steve Schafer ha scritto:

On Fri, 09 Jan 2009 09:28:49 -0600, you wrote:

...

I'm not sure that the original question implied *that* level of need.

I can't imagine being worried about leap seconds yet at the same time being willing to accept the potential vagaries of any of the built-in clocks.

POSIX realtime extensions have been developed to be high reliable. I don't know if the implementations on general purpose operating systems like Linux are reliable, but in case of problems one can try to switch to a real time operating system. This resources may be useful: http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html Timing is, however, a complex issue.

Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com

Manlio Perillo

...

POSIX realtime extensions have been developed to be high reliable.

(...) However, they offer no guarantees on interval measurements, and the correction algorithms can cause the measurement of a time interval of an hour or so duration to be off by +/- 1 sec, especially within the first few hours after a cold boot. (...)

At the start of this thread, my assumption was that all computers had a 100% reliable tick counter. Well, this shows I understand nothing about hardware. My problem is that the equipment I interact with is supposed to deliver data at a constant rate. Since I don't know how much its engineers care about patients, I wanted to be sure not to save wrong information. It wouldn't matter if the clock is saying we are on XVII century, as long as 10 seconds would never be 10.1. But, as I learned from you, my PC is not to be considered as a reference. Maybe the right approach is to ask people who understand hardware if mine is actually a valid concern. Thanks, Maurício

Mauricio wrote:

patients, I wanted to be sure not to save wrong information. It wouldn't matter if the clock is saying we are on XVII century, as long as 10 seconds would never be 10.1.

Chris (yes I am an experimental physicist) asks: What are the interval durations you need to measure? 0.1 second is very different from 1 ms or 0.1 μs ! (1 ms is the atomic time radio signal accuracy) (0.1 μs can be had with GPS receivers) Since they are from equipment, what is the spec? What is the error tolerance for these durations? How are these errors allowed or forbidden to accumulate? Since you say you do not trust the incoming timing then you need to be able to measure it. Do you need to monitor the timing of each and every measurement while running? Could you measure and certify the timing of the equipment before using it? Got a cheap oscilloscope?