[PATCH] HPET: do not use 64-bit reads

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[PATCH] HPET: do not use 64-bit reads

Clemens Ladisch-2
This patch changes the HPET code to use only 32-bit reads. On 32-bit
architectures, 64-bit reads are not atomic, and even on 64-bit
architectures, the timer is not guaranteed to have 64 bits.

Index: jack/config/os/gnu-linux/time.c
===================================================================
--- jack/config/os/gnu-linux/time.c 2006-05-26 04:45:14.000000000 +0200
+++ jack/config/os/gnu-linux/time.c 2006-10-22 17:24:39.000000000 +0200
@@ -64,13 +64,10 @@ jack_hpet_init ()
 static jack_time_t
 jack_get_microseconds_from_hpet (void)
 {
- unsigned long long hpet_counter;
- long double hpet_time;
+ unsigned int hpet_counter;
 
- hpet_counter = *((unsigned long long *) (hpet_ptr + HPET_COUNTER));
- hpet_time = (long double) hpet_counter * (long double) hpet_period *
- (long double) 1e-9;
- return ((jack_time_t) (hpet_time + 0.5));
+ hpet_counter = * (unsigned int *) (hpet_ptr + HPET_COUNTER);
+ return (uint64_t) hpet_counter * (uint64_t) hpet_period / 1000000000u;
 }
 
 #else

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Jussi Laako
Clemens Ladisch wrote:
> This patch changes the HPET code to use only 32-bit reads. On 32-bit
> architectures, 64-bit reads are not atomic, and even on 64-bit
> architectures, the timer is not guaranteed to have 64 bits.

I merged this a bit different way. 32-bit reads are now used on 32-bit
platforms. Full 64-bit main counter is used on x86-64. According to ICH7
documentation, there shouldn't be any problem on 64-bit access on 64-bit
processors.

Haven't seen any problems on my ICH5 with the old code either. I could
even write short inline asm to ensure 64-bit read with "movq".


        - Jussi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
On Wed, 2006-10-25 at 21:23 +0300, Jussi Laako wrote:

> Clemens Ladisch wrote:
> > This patch changes the HPET code to use only 32-bit reads. On 32-bit
> > architectures, 64-bit reads are not atomic, and even on 64-bit
> > architectures, the timer is not guaranteed to have 64 bits.
>
> I merged this a bit different way. 32-bit reads are now used on 32-bit
> platforms. Full 64-bit main counter is used on x86-64. According to ICH7
> documentation, there shouldn't be any problem on 64-bit access on 64-bit
> processors.
>
> Haven't seen any problems on my ICH5 with the old code either. I could
> even write short inline asm to ensure 64-bit read with "movq".

How do you know that this works for chipsets other than ICH7?

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Jussi Laako
Lee Revell wrote:
> How do you know that this works for chipsets other than ICH7?

According to the original HPET spec it should work on all 64-bit systems
unless the HPET is for some reason connected over 32-bit PCI or similar.

On Intel case it's behind DMI bus, on AMD systems it's behind
HyperTransport. nVidia and few others are not providing datasheets in
open, so it's really hard to say (do they even have HPET?). However, if
someone finds problem with it, I'll expect to see bug report with some
details. It's not fatal in any case:

1) HPET device is not the default clock source, you have to explicitly
specify.
2) HPET device use is not the recommended way, recommended way is the
default way.
3) If there's a problem, user can use system clock as a clock source anyway.
4) User can tell kernel to use HPET as clocksource and then jack to use
kernel provided clock.
5) 32-bit timer wraps around every now and then for sure. Problem on
64-bit platform is less likely, IMO.

There's no guarantee of problem on 64-bit platform (unless someone can
demonstrate it really happening). But there's guarantee of the 32-bit
counter wrapping around. Will all the jack things survive when the clock
wraps... That's an interesting question...

One option is of course to drop direct HPET support altogether, then
there's nothing to argue... ;) (is anybody actually using it?)


BR,

        - Jussi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
On Wed, 2006-10-25 at 23:20 +0300, Jussi Laako wrote:
> One option is of course to drop direct HPET support altogether, then
> there's nothing to argue... ;) (is anybody actually using it?)
>

This is what I would do.  As hardware gets flakier and more broken in
this area, lots of work has recently gone into solving this exact
problem: making the kernel select the fastest possible correct
timesource.  I think it's crazy to duplicate that functionality in JACK.

IMHO the 2 JACK clock sources should be clock_gettime(CLOCK_MONOTONIC)
and the legacy behavior, for old/slow systems.  If the kernel doesn't
pick the best timesource or is too slow compared to direct hardware
access then the kernel should be fixed.

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Paul Davis
On Wed, 2006-10-25 at 17:01 -0400, Lee Revell wrote:
> On Wed, 2006-10-25 at 23:20 +0300, Jussi Laako wrote:
> > One option is of course to drop direct HPET support altogether, then
> > there's nothing to argue... ;) (is anybody actually using it?)
> >
>
> This is what I would do.  As hardware gets flakier and more broken in
> this area, lots of work has recently gone into solving this exact
> problem: making the kernel select the fastest possible correct
> timesource.  I think it's crazy to duplicate that functionality in JACK.

i would agree except for one thing. the reason we originally used the
cycle counter was that it is accessible from user space without a system
call. it is ridiculous in this era that h/w would/could not provide a
monotonic, high resolution clock that can be *read* without requiring
priviledged access. making a system call to get a value from a 64 bit
register is silly. gettimeofday() represents an API to quite a
sophisticated bit of functionality, functionality that JACK doesn't need
(at least not for this purpose).

> IMHO the 2 JACK clock sources should be clock_gettime(CLOCK_MONOTONIC)
> and the legacy behavior, for old/slow systems.

there are 4 options, not 3, at present. cycle counter, gettimeofday,
clock_gettime and HPET.

--p



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
On Wed, 2006-10-25 at 17:17 -0400, Paul Davis wrote:
> i would agree except for one thing. the reason we originally used the
> cycle counter was that it is accessible from user space without a system
> call. it is ridiculous in this era that h/w would/could not provide a
> monotonic, high resolution clock that can be *read* without requiring
> priviledged access. making a system call to get a value from a 64 bit
> register is silly. gettimeofday() represents an API to quite a
> sophisticated bit of functionality, functionality that JACK doesn't need
> (at least not for this purpose).

One would hope so, but hardware seems to be getting worse not better in
this area.  Apparently the TSC is almost as broken in Intel's multicore
x86-64 implementation as in AMD's.

I really wonder how the other OS does it.  Do they just make everyone
eat the cost of a system call?

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Jussi Laako
In reply to this post by Lee Revell
Lee Revell wrote:
> This is what I would do.  As hardware gets flakier and more broken in
> this area, lots of work has recently gone into solving this exact
> problem: making the kernel select the fastest possible correct
> timesource.  I think it's crazy to duplicate that functionality in JACK.

Point of it's sole existence is to provide something lighter weight than
system call. I would also refer to earlier discussion about performance
of syscalls and TSC. HPET device usage is somewhere in the middle
grounds. And it's duplication, yes.


        - Jussi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
On Thu, 2006-10-26 at 00:29 +0300, Jussi Laako wrote:
> Lee Revell wrote:
> > This is what I would do.  As hardware gets flakier and more broken in
> > this area, lots of work has recently gone into solving this exact
> > problem: making the kernel select the fastest possible correct
> > timesource.  I think it's crazy to duplicate that functionality in JACK.
>
> Point of it's sole existence is to provide something lighter weight than
> system call.

Isn't read() from /dev/hpet a syscall?

>  I would also refer to earlier discussion about performance
> of syscalls and TSC. HPET device usage is somewhere in the middle
> grounds. And it's duplication, yes.
>

I think it might be worth revisiting as it's become clear that hardware
with an unusable TSC will become the norm and as the kernel evolves.
For example getttimeofday() is supposed to be much cheaper on x86-64
than i386.  I haven't tested it lately...

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

D. Michael McIntyre-3
In reply to this post by Lee Revell
On Wednesday 25 October 2006 5:25 pm, Lee Revell wrote:

> I really wonder how the other OS does it.  Do they just make everyone
> eat the cost of a system call?

Probably.  I know diddly squat about any of this stuff, but this comment
reminded me of some message I got from an audio app on Windows once.  
Something to the effect of "You're running me on Windows, and I don't like it
here.  I can't work under these conditions.  You are about to experience
terrible latency, and there's nothing I can do about it."  I think that was
Pro Tools, back around the turn of the century.

--
D. Michael McIntyre

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/
See my new music stand unfolding at http://users.adelphia.net/~silvan/

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
On Wed, 2006-10-25 at 18:48 -0400, D. Michael McIntyre wrote:

> On Wednesday 25 October 2006 5:25 pm, Lee Revell wrote:
>
> > I really wonder how the other OS does it.  Do they just make everyone
> > eat the cost of a system call?
>
> Probably.  I know diddly squat about any of this stuff, but this comment
> reminded me of some message I got from an audio app on Windows once.  
> Something to the effect of "You're running me on Windows, and I don't like it
> here.  I can't work under these conditions.  You are about to experience
> terrible latency, and there's nothing I can do about it."  I think that was
> Pro Tools, back around the turn of the century.
>

Actually the problem is a hardware not a software one.  Newer chipsets
simply do not provide a hardware timesource that's as fast and cheap as
old ones.

For example, here's the output of a simple benchmark that compares rdtsc
to gettimeofday on my 600Mhz C3:

$ ./tsctest
rdtsc: 10000 calls in 1040 usecs
gettimeofday: 10000 calls in 12087 usecs

Here's the output on my "AMD Athlon(tm)64 X2 Dual Core Processor 3800+":

$ ./tsctest
rdtsc: 10000 calls in 112 usecs
gettimeofday: 10000 calls in 23249 usecs

rdtsc is 10x faster on the new machine, but useless for timekeeping
because the TSC stops in low power CPU states and isn't synced between
cores.  So gettimeofday() ends up 2x SLOWER, on a 10x faster machine,
because it has to fall back to the ACPI PM timer.

I was wondering what Windows developers do about this situation.  It
seems implausible that they would just eat such a massive slowdown
because the hardware guys decided to break the TSC.

Gotta love progress...

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Clemens Ladisch-2
In reply to this post by Lee Revell
Lee Revell wrote:
> On Thu, 2006-10-26 at 00:29 +0300, Jussi Laako wrote:
> > Point of it's sole existence is to provide something lighter weight than
> > system call.
>
> Isn't read() from /dev/hpet a syscall?

It's a mmap() once at initialization followed by standard memory reads.
(Well, it isn't standard memory.)

> I really wonder how the other OS does it.  Do they just make everyone
> eat the cost of a system call?

Some information is available to user space (to functions in
kernel32.dll) through a mmap()ed page.  I don't know if the timer is
part of that information.

Both OS X for Intel and the Vista ready logo require HPET.


HTH
Clemens

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Clemens Ladisch-2
In reply to this post by Jussi Laako
Jussi Laako wrote:
> Lee Revell wrote:
> > How do you know that this works for chipsets other than ICH7?
>
> According to the original HPET spec it should work on all 64-bit systems
> unless the HPET is for some reason connected over 32-bit PCI or similar.

The atomicity of the read shouldn't be a problem on 64-bit system.

However, there is no guarantee that the timer actually has 64 bits, the
specification only recommends it.  My x86-64 system has a 32-bit timer
(AMD64 with a VT8237 southbridge).

> But there's guarantee of the 32-bit counter wrapping around.

Every five minutes (all current systems use a 14.31818 MHz timer).

> Will all the jack things survive when the clock wraps... That's an
> interesting question...

Other clocks can wrap, too.


Regards,
Clemens

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Florian Paul Schmidt-2
In reply to this post by Lee Revell
On Thursday 26 October 2006 01:55, Lee Revell wrote:

> Actually the problem is a hardware not a software one.  Newer chipsets
> simply do not provide a hardware timesource that's as fast and cheap as
> old ones.
>
> For example, here's the output of a simple benchmark that compares rdtsc
> to gettimeofday on my 600Mhz C3:
>
> $ ./tsctest
> rdtsc: 10000 calls in 1040 usecs
> gettimeofday: 10000 calls in 12087 usecs
>
> Here's the output on my "AMD Athlon(tm)64 X2 Dual Core Processor 3800+":
>
> $ ./tsctest
> rdtsc: 10000 calls in 112 usecs
> gettimeofday: 10000 calls in 23249 usecs
>
> rdtsc is 10x faster on the new machine, but useless for timekeeping
> because the TSC stops in low power CPU states and isn't synced between
> cores.  So gettimeofday() ends up 2x SLOWER, on a 10x faster machine,
> because it has to fall back to the ACPI PM timer.
>
> I was wondering what Windows developers do about this situation.  It
> seems implausible that they would just eat such a massive slowdown
> because the hardware guys decided to break the TSC.

I am wondering whether it matters. How often are these functions called in
i.e. jackd? Is gettimeofday actually becoming a bottleneck? If you run jackd
with a periodsize of 32 frames, it needs to call gettimeofday roughly once
every 32/48000 seconds (assuming 48khz samplerate). That's a little more than
once per ms. On your amd box gettimeofday takes about 2 usecs (if naively
dividing 23249/10000 and rounding a bit), so that's ca. 0.3% of the available
time per process cycle. Doesn't sound too bad.

I can imagine that it could be a problem though in situations different from
jackd..

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Jack O'Quin
On 10/26/06, Florian Schmidt <[hidden email]> wrote:

> I am wondering whether it matters. How often are these functions called in
> i.e. jackd? Is gettimeofday actually becoming a bottleneck? If you run jackd
> with a periodsize of 32 frames, it needs to call gettimeofday roughly once
> every 32/48000 seconds (assuming 48khz samplerate). That's a little more than
> once per ms. On your amd box gettimeofday takes about 2 usecs (if naively
> dividing 23249/10000 and rounding a bit), so that's ca. 0.3% of the available
> time per process cycle. Doesn't sound too bad.
>
> I can imagine that it could be a problem though in situations different from
> jackd..

Without going back and studying the code, I believe gettimeofday()
must be called much more than once per cycle.  As a rough guess,
it will be called about twice per client (which includes the backend in
jackd).
--
 joq

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
In reply to this post by Clemens Ladisch-2
On Thu, 2006-10-26 at 08:51 +0200, Clemens Ladisch wrote:
> > I really wonder how the other OS does it.  Do they just make everyone
> > eat the cost of a system call?
>
> Some information is available to user space (to functions in
> kernel32.dll) through a mmap()ed page.  I don't know if the timer is
> part of that information.
>

Sounds very similar to how x86-64 does it with vsyscall...

> Both OS X for Intel and the Vista ready logo require HPET.

Hmm.  Is it really possible that my Athlon X2 3800 board has no HPET?
The kernel certainly doesn't find it...

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Dmitry Baikov
In reply to this post by Lee Revell
On 10/26/06, Lee Revell <[hidden email]> wrote:
> I really wonder how the other OS does it.  Do they just make everyone
> eat the cost of a system call?

The preferred method of timing in other OS was
QueryPerformanceCounter()/QueryPerformanceFrequency() calls. Functions
should hide the implementation details, but on AMD64x2 they definetely
use RDTSC. It's a real problem here at my day job. I'm yet to find a
reasonable solution. For now we just force the program to run on one
CPU.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Lee Revell
On Thu, 2006-10-26 at 20:46 +0400, Dmitry Baikov wrote:

> On 10/26/06, Lee Revell <[hidden email]> wrote:
> > I really wonder how the other OS does it.  Do they just make everyone
> > eat the cost of a system call?
>
> The preferred method of timing in other OS was
> QueryPerformanceCounter()/QueryPerformanceFrequency() calls. Functions
> should hide the implementation details, but on AMD64x2 they definetely
> use RDTSC. It's a real problem here at my day job. I'm yet to find a
> reasonable solution. For now we just force the program to run on one
> CPU.
>

Interesting.  So your're saying that Windows does not work around this
hardware bug?

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Dmitry Baikov
On 10/26/06, Lee Revell <[hidden email]> wrote:
> Interesting.  So your're saying that Windows does not work around this
> hardware bug?

WinXP SP2 patched to death does not.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPET: do not use 64-bit reads

Dmitry Baikov
> WinXP SP2 patched to death does not.

Oops, my bad. Seems we should update our "CPU drivers".

http://support.microsoft.com/?scid=kb%3Ben-us%3B909944&x=15&y=10

I'll try it tommorrow and report.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
123