[GE users] bogomips as a selection criteria

udowaechter udo.waechter at uni-osnabrueck.de
Fri Jun 5 16:12:27 BST 2009


    [ The following text is in the "UTF-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]

Hello,
we are doing something similar, but use the pystones (pretty trivial)  
benchmark from python:

python -c \"from test import pystone; print  
':'.join(map(str,pystone.pystones(1000000)))

We store this value in a file and update it from time to time....  
Additionally a loadsensor reads the state file and updates a complex.

Additionally we have a load_sensor which uses this number and some  
other values from sge to compute the seqno:

#!/bin/bash
# $Id$
# formula: corefactor*num_proc+(pystones*(1-(np_load_avg/loadcutoff)))
# if loadaverage of the exechost is equal or above loadcutoff value  
the result will be set to 0
# after the  'sort' call we have s.th. like:
#   hl:np_load_avg=0.000000
#         hl:num_proc=1.000000
#   hl:pystones=44091.000000

#. /opt/sge/default/common/settings.sh

SGE_ROOT=/opt/sge; export SGE_ROOT

ARCH=`$SGE_ROOT/util/arch`
SGE_CELL=default; export SGE_CELL
SGE_CLUSTER_NAME=ikw01; export SGE_CLUSTER_NAME
SGE_QMASTER_PORT=6444; export SGE_QMASTER_PORT
SGE_EXECD_PORT=6445; export SGE_EXECD_PORT

corefactor=10000000
loadcutoff=1.25

VAL=$(${SGE_ROOT}/bin/${ARCH}/qhost -h `hostname` -F  
num_proc,pystones,np_load_avg |grep -e num_proc -e pystones -e  
np_load_avg |sed -e 's/Host Resource(s)://g' | awk '/hl:/ { print $1  
$2 $3 }' |sort | cut -f 2 -d "=" | tr "\n" " " | awk -v corefactor= 
$corefactor -v loadcutoff=$loadcutoff '{ seq_no = $1 >= loadcutoff ?  
0 : int(corefactor*$2+($3*(1-($1/loadcutoff)))); print seq_no }')
echo "seq_no:$VAL"

#EOF-seqno-loadsensor

The idea here is, that hosts with a higher cpu number get a higher  
sequence number
formula: corefactor*num_proc+(pystones*(1-(np_load_avg/loadcutoff)))

In our environment, host with a lot of cpus (>4) are usually compute  
servers, thus those should be preferred when doing computations. Even  
if there would be one reaaaaaaaalllly fast machine with less cpus, a  
server with many cpus would have a higher seqno

The RHS of the addition in the seqno formula is the pstones value  
(could be bogomips there, but I am not sure if bogomips is the value  
for a single core!) time the np_load_average (which is normalised over  
the number of cores) divided by the loadcutoff)

If the np_load_avg of the host is higher than loadcutoff the seqno is  
set to 0. With rising load, the seqno of a host decreases, but remains  
in the same magnitude...

This formula gives a pretty dynamic load distribution in our cluster.
Hosts that share the same magnitute of seqno (lets say 8-core recent  
intels have seqnos > 8000000) are preferred. Additionally, within this  
group of hosts, the sequence numbers differ in smaller values  
depending on their overall load.

Our pystones value is updated from time to time (I think its every 2  
days or so), and it depends on that host's load at update time whether  
it is the maximum possible value or not.

The scheduler is set to use -seq_no queue_sort_method

Hope this helps, it does with us
bye,
udo.


On 05.06.2009, at 12:51, olesen wrote:

>> Second step is to tell SGE to prefer hosts with the higher bogomips
>> index inside the same queue, a kind of "soft request" on bogomips.
>>
>> And here is where I'm stuck.
>
> You could change the global queue_sort_method to seqno and then  
> assign a sequence number that decreases with increasing bogomips.
>
> To make things less confusing, it'd be advisable to classify the  
> various bogompis ranges into host groups.  You only need to do this  
> once (and thus can drop the bogomips from the reporting).
>
> For example, you might have the following queue:
>
>  name       foo
>  hostlist   @hosts1 @hosts2 @hosts3 @hosts4
>  seq_no     100,[@hosts2=110],[@hosts3=120],[@hosts4=130]
>
>
> Your script just needs to categorize the host into one of the  
> @hostsX host_groups based on the bogomips range and use either qconf  
> -mhgrp or qconf -Mhgrp with the modified values.
>
>
> /mark
>
> This e-mail message and any attachments may contain
> legally privileged, confidential or proprietary Information,
> or information otherwise protected by law of EMCON
> Technologies, its affiliates, or third parties. This notice
> serves as marking of its "Confidential" status as defined
> in any confidentiality agreements concerning the sender
> and recipient. If you are not the intended recipient(s),
> or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby
> notified that any dissemination, distribution or copying
> of this e-mail message is strictly prohibited.
> If you have received this message in error, please
> immediately notify the sender and delete this e-mail
> message from your computer.
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=200980
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net 
> ].
>

-- 
:: udo waechter - root at zoide.net :: N 52?16'30.5" E 8?3'10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=201002

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

    [ Part 2, Application/PKCS7-SIGNATURE (Name: "smime.p7s") 2.2 KB. ]
    [ Unable to print this part. ]



More information about the gridengine-users mailing list