01.12.2012 Views

Architecture of Computing Systems (Lecture Notes in Computer ...

Architecture of Computing Systems (Lecture Notes in Computer ...

Architecture of Computing Systems (Lecture Notes in Computer ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

78 M. Bonn and H. Schmeck<br />

Uptime-based Distribution<br />

As the name <strong>of</strong> this strategy suggests, this selection algorithm ma<strong>in</strong>ly considers the<br />

uptime values <strong>of</strong> the nodes. In practice, a typical node is available for a certa<strong>in</strong> time<br />

period, but then it gets shut down with <strong>in</strong>creas<strong>in</strong>g probability. This proceeds every<br />

day <strong>in</strong> the same (or similar) manner. The values ���� and ����, which are determ<strong>in</strong>ed<br />

for each node � help to predict how long an ask<strong>in</strong>g node will still be available.<br />

From these values, a further value, ��������, is calculated. The closer the<br />

current uptime gets to the average uptime, the shorter are the jobs which have to be<br />

selected. If the node’s uptime exceeds its average uptime, the scheduler little by<br />

little selects longer-runn<strong>in</strong>g jobs, depend<strong>in</strong>g on the node’s total reliability. To account<br />

for the possible different CPU performances among the nodes, the relative<br />

benchmark <strong>in</strong>dex is f<strong>in</strong>ally <strong>in</strong>tegrated to scale the average runtime. In other words,<br />

�������� estimates how long the average runtime ���� <strong>of</strong> a job type � maximally<br />

should be, to get a job <strong>of</strong> this type successfully done by the considered node<br />

before it becomes unavailable.<br />

|���� −���<br />

��������� = �<br />

�|, ��������� with �� � �−1,1�<br />

��� �1� � |���� −����|, ��������� �������� = ��������� � � �<br />

To estimate, which job type has to be selected, the average type runtimes are sorted<br />

(hav<strong>in</strong>g ���� � ����,� � �) and the correspond<strong>in</strong>g mean values are calculated:<br />

����� = �<br />

� ����� �������� F<strong>in</strong>ally, the ultimate run length target value ���� is calculated:<br />

���� = ����� � ����−2,2� where<br />

����� = � ���� , |�������� − ��� � | � |�������� − ���� � |<br />

���� � , |�������� − ��� � | � |�������� − ���� � | with<br />

|�������� − ���� | = m<strong>in</strong><br />

��� |�������� − ����| and<br />

|�������� − ����� | = m<strong>in</strong>|��������<br />

− �����| �<br />

In other words, from the total set <strong>of</strong> average job type runtimes and their pair-wise<br />

mean values the s<strong>in</strong>gle value ����� is selected which is closest to the previous calculated<br />

ideal value ��������. Then the <strong>in</strong>dividual job � � is selected and delivered<br />

which m<strong>in</strong>imizes ����� − ��� ������. For clarity, the whole strategy is expla<strong>in</strong>ed by an<br />

example now. We assume jobs <strong>of</strong> four types/users �� �,…,�� � be<strong>in</strong>g <strong>in</strong> the data base.<br />

We also assume the follow<strong>in</strong>g average runtimes (<strong>in</strong> m<strong>in</strong>utes):<br />

��� � = 10, ��� � = 60, ��� � = 180, ��� � = 200<br />

Furthermore, the follow<strong>in</strong>g monitor<strong>in</strong>g values <strong>of</strong> an ask<strong>in</strong>g node are assumed to be<br />

estimated so far:<br />

��� = 240, ��� = 220, � = 2, � = 0

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!