Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #2384 > unrolled thread

Realtime clock accessible without context-switch?

Back to article view | Back to comp.os.linux.hardware

Contents

  Realtime clock accessible without context-switch? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-20 10:29 +0000
    Re: Realtime clock accessible without context-switch? Clemens Ladisch <clemens@ladisch.de> - 2014-05-20 21:56 +0200
      Re: Realtime clock accessible without context-switch? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-21 07:29 +0000
        Re: Realtime clock accessible without context-switch? Thomas Richter <thor@math.tu-berlin.de> - 2014-05-21 09:47 +0200
        Re: Realtime clock accessible without context-switch? William Unruh <unruh@invalid.ca> - 2014-05-21 15:51 +0000
        Re: Realtime clock accessible without context-switch? Clemens Ladisch <clemens@ladisch.de> - 2014-05-21 19:32 +0200
          Re: Realtime clock accessible without context-switch? Richard Kettlewell <rjk@greenend.org.uk> - 2014-05-21 23:35 +0100
            Re: Realtime clock accessible without context-switch? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-05-22 07:53 +0000
              Re: Realtime clock accessible without context-switch? Clemens Ladisch <clemens@ladisch.de> - 2014-05-22 20:36 +0200
                Re: Realtime clock accessible without context-switch? Richard Kettlewell <rjk@greenend.org.uk> - 2014-05-22 20:26 +0100
                  Re: Realtime clock accessible without context-switch? William Unruh <unruh@invalid.ca> - 2014-05-22 22:48 +0000
          Re: Realtime clock accessible without context-switch? Jan Pieter <jp@jp.dhs.orig> - 2014-06-01 09:58 +0200
    Re: Realtime clock accessible without context-switch? Todd <Todd@invalid.invalid> - 2014-05-23 14:20 -0700

#2384 — Realtime clock accessible without context-switch?

Is there a way to access (say on Intel platforms) the realtime clock 
without using a special device driver, but simply with non-synchronized 
memory access?

[toc] | [next] | [standalone]

#2386

Charles T. Smith wrote:
> Is there a way to access (say on Intel platforms) the realtime clock
> without using a special device driver, but simply with non-synchronized
> memory access?

On IBM-PC compatible machines, the RTC lives in the good ol' ISA I/O
space, which cannot be memory-mapped.

When doing ISA I/O accesses, the switch to kernel mode is _not_ the
bottleneck.  If you want to avoid it anyway, use iopl and inb/outb.


Regards,
Clemens

[toc] | [prev] | [next] | [standalone]

#2388

On Tue, 20 May 2014 21:56:48 +0200, Clemens Ladisch wrote:

> Charles T. Smith wrote:
>> Is there a way to access (say on Intel platforms) the realtime clock
>> without using a special device driver, but simply with non-synchronized
>> memory access?
> 
> On IBM-PC compatible machines, the RTC lives in the good ol' ISA I/O
> space, which cannot be memory-mapped.
> 
> When doing ISA I/O accesses, the switch to kernel mode is _not_ the
> bottleneck.  If you want to avoid it anyway, use iopl and inb/outb.
> 
> 
> Regards,
> Clemens


Still these days?  But aren't there other clocks around?  Newer 
processors have various debug registers, I think.  Might there not be 
timers or something among them?

But thank you for reminding me about the i/o space.  It might be an 
option.

Your statement that the "switch to kernel mode is *not* the bottleneck" 
is intriguing.  Can you give a hint or a URL about what you mean?

cts

[toc] | [prev] | [next] | [standalone]

#2389

Am 21.05.2014 09:29, schrieb Charles T. Smith:

> Still these days?  But aren't there other clocks around?  Newer
> processors have various debug registers, I think.  Might there not be
> timers or something among them?
>
> But thank you for reminding me about the i/o space.  It might be an
> option.

The high-performance timers of (not any more so-)recent intel compatible 
CPUs might be a better alternative. A little bit of inline assembly 
helps to access them.

[toc] | [prev] | [next] | [standalone]

#2391

["Followup-To:" header set to comp.os.linux.misc.]
On 2014-05-21, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:
> On Tue, 20 May 2014 21:56:48 +0200, Clemens Ladisch wrote:
>
>> Charles T. Smith wrote:
>>> Is there a way to access (say on Intel platforms) the realtime clock
>>> without using a special device driver, but simply with non-synchronized
>>> memory access?
>> 
>> On IBM-PC compatible machines, the RTC lives in the good ol' ISA I/O
>> space, which cannot be memory-mapped.
>> 
>> When doing ISA I/O accesses, the switch to kernel mode is _not_ the
>> bottleneck.  If you want to avoid it anyway, use iopl and inb/outb.
>> 
>> 
>> Regards,
>> Clemens
>
>
> Still these days?  But aren't there other clocks around?  Newer 
> processors have various debug registers, I think.  Might there not be 
> timers or something among them?

Certainly. There is the system clock. The RTC is used ONLY to set up the
system clock at boot. It is not used thereafter. Also the rtc only gives
1 second granularity. Ie, you cannot read the time from it to better
than 1 sec. The system clock has 1nanosec granularity (well of course
that does not mean that the clock actually has 1 ns accuracy-- it is
more like 1microsec or worse.)
So again, what do you want to do? Tell us that rather than asking us how
to impliment your bad solutions. 


>
> But thank you for reminding me about the i/o space.  It might be an 
> option.
>
> Your statement that the "switch to kernel mode is *not* the bottleneck" 
> is intriguing.  Can you give a hint or a URL about what you mean?
>
> cts

[toc] | [prev] | [next] | [standalone]

#2392

Charles T. Smith wrote:
> On Tue, 20 May 2014 21:56:48 +0200, Clemens Ladisch wrote:
>> Charles T. Smith wrote:
>>> Is there a way to access (say on Intel platforms) the realtime clock
>>> without using a special device driver, but simply with non-synchronized
>>> memory access?
>>
>> On IBM-PC compatible machines, the RTC lives in the good ol' ISA I/O
>> space, which cannot be memory-mapped.
>>
>> When doing ISA I/O accesses, the switch to kernel mode is _not_ the
>> bottleneck.  If you want to avoid it anyway, use iopl and inb/outb.
>
> Still these days?

If it didn't use I/O space, it wouldn't be compatible.

> But aren't there other clocks around?

Lots, but none of those store the _real_ time.

I'd suggest the High Precision Event Timer; see the example program below.

> Newer processors have various debug registers, I think.

Try rdtsc.

Or just forget about all that hardware-dependent hackery and use
clock_gettime().

> Your statement that the "switch to kernel mode is *not* the bottleneck"
> is intriguing.  Can you give a hint or a URL about what you mean?

An I/O access (about one microsecond) is much slower than the SYSCALL
instruction; and with the RTC, you'd need to read several registers.


Regards,
Clemens


--8<---------------------------------------------------------------->8--
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main(void)
{
	int fd = open("/dev/hpet", O_RDONLY);
	if (fd == -1) {
		perror("/dev/hpet");
		return 1;
	}
	const volatile unsigned int *ptr = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
	if (ptr == MAP_FAILED) {
		perror("mmap");
		return 1;
	}
	printf("frequency: %.5f MHz\n", 1e9 / ptr[1]);
	for (;;) {
		printf("\rcounter: %08x", ptr[60]);
		fflush(stdout);
		usleep(123456);
	}
}

[toc] | [prev] | [next] | [standalone]

#2394

Clemens Ladisch <clemens@ladisch.de> writes:
> Charles T. Smith wrote:

>> Your statement that the "switch to kernel mode is *not* the bottleneck"
>> is intriguing.  Can you give a hint or a URL about what you mean?
>
> An I/O access (about one microsecond) is much slower than the SYSCALL
> instruction; and with the RTC, you'd need to read several registers.

As it happens, fetching the current time doesn’t involve a syscall
anyway (on amd64).

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#2395

On Wed, 21 May 2014 23:35:22 +0100, Richard Kettlewell wrote:

> Clemens Ladisch <clemens@ladisch.de> writes:
>> Charles T. Smith wrote:
> 
>>> Your statement that the "switch to kernel mode is *not* the
>>> bottleneck" is intriguing.  Can you give a hint or a URL about what
>>> you mean?
>>
>> An I/O access (about one microsecond) is much slower than the SYSCALL
>> instruction; and with the RTC, you'd need to read several registers.
> 
> As it happens, fetching the current time doesn’t involve a syscall
> anyway (on amd64).


And I'm reasonably sure that doing a task switch on linux has much more 
involved in it than just the trap instruction itself.

[toc] | [prev] | [next] | [standalone]

#2397

Charles T. Smith wrote:
> On Wed, 21 May 2014 23:35:22 +0100, Richard Kettlewell wrote:
>> Clemens Ladisch <clemens@ladisch.de> writes:
>>> An I/O access (about one microsecond) is much slower than the SYSCALL
>>> instruction; and with the RTC, you'd need to read several registers.
>>
>> As it happens, fetching the current time doesn’t involve a syscall
>> anyway (on amd64).

Yeah; the kernel reads the realtime clock once when booting, and then
tries to avoid touching it ever again by using another clock to track
the current time.

> And I'm reasonably sure that doing a task switch on linux has much more
> involved in it than just the trap instruction itself.

On AMD64, a system call does not involve a trap; it's just a jump to
a predefined address that also switches the privilege level so that
the kernel code is allowed to access all memory pages.  A task switch
has to save and restore all registers, and to switch page tables if
the new task is in another process.


Regards,
Clemens

[toc] | [prev] | [next] | [standalone]

#2398

Clemens Ladisch <clemens@ladisch.de> writes:
> Charles T. Smith wrote:
>> On Wed, 21 May 2014 23:35:22 +0100, Richard Kettlewell wrote:
>>> Clemens Ladisch <clemens@ladisch.de> writes:
>>>> An I/O access (about one microsecond) is much slower than the SYSCALL
>>>> instruction; and with the RTC, you'd need to read several registers.
>>>
>>> As it happens, fetching the current time doesn’t involve a syscall
>>> anyway (on amd64).
>
> Yeah; the kernel reads the realtime clock once when booting, and then
> tries to avoid touching it ever again by using another clock to track
> the current time.

That’s a separate issue, and not what I mean.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#2399

On 2014-05-22, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> Clemens Ladisch <clemens@ladisch.de> writes:
>> Charles T. Smith wrote:
>>> On Wed, 21 May 2014 23:35:22 +0100, Richard Kettlewell wrote:
>>>> Clemens Ladisch <clemens@ladisch.de> writes:
>>>>> An I/O access (about one microsecond) is much slower than the SYSCALL
>>>>> instruction; and with the RTC, you'd need to read several registers.
>>>>
>>>> As it happens, fetching the current time doesn???t involve a syscall
>>>> anyway (on amd64).
>>
>> Yeah; the kernel reads the realtime clock once when booting, and then
>> tries to avoid touching it ever again by using another clock to track
>> the current time.
>
> That???s a separate issue, and not what I mean.

So why not say what you mean. Obviously your were misinterpreted which
suggests you were not clear. 

>

[toc] | [prev] | [next] | [standalone]

#2408

On 05/21/2014 07:32 PM, Clemens Ladisch wrote:

> #include<stdio.h>
> #include<fcntl.h>
> #include<unistd.h>
> #include<sys/mman.h>
>
> int main(void)
> {
> 	int fd = open("/dev/hpet", O_RDONLY);
> 	if (fd == -1) {
> 		perror("/dev/hpet");
> 		return 1;
> 	}
> 	const volatile unsigned int *ptr = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
> 	if (ptr == MAP_FAILED) {
> 		perror("mmap");
> 		return 1;
> 	}
> 	printf("frequency: %.5f MHz\n", 1e9 / ptr[1]);
> 	for (;;) {
> 		printf("\rcounter: %08x", ptr[60]);
> 		fflush(stdout);
> 		usleep(123456);
> 	}
> }

as user:
/dev/hpet: Permission denied

as root:
/dev/hpet: Device or resource busy

Jan Pieter.

[toc] | [prev] | [next] | [standalone]

#2402

On 05/20/2014 03:29 AM, Charles T. Smith wrote:
> Is there a way to access (say on Intel platforms) the realtime clock
> without using a special device driver, but simply with non-synchronized
> memory access?
>

 From the command line or inside a program?



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the riddle wrapped in an enigma wrapped
in a couple slices of baloney
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.hardware

csiph-web