time updates to clockfix branch

Jussi Laako wrote:
> As I don't have HPET capable hardware at home,
hopefully someone with
> suitable hardware will test the code... 

Seems to work.

After I added CLOCK_MONOTONIC to <time.h>.  My system
(Slackware 10.0)
doesn't have it; this should probably be checked by
configure.
(The clock_gettime() call then fails, of course.)

<asm/hpet.h> doesn't exist, either.  This isn't needed
when the HPET_*
symbols are defined in client.c anyway.

And I guess it wasn't intended that ARCH_X86 isn't defined
without
--enable-dynsimd.

The period length register has 32 bits, not 64.

The counter register, however, does have 64 bits (you are
reading it as
unsigned int).  This bug happens to mask the next bug:
conversion from
and to floating point do not work with unsigned integers,
they always
treat integers as signed.  If the most significant bit it
set, the
floating point number will be negative, and the conversion
to
jack_time_t will set most of the upper bits.

However, on a 32-bit machine, reading the 64-bit counter
will use two 32
bit reads.  This will fail if the lower 32 bits of the
counter roll over
between the reads.  It's better to use only the native word
size
(unsigned long) when reading the counter.

hpet_ptr should probably be volatile, just to be sure.


HTH
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Clemens Ladisch wrote:

> > As I don't have HPET capable hardware at home,
hopefully someone with
> > suitable hardware will test the code... 
> 
> Seems to work.
> 
> After I added CLOCK_MONOTONIC to <time.h>.  My
system (Slackware 10.0)
> doesn't have it; this should probably be checked by
configure.
> (The clock_gettime() call then fails, of course.)

CLOCK_MONOTONIC should be defined in <bits/time.h>,
which should be
included by <time.h>.

-- 
Glynn Clements <glynngclements.plus.com>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Glynn Clements wrote:
> Clemens Ladisch wrote:
> > After I added CLOCK_MONOTONIC to <time.h>. 
My system (Slackware 10.0)
> > doesn't have it; this should probably be checked
by configure.
> 
> CLOCK_MONOTONIC should be defined in
<bits/time.h>, which should be
> included by <time.h>.

Yes, this is the exact place where the other CLOCK_ symbols
were
defined, and where I had to add CLOCK_MONOTONIC to get it to
compile.


Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Tue, 2006-01-31 at 08:54 +0100, Clemens Ladisch wrote:
> After I added CLOCK_MONOTONIC to <time.h>.  My
system (Slackware 10.0)
> doesn't have it; this should probably be checked by
configure.
> (The clock_gettime() call then fails, of course.)

Which version of glibc it has? Or is the "librt"
(or it's headers) in
some other non-installed package? I'll try to figure out how
to check
that in configure, as I'm not very expert in autotools.

> <asm/hpet.h> doesn't exist, either.  This isn't
needed when the HPET_*
> symbols are defined in client.c anyway.

That should be visible in /usr/include/asm through linkage
to /usr/src/linux/include/asm-i386.

> And I guess it wasn't intended that ARCH_X86 isn't
defined without
> --enable-dynsimd.

Yeah, I'll fix that part.

> The period length register has 32 bits, not 64.

Whoops, yes, that's a typo. I had the variable declared
correctly
static unsigned int hpet_period; /* period length in femto
secs */
but pointer typecast is incorrect.

> The counter register, however, does have 64 bits (you
are reading it as
> unsigned int).

Yeah, pointer typecasts are accidentally vice versa compared
to variable
types. I'll fix that...

> This bug happens to mask the next bug: conversion from
> and to floating point do not work with unsigned
integers, they always
> treat integers as signed.  If the most significant bit
it set, the
> floating point number will be negative, and the
conversion to
> jack_time_t will set most of the upper bits.

That's incorrect. If that happens then it's a compiler bug.
At least
doesn't happen with any of the compilers I have here (three
different
gcc versions and icc).

> However, on a 32-bit machine, reading the 64-bit
counter will use two 32
> bit reads.  This will fail if the lower 32 bits of the
counter roll over
> between the reads.  It's better to use only the native
word size
> (unsigned long) when reading the counter.

When compiled with proper arch it shouldn't happen. Of
course I could
inline it as "movq". In any case it takes pretty
long time for that
64-bit counter to wrap around, at least way more than in
case of TSC.


-- 
Jussi Laako <jussi.laakopp.inet.fi>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Jussi Laako wrote:
> On Tue, 2006-01-31 at 08:54 +0100, Clemens Ladisch
wrote:
> > After I added CLOCK_MONOTONIC to <time.h>. 
My system (Slackware 10.0)
> > doesn't have it; this should probably be checked
by configure.
> 
> Which version of glibc it has? Or is the
"librt" (or it's headers) in
> some other non-installed package?

Headers and libraries are from glibc-2.3.2 (2003-01-12).

> > <asm/hpet.h> doesn't exist, either.  This
isn't needed when the HPET_*
> > symbols are defined in client.c anyway.
> 
> That should be visible in /usr/include/asm through
linkage
> to /usr/src/linux/include/asm-i386.

/usr/include/asm contains the headers the C library was
compiled with.
Neither this directory nor /usr/src/linux has anything to do
with the
currently running kernel.  Linus' take on this is:
http://groups.
google.com/group/linux.kernel/browse_thread/thread/7e01e9697
20e28eb/4daa203ae30ff0bb

The HPET_* symbols are not ioctls or something that is part
of the user
space interface of Linux (they come from an external
specification), so
there is no need to take from a Linux header.

> > This bug happens to mask the next bug: conversion
from
> > and to floating point do not work with unsigned
integers, they always
> > treat integers as signed.  If the most significant
bit it set, the
> > floating point number will be negative, and the
conversion to
> > jack_time_t will set most of the upper bits.
> 
> That's incorrect. If that happens then it's a compiler
bug.

Yes, you're right.  I didn't actually test this.  Gcc
inserts code that
checks for the sign and makes it come out right.

> > However, on a 32-bit machine, reading the 64-bit
counter will use two 32
> > bit reads.  This will fail if the lower 32 bits of
the counter roll over
> > between the reads.  It's better to use only the
native word size
> > (unsigned long) when reading the counter.
> 
> When compiled with proper arch it shouldn't happen. Of
course I could
> inline it as "movq".

There are cases where the hardware splits a 64-bit read into
two 32-bit
reads.  Please see section 2.4.7 of the HPET spec.
(Intel doesn't tell which hardware cannot do 64 bits, but
the same
warning is in the ICH5 datasheet.)

> In any case it takes pretty long time for that 64-bit
counter to wrap
> around, at least way more than in case of TSC.

With the usual 14.31818 MHz timer, more than 40000 years. 
But I was
speaking about the lower 32 bits which wrap around every
five minutes.


Regards,
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Wed, 2006-02-01 at 18:23 +0100, Clemens Ladisch wrote:
> Headers and libraries are from glibc-2.3.2
(2003-01-12).

Hmmh, it's present on this glibc-2.3.3-118 (SuSE 9.2).

> /usr/include/asm contains the headers the C library was
compiled with.
> Neither this directory nor /usr/src/linux has anything
to do with the
> currently running kernel.

It's specific subset of those kernel headers. It has to be,
or then it's
rewrite of those risking consistency of ioctl/sig/errno
numbers. In 2.2
or 2.4 era it used to be direct symbolic link to kernel
sources and is
still able to function that way.

> The HPET_* symbols are not ioctls or something that is
part of the user
> space interface of Linux (they come from an external
specification), so
> there is no need to take from a Linux header.

There should be single header defining the offsets for all
this kind of
hardware memory maps. Anyway, that header is not used
anymore.

In any case, in my system there's asm/hpet.h provided by
glibc-devel
package.

/home/visitor> rpm -q --file /usr/include/asm/hpet.h
glibc-devel-2.3.3-118

> With the usual 14.31818 MHz timer, more than 40000
years.  But I was
> speaking about the lower 32 bits which wrap around
every five minutes.

Let's see how common this problem will be. It's smaller
annoyance than
dealing with the constant wraparound.


-- 
Jussi Laako <jussi.laakopp.inet.fi>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Wed, 2006-02-01 at 18:23 +0100, Clemens Ladisch wrote:
> With the usual 14.31818 MHz timer, more than 40000
years.  But I was
> speaking about the lower 32 bits which wrap around
every five minutes.

That 32-bit thing... This is the things time will fix pretty
soon
anyway. When most users have hardware where HPET works
without hacks,
those are most probably 64-bit capable Intel or AMD
machines. Most
probably in AMD architectures the HyperTransport to
southbridge won't
split it to 32-bit ops...


-- 
Jussi Laako <jussi.laakopp.inet.fi>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el