Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923091948.ga13...@wavehammer.waldi.eu.org
Re: 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. signature.asc Description: This is a digitally signed message part.
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq5dqaz8@xoog.err.no
Re: nacl and CPU frequency.
On Sun, 23 Sep 2012, Thomas Preud'homme robo...@celest.fr wrote: 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. How can build-time recognition of CPU features be useful in any way for Debian? We can usually be certain that most systems which run the code will have different CPUs to the system used for building. If hard-coding the number to some reasonable value isn't good enough then code needs to be written to detect it at run-time. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209232052.27861.russ...@coker.com.au
Re: nacl and CPU frequency.
On Sat, Sep 22, 2012 at 05:29:45PM +0100, peter green wrote: 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. procps has been struggling with this for years, though ita mainly around the CPU ticks versus real seconds. If you are really bored, have a look at some old procps bugs where this sort of thing has broken. We've narrowed it down to a small handful of checks. The real value is probably unknown for some devices so we just set it to a fixed value. The point is, trying to guess this sort of stuff will probably give you the wrong number so a pseduo CPU speed is probably as bad as anything else you can come up with, so find something simple. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923225625.ga17...@enc.com.au
nacl and CPU frequency.
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 (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). Currently the generic implementations (there are also some CPU specific implementations) do this by looking at various locations in /proc and /sys, specifically (in order) /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq /sys/devices/system/cpu/cpu0/clock_tick /proc/cpuinfo If it fails to find the info in /sys or /proc it then falls back to trying lsattr and psrinfo but neither of theese seem to exist in current debian. Unfortunately it seems /sys/devices/cpu/cpu0 doesn't exist on all systems (even if /sys is mounted) and while /proc/cpuinfo always seems to exist it doesn't always have CPU frequency information. Now for my questions (the first is directed at developers in general, the second is directed at Sergiusz but if others know the answer I wouldn't mind them asking it) Is there a portable way of determining CPU frequency in debian? 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? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505dcb22.70...@p10link.net
Re: 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 100, regardless of the
actual implementation details...
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
signature.asc
Description: OpenPGP digital signature
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505dd46c.5010...@tuckley.org
Re: nacl and CPU frequency.
On Sun, 23 Sep 2012, peter green plugw...@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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209230117.50039.russ...@coker.com.au
Re: nacl and CPU frequency.
Russell Coker wrote: On Sun, 23 Sep 2012, peter green plugw...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505de535.9040...@p10link.net
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505de779.9010...@p10link.net
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120922181102.GJ32381@localhost.localdomain
Re: 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 plugw...@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. signature.asc Description: This is a digitally signed message part
