Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: LTSP + Mosix


  • Subject: Re: lug-bg: LTSP + Mosix
  • From: George Danchev <danchev@xxxxxxxxx>
  • Date: Sun, 19 Sep 2004 19:42:20 +0300

On Sunday 19 September 2004 18:17, Peter Georgiev wrote:
> On Sun, 19 Sep 2004 16:21:23 +0300 (EEST); linux@xxxxxxxxxxxxxxxx wrote:
> > Та основната идея ми беше да се разтовари Linux Treminal Server-a.
> > Незнам обаче дали това е идеята на OpenMosix-a ... или май идеята му е
> > едно голямо и трудоемко приложение да се изтъркаля по-бързо (ако е
> > така поне ще пробвам Doom3 ... Нали е последно време това стана като
> > базов тест за бързодействие ... Последното него приемайте сериозно
> > !!!)
>
> Това като вариант ще сработи според мене. Определено ще разтовариш
> сървъра. Това е и идеята на Open Mosix, когато има много процеси, които
> товарят CPU и RАМ, те да се разпределят между nod-овете за да се
> балансира товара.

това е идеята на всички клъстерни технологии ;-)

> Doom най-вероятно ще е един процес "ядящ" огромни ресурси и файда няма
> да има от клъстъра. Виж, ако компресираш аудио файлове до мр3 или ogg,
> да речем с grip и lame, теоретично едновременната компресия на N файла
> на клъстър от 5 равностойни машини трябва да завърши 5 пъти по-бързо
> отколкото на 1.
>
> Ако говорим за по-бързото изпълнение на един голям и ресурсопоглъщащ
> процес, варианта е Beowulf клъстър, при който всички машини работят
> паралелно като един супер-компютър. Като тези, които ползват напоследък
> компаниите за специални ефекти в киното. Или много университети за
> научни изчискения, изискващи огромем ресурс. В случая обаче са
> необходими специално написани за паралелна работа приложения.

не става ясно в двата случая как голям и ресурсопоглъщащ процес ще бъде 
обработен (ако въобще бъде обработен от двете технологии)... а то зависи , и 
е според зависи от много неща, виж по-долу.

> Има доста такива проекти и информация из мрежата, Mosix, OpenMosix,
> Beowulf, OSCAR...

Ще си позволя малко да детаилизирам, че малко си размил границите на 
технологиите ;-) Значи имаме коренна разлика между:

1) Beowulf почива на т.н. Message Passing технологии (това са такива message 
passing API-та като PVM и MPI, ask google). Много стара идея още от времето 
когато са предложени тредовете ;-) . Голям недостатък е, че изисква да се 
изпълняват само специално написани за целта приложения, отчитайки 
конкурентните и паралелните части на цялата задача. It all depends upon the 
application. Освен това нарастването на нодовете налява скалируемостта или 
грубо казано 5x5 = 20 Такива приложения се пишат изключително трудно и бавно, 
само в някои изследователски лабове и тези приложения няма да са от полза на 
много други хора, за това и PVM и MPI не е толкова разпространено като 
технология.

2) Mosix, OpenMosix е по технологията Single System Image - не се изискват 
специално написани приложения като горните с оглед на конкурентност и 
паралелизъм реализирани в самите тях... Всичкото приложения дето ползват 
posix тредове може да се мигрира. Алгоритми в ядрото (а не в приложението, за 
разлика от горе) решават  кога нода е натоварен и има ли  по-разтоварен нод и 
кои таскове позволяват миграция и кои от тях да се мигрират и кои от тях да 
бъдат първи. Това не значи обаче, че всичкото таскове може да се мигрира 
между нодовете, има работи които искат да са си на същия нод на който са 
стартирани като бази данни, приложения с Java green threads, ала бала shared 
memory... В този случай те просто си вървят на нода на който са стартирани. 
Тука 5x5 е винаги е 25, демек и при 3 и при 3000 нода скалируемостта и 
овърхеда върху цялостната работа на клъстера си остават същите. Използват се 
много хитри алгоритми за откриване на най-разтоварен нод, цена на миграцията 
и т.н.

и двете изискват тривиален хардуер... разликата е в софта ;-)

-- 
pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.