FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-22-2012, 02:55 PM
David Given
 
Default nacl and CPU frequency.

On 22/09/12 15:28, peter green wrote:
[...]
> In order to build successfully nacl needs to determine the CPU frequency
> (the CPU frequency determined at build time is not used in the final
> binaries afaict but if it's not determined then the build will fail as
> it will consider the implementation broken and if it can't find any
> non-broken implementations it won't build).
[...]
> Do you known how important it is to have an accurate CPU frequency
> determination for nacl. e.g. if true CPU frequency can't be determined
> would it be ok to use bogomips instead?

I can't imagine why it would want to know this --- particularly as most
modern architectures don't *have* a single clock frequency (and some may
not have clocks at all).

I wonder if what the developers were actually thinking of when they
think of a clock frequency is actually the value of CLOCKS_PER_SEC,
which is the factor needed to turn a clock_t into a real wall-clock time
--- because on Posix that's defined to be 1000000, regardless of the
actual implementation details...

--
┌─── dg*cowlark.com ───── http://www.cowlark.com ─────

│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
 
Old 09-22-2012, 03:08 PM
Colin Tuckley
 
Default nacl and CPU frequency.

On 22/09/12 15:28, peter green wrote:
> I'm trying to get nacl built on more architectures in debian, in
> particular I want to see it build on arm*.
>
> In order to build successfully nacl needs to determine the CPU frequency

I think you need to analyse what it's doing with the CPU frequency,
because on most modern hardware the frequency changes due to power
saving and other stuff.

Colin

--
Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0x1B3045CE

All E-mail gladly received. Offensive reply ASAP.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 505DD46C.5010401@tuckley.org">http://lists.debian.org/505DD46C.5010401@tuckley.org
 
Old 09-22-2012, 03:17 PM
Russell Coker
 
Default nacl and CPU frequency.

On Sun, 23 Sep 2012, peter green <plugwash@p10link.net> wrote:
> In order to build successfully nacl needs to determine the CPU frequency
> (the CPU frequency determined at build time is not used in the final
> binaries afaict but if it's not determined then the build will fail as
> it will consider the implementation broken and if it can't find any
> non-broken implementations it won't build).

If the build process is trying to discover information that it then discards
then why not just patch it to not do so?

Surely you as the DD can determine which architectures aren't "broken" and
configure the package to only build on them.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209230117.50039.russell@coker.com.au">http://lists.debian.org/201209230117.50039.russell@coker.com.au
 
Old 09-22-2012, 04:20 PM
peter green
 
Default nacl and CPU frequency.

Russell Coker wrote:

On Sun, 23 Sep 2012, peter green <plugwash@p10link.net> wrote:

In order to build successfully nacl needs to determine the CPU frequency
(the CPU frequency determined at build time is not used in the final
binaries afaict but if it's not determined then the build will fail as
it will consider the implementation broken and if it can't find any
non-broken implementations it won't build).



If the build process is trying to discover information that it then discards
then why not just patch it to not do so?
It's not the build process itself doing the determination, it's the code
being built and
tested (as I said the build process tries various implementations until
it finds one that

works),

So sure I could patch the build process to force it to build the generic
implementation
without testing it but if it then doesn't work for many users I won't
really have gained

much.

>Surely you as the DD can determine which architectures aren't "broken"
Not being able to read the clockspeed doesn't seem to be determined by
debian
architecture, it seems to be kernel related. e.g. on my beagleboard XM I
can see the

clocksepeed in /sys/ but on my imx53 I can't. On my amd64 laptop I can't see
the speed in /sys but I can see it in /proc/cpuinfo.





--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 505DE535.9040206@p10link.net">http://lists.debian.org/505DE535.9040206@p10link.net
 
Old 09-22-2012, 04:29 PM
peter green
 
Default nacl and CPU frequency.

On 22/09/12 15:28, peter green wrote:
> I'm trying to get nacl built on more architectures in debian, in
> particular I want to see it build on arm*.
>
> In order to build successfully nacl needs to determine the CPU frequency


I think you need to analyse what it's doing with the CPU frequency,
because on most modern hardware the frequency changes due to power
saving and other stuff.


It would appear that nacl is designed to have a concept of measuring elapsed
time in CPU cycles. But when measurements in true CPU cycles (obtained
using inline assembler) are not available it falls back to using time values
from the OS and multiplying them by the number of CPU cycles per second.
This appears to be used for measuring performance of various things.


I therefore conclude that if it's not returning elapsed times in true CPU
cycles it probablly doesn't matter much if the supposed CPU speed and the
real CPU speed are not exactly the same.

As such unless someone objects I plan to patch the code to fallback to
using bogomips as a "psuedo CPU speed" if true CPU speed cannot be
determined.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 505DE779.9010500@p10link.net">http://lists.debian.org/505DE779.9010500@p10link.net
 
Old 09-22-2012, 06:11 PM
Konstantin Khomoutov
 
Default nacl and CPU frequency.

On Sat, Sep 22, 2012 at 05:20:05PM +0100, peter green wrote:

> >>In order to build successfully nacl needs to determine the CPU
> >>frequency (the CPU frequency determined at build time is not
> >>used in the final binaries afaict but if it's not determined
> >>then the build will fail as it will consider the implementation
> >>broken and if it can't find any non-broken implementations it
> >>won't build).
> >
> >If the build process is trying to discover information that it
> >then discards then why not just patch it to not do so?
> It's not the build process itself doing the determination, it's the
> code being built and
> tested (as I said the build process tries various implementations
> until it finds one that
> works),
Did you ask the nacl upstream about why they needed that code to be
built? I think referring them to your initial message in this thread
might make them think about patching/removing that code.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120922181102.GJ32381@localhost.localdomain
 
Old 09-22-2012, 11:42 PM
Ben Hutchings
 
Default nacl and CPU frequency.

On Sat, 2012-09-22 at 17:20 +0100, peter green wrote:
> Russell Coker wrote:
> > On Sun, 23 Sep 2012, peter green <plugwash@p10link.net> wrote:
> >
> >> In order to build successfully nacl needs to determine the CPU frequency
> >> (the CPU frequency determined at build time is not used in the final
> >> binaries afaict but if it's not determined then the build will fail as
> >> it will consider the implementation broken and if it can't find any
> >> non-broken implementations it won't build).
> >>
> >
> > If the build process is trying to discover information that it then discards
> > then why not just patch it to not do so?
> It's not the build process itself doing the determination, it's the code
> being built and
> tested (as I said the build process tries various implementations until
> it finds one that
> works),
[...]

So the build process is trying to determine which method will work?
Then what if it settles on some method that is available on the build
machine's kernel, but not the target distribution's kernel? I think you
need to either (1) make it defer this to run-time or (2) force the
decision at build-time, and be conservative.

(In general, userland packages in testing/unstable should not depend on
kernel features that aren't in the official kernel packages in stable,
as this can cause breakage during upgrades.)

Ben.

--
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.
 
Old 09-23-2012, 09:19 AM
Bastian Blank
 
Default nacl and CPU frequency.

On Sat, Sep 22, 2012 at 03:28:50PM +0100, peter green wrote:
> In order to build successfully nacl needs to determine the CPU
> frequency (the CPU frequency determined at build time is not used in
> the final binaries afaict but if it's not determined then the build
> will fail as it will consider the implementation broken and if it
> can't find any non-broken implementations it won't build).

What does it use this information for? With current CPUs, this value is
neither fixed over time, nor really meaningful.

If you want to have accurate timing, use the monotonic clock.

Bastian

--
Respect is a rational process
-- McCoy, "The Galileo Seven", stardate 2822.3


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120923091948.GA13799@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20120923091948.GA13799@wavehammer.waldi.eu.org
 
Old 09-23-2012, 10:24 AM
"Thomas Preud'homme"
 
Default nacl and CPU frequency.

Le dimanche 23 septembre 2012 01:42:01, Ben Hutchings a crit :
>
> So the build process is trying to determine which method will work?
> Then what if it settles on some method that is available on the build
> machine's kernel, but not the target distribution's kernel? I think you
> need to either (1) make it defer this to run-time or (2) force the
> decision at build-time, and be conservative.

If I understood correctly he is ready to patch the build system to use a
specific method for this precise reason but is asking which method would work
on all Debian system.
 
Old 09-23-2012, 10:39 AM
Tollef Fog Heen
 
Default nacl and CPU frequency.

]] "Thomas Preud'homme"

> If I understood correctly he is ready to patch the build system to use a
> specific method for this precise reason but is asking which method would work
> on all Debian system.

Detect it at runtime and choose the appropriate method then?

(Not that CPU frequency is constant at runtime either, mind.)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pq5dqaz8.fsf@xoog.err.no">http://lists.debian.org/87pq5dqaz8.fsf@xoog.err.no
 

Thread Tools




All times are GMT. The time now is 10:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org