Peter Jeremy wrote:
> On 2009-Aug-25 19:50:04 +0100, "Dr. David Kirkby" <[email protected]>
> wrote:
>> Note I've implement the load averages in two ways:
>>
>> * System as a whole
>> * Processors available to Sage, which might have a very different load
>> average if its running in a Solaris Zone or as a virtual machine with
>> only a limited number of processors available.
>
> The latter may not make sense on other operating systems. Should they
> return the system-wide load average or an error?
>
First, as I said in a previous post, I do not believe the load average
is terribly useful on multi-core, multi-threaded processors.
I'd suggest if on other systems they can not be determined, then just
assume the same.
>> My intension is to add something to Sage so this sort of information can
>> be found on Solaris. I'll leave it to others to get the data from linux,
>> OS X etc.
>
> I think there needs to be more co-ordination than this. The data
> collected needs to be both useful and available on other platforms.
> There may be cases where providing exactly the same data is
> comparatively expensive on other systems and an alternate definition
> would provide similar information far more cheaply.
Yes, I tend to agree. I starting trying to fix the 'top' issue and
thought I'd extend it, but perhaps I should just limit the fix to that
for now.
I don't believe computing the number of cpus should be expensive, as it
only needs to be done once.
>> The following 3 commands apply to one single process of a given PID:
>> ./a.out image_size PID (Image size in MB)
>> ./a.out resident_size PID (Resident size in MB)
>
> These either need to be a floating point value or reported in
> smaller units. Typical granularity is pages.
I did this initially as that is what 'top' is outputting. I think kB
might be best, as page size is not consistans on operating system. By
making it kB, it should allow the largest amount of memory allocatable
on a 32-bit system (4 GB) to be output as a 'long' which someone (forgot
who) said was best.
>> ./a.out process_priority PID (Priority)
>
> Is this expected to be comparable across different OSs? If so,
> there needs to be agreement on what different numbers mean.
I see no reason to have comparable data on different operating systems.
I don't believe that is possible.
>> ./a.out processor_speed (CPU speed in MHz, rounded to
>> the nearest integer)
>
> Most OSs support CPU throttling (I think even Solaris does on some of
> the CoolThreads boxes) and current x86 family CPUs allow diffent cores
> to throttle to different speeds. Does this represent the top speed of
> the fastest CPU, average top speed, current CPU speed or what? Note
> that averaging current speed is probably not a good idea because a
> single-threaded sage may be saturating one core (hence it is running
> at full speed) whilst the other core is idling (and therefore
> throttled to minimum).
I believe this system call will return the fastest the CPU is capable
of. I'm told however that on SPARC, using processors with different
speeds is supported on some platforms.
It is also impossible to directly equate processor speeds across
different CPUs. It would however give some idea to someone answering a
support request to know if the person is running very old or cutting
edge hardware.
>> ./a.out physical_processors (Number of physical CPUs)
>
> Total CPUs or CPUs available to the Sage (via processor set or
> similar). What is the definition of a CPU - put another way, how
> many CPUs in a T5120? 1, 8 or 64?
Total physical processors (1 in the T5120) on Solaris at least can be
determined, though I don't know a system call to do it. The number of
threads (64 in your example) can also be found. I'm not sure about the
number of cores.
I believe in some cases, returning -1 to indicate 'unknown' will be
appropriate.
>> ./a.out platform (SUNW,Sun-Blade-1500,
>> SUNW,Sun-Fire-T200 etc)
>
> What do you expect a PC to report here? The SMBIOS System Product?
I believe that will be up to the person writing the code for linux or
whatever. I don't believe you can expect 100% consitancy across all
platforms. Even in the case of Sun equipment, this is not totally
unambiguous. The Sun Blade 2000 is reported as a Sun Blade 1000. The
motherboards are the same. It does at least give some idea if the
machine is a really old one, or quite new model.
>> ./a.out solaris_version (The version of Solaris (7, 8,
>> 9, 10, 11 etc)
>
> For portability, this should be something neutral like 'os_version'.
> Note that Sun still prefer reporting it as SunOS 5.x. Is this intended
> to be a float (eg 5.10 or 2.6) or a string (eg '2.6.24-19-server')?
I'm aware of that. Though perhaps more useful is 'Solaris 10 update 4'.
That needs a grep of /etc/release to get that data.
> Once you start looking beyond Sun Solaris on SPARC, there are a variety
> of other details that become relevant as well:
> - Vendor (eg the SMBIOS System Maker on a PC)
> - OS Name ("Linux", "Solaris", "FreeBSD" etc)
> - Architecture ("SPARC", "x86", "x86_64", etc)
> - Anything else I've forgotten.
> - CPU type (cpuinfo model name on Linux)
I believe one should just do the best on OS one can do. It's probably
going to be impossible to get all the same data on all operating systems.
I would suggest one way to approach this would be for everyone to list
the 20 things they think would be most important.
Mine might start
1) Sage version (20 points)
2) Operating system (19 points)
3) Operating system version (18 points).
...
etc etc
19) colour of the case (2 points)
20) Number of scratches on the case (1 point).
Rank them, and try to implement the most important ones.
One that might be useful on Solaris, and could be implemented, is the
number of spare processor slots, so a suggestion to add a CPU could be
made, when one knows there can be extra CPUs added.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
