On Thu, Feb 11, 2010 at 09:23:02PM +0100, Petr Salinger wrote:
> The 32-bit overflow during calculation is responsible
> for remaining problem.
That overflow is in the kernel itself then? I'm using bc to do these
calculations and it seems ok with large numbers. procps itself uses
long longs. May e
On Thu, 11 Feb 2010, Cyril Brulebois wrote:
> Petr Salinger (11/02/2010):
> > How much cores (CPUs) does field.debian.org have ?
> > My guess is 4.
>
> Correct:
> ,
> | $ ssh field.debian.org grep ^processor /proc/cpuinfo
> | processor : 0
> | processor : 1
> | processor : 2
> | proces
Petr Salinger (11/02/2010):
> How much cores (CPUs) does field.debian.org have ?
> My guess is 4.
Correct:
,
| $ ssh field.debian.org grep ^processor /proc/cpuinfo
| processor : 0
| processor : 1
| processor : 2
| processor : 3
`
Mraw,
KiBi.
signature.asc
Description: D
But looking at poor field.debian.org
188847.15 673325.21
cpu 119994 4473784 3539322 2746621
The second number first line is idle seconds, the 4th number is idle
ticks. See linprocfs_dostat() and linprocfs_douptime().
If its relationship is 100 then one is 100 times the other.
It's not, it's abo
On linux, we just use ELF notes and this problem goes away. If there
is something equivalent in freeBSD then I could use that as well.
I wouldn't know, I'm just the poor DSA who gets to fight these machines. :)
Maybe the debian-bsd list would know.
The ELF notes are the property of ELF form
On Thu, 11 Feb 2010, Craig Small wrote:
> On Thu, Feb 11, 2010 at 01:48:07AM +0100, Peter Palfrader wrote:
> > | wea...@field:~$ cat /proc/uptime ; grep 'cpu ' /proc/stat ; cat
> > /proc/uptime
> > | 188847.15 673325.21
> > | cpu 119994 4473784 3539322 2746621
> > | 188847.16 673325.21
> > | wea.
6 matches
Mail list logo
