Timer idea

Timer idea

[evan]

I was thinking about benchmarking, profiling, and various other applications
that might need frequent access to the current time.  Polling timers or
frequent timer signal delivery both seem like there would be a lot of overhead.
 I was thinking it would be nice if you could just read the time information
without making an OS call.

I figure the kernel keeps accurate records of current time information and the
values of various timers.  I then had the idea that one could have a /dev or
maybe a /proc entry that would allow you to mmap() the kernel records (read
only) and then you could read this information right from the kernel without
any overhead.

Comments?  Please CC me on replies.

Re: Timer idea

[Kenichi Okuyama]

Dear Evan,

>>>>> "Evan" == evan  <evan@coolrunningconcepts.com> writes:
Evan> I was thinking about benchmarking, profiling, and various other applications
Evan> that might need frequent access to the current time.  Polling timers or
Evan> frequent timer signal delivery both seem like there would be a lot of overhead.
Evan>  I was thinking it would be nice if you could just read the time information
Evan> without making an OS call.

This will only work on IA32...but..

I usually use "Time Slice Counter" which is 64bit register counting
up the CPU Freq for this purpose. Since it's built into CPU, no OS
call overhead happens. Also, because now-a-day CPU runs in very high
speed, each count will give you upto 0.3nsec accuracy.

Speed step technology might slow the CPU Freq, so it's true that
things aren't as accurate as it used to be. But this is the best I
can find.

I though similar counter is available for PowerPC too.
# At least, PPC601 had something similar.


Evan> I figure the kernel keeps accurate records of current time information and the
Evan> values of various timers.  I then had the idea that one could have a /dev or
Evan> maybe a /proc entry that would allow you to mmap() the kernel records (read
Evan> only) and then you could read this information right from the kernel without
Evan> any overhead.

There is overhead.

If you mmap(), address is reserved, but shall not have memory
assigned yet. When you read the address, exception will occur, and
then memory will be attached. THIS action is overhead.

Also, once it's attached, there's no way for OS to know when that
mapped page can be freed, to fill in newer value.

I don't think mmap() idea will work as good as it seems.
I might be making mistake, though.

best regards,
---- 
Kenichi Okuyama

Re: Timer idea

[George Anzinger]

evan@coolrunningconcepts.com wrote:
> I was thinking about benchmarking, profiling, and various other applications
> that might need frequent access to the current time.  Polling timers or
> frequent timer signal delivery both seem like there would be a lot of overhead.
>  I was thinking it would be nice if you could just read the time information
> without making an OS call.
> 
> I figure the kernel keeps accurate records of current time information and the
> values of various timers.  I then had the idea that one could have a /dev or
> maybe a /proc entry that would allow you to mmap() the kernel records (read
> only) and then you could read this information right from the kernel without
> any overhead.
> 

Your are describing the vsyscall.  John Stultz and company are actively working on this as we speak. 
  If memory serves, it is already available on some platforms.

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: Timer idea

[john stultz]

On Tue, 2005-11-15 at 10:58 -0800, George Anzinger wrote:
> evan@coolrunningconcepts.com wrote:
> > I was thinking about benchmarking, profiling, and various other applications
> > that might need frequent access to the current time.  Polling timers or
> > frequent timer signal delivery both seem like there would be a lot of overhead.
> >  I was thinking it would be nice if you could just read the time information
> > without making an OS call.
> > 
> > I figure the kernel keeps accurate records of current time information and the
> > values of various timers.  I then had the idea that one could have a /dev or
> > maybe a /proc entry that would allow you to mmap() the kernel records (read
> > only) and then you could read this information right from the kernel without
> > any overhead.
> > 
> 
> Your are describing the vsyscall.  John Stultz and company are actively working on this as we speak. 
>   If memory serves, it is already available on some platforms.

Yep. x86-64 already supports this as does ppc64 via vsyscall/VDSOs. ia64
has a different variant on it as well (fast syscalls).

thanks
-john

Re: Timer idea

[linux-os (Dick Johnson)]

On Tue, 15 Nov 2005 evan@coolrunningconcepts.com wrote:

> I was thinking about benchmarking, profiling, and various other applications
> that might need frequent access to the current time.  Polling timers or
> frequent timer signal delivery both seem like there would be a lot of
> overhead.
> I was thinking it would be nice if you could just read the time information
> without making an OS call.
>
> I figure the kernel keeps accurate records of current time information and the
> values of various timers.  I then had the idea that one could have a /dev or
> maybe a /proc entry that would allow you to mmap() the kernel records (read
> only) and then you could read this information right from the kernel without
> any overhead.

Great invention, read some timer without any overhead! I guess if
you can figure it out you are up for a Nobel Prize, certainly a new
breakthrough.

FYI, even if you put some kernel spinning count in shared-memory,
it would have overhead. In fact, users might even be able DOS the
machine by spinning on that count. Putting time in /proc or /dev
also has great overhead. Have you ever looked at how these
file-systems work?

On ix86 machines, basic time comes from chip(s), read from ports.
That's just another tiny little problem.

The time-keeping in Linux certainly has a few problems and they
don't seem to be getting resolved, just exchanging one set of
problems for another as the timer code has been rewritten many
times. It would helpful if somebody did take a fresh new look
at timekeeping, but reading something from shared memory just
isn't relevant.

>
> Comments?  Please CC me on replies.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.51 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Timer idea

[George Anzinger]

linux-os (Dick Johnson) wrote:
> On Tue, 15 Nov 2005 evan@coolrunningconcepts.com wrote:
> 
> 
>>I was thinking about benchmarking, profiling, and various other applications
>>that might need frequent access to the current time.  Polling timers or
>>frequent timer signal delivery both seem like there would be a lot of
>>overhead.
>>I was thinking it would be nice if you could just read the time information
>>without making an OS call.
>>
>>I figure the kernel keeps accurate records of current time information and the
>>values of various timers.  I then had the idea that one could have a /dev or
>>maybe a /proc entry that would allow you to mmap() the kernel records (read
>>only) and then you could read this information right from the kernel without
>>any overhead.
> 
> 
> Great invention, read some timer without any overhead! I guess if
> you can figure it out you are up for a Nobel Prize, certainly a new
> breakthrough.
> 
> FYI, even if you put some kernel spinning count in shared-memory,
> it would have overhead. In fact, users might even be able DOS the
> machine by spinning on that count. Putting time in /proc or /dev
> also has great overhead. Have you ever looked at how these
> file-systems work?
> 
> On ix86 machines, basic time comes from chip(s), read from ports.
> That's just another tiny little problem.

Its not just shared memory, but a protected very low overhead extension of the kernel code space 
into the user map.  Mostly what is saved is the system call overhead.
> 
> The time-keeping in Linux certainly has a few problems and they
> don't seem to be getting resolved, just exchanging one set of
> problems for another as the timer code has been rewritten many
> times. It would helpful if somebody did take a fresh new look
> at timekeeping, but reading something from shared memory just
> isn't relevant.

Possibly you would like to review what John is doing and make relevent comments.

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: Timer idea

[Christopher Friesen]

linux-os (Dick Johnson) wrote:

> On ix86 machines, basic time comes from chip(s), read from ports.
> That's just another tiny little problem.

I'm sure you already know this, but x86 can also use the HPET for 
timestamps, as well as the TSC if it's available.

Chris

Re: Timer idea

[linux-os (Dick Johnson)]

On Tue, 15 Nov 2005, Christopher Friesen wrote:

> linux-os (Dick Johnson) wrote:
>
>> On ix86 machines, basic time comes from chip(s), read from ports.
>> That's just another tiny little problem.
>
> I'm sure you already know this, but x86 can also use the HPET for
> timestamps, as well as the TSC if it's available.
>
> Chris
>

Yes. Also, it can be 64 bits on 64 bit machines. Memory-mapping
isn't a solve-all, though. The mayor problem is that there
are so many ways to get incompatible time:

 	PIT, RTC, TSC, HPET.

... Every one requires a knowledge of a specific architecture  --
and every one has its own set of problems. If HPET was a problem
solver, then it would be a step in the right direction. Unfortunately
it just makes another set of unique problems.

The new hardware timer should-have-been something that does:

 	(1) A memory mapped register that reads time with
 	microsecond resolution like POSIX wants.
 	(2) A memory mapped register to which is written an
 	offset to adjust the time (in +/- microseconds).
 	(3) A memory mapped register to course-set time like
 	'time_t'.
 	(4) It should have been PCI/Based so if the motherboard
 	didn't have one built-in, you could buy one and plug
 	it in.

... Now, with everything done in hardware, there is no problem
with obtaining a correct, adjustable time. Anything less is
just a patch on a patch. Such a timer-chip, if made with a built-
in low-temperature coefficient AT-cut crystal could have been
developed to sell for under two dollars, in 1,000 quantities. Of
course if you have to make a plug-in board with a PCI interface,
that's much more expensive, but only the cost of a cheap network
card.

It looks like Intel had some timer-chip macro-cells that they
wanted to unload. There was no technical thought put into the
HPET. Yes, they claimed that it can be used for multimedia and,
in fact, it was first called a "multimedia timer". So new
ix86 boards will have what Apple boards have.

In a previous generation, VAXen had the right idea. A separate
device that kept time, starting at zero. The clock time was the
sum of boot-time, clock-time, and time-adjust quadwords. Unfortunately
the time was in micro-fortnights because it used a bus-clock for
the interval.

The concept of the three values, manipulated by hardware, not
software, will certainly be the ultimate solution to time-keeping.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.51 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.