CC BY
28
УДK 004.002
DOI: 10.15587/2313-8416.2015.44380
ВПЛИВ ВИСОКОПРОДУКТИВНИХ СОКЕТ1В НА 1НТЕНСИВН1СТЬ ОБРОБКИ ДАНИХ
© В. М. Мельник, Н. В. Багнюк, K. В. Мельник
В po6omi вивчаються продуктивтсть i обмеження coKemie за архтектурою вiрmуальнoгo ттерфейсу (САВ1), яК використовують компонентну основу для надання nidmpuMKU в момент виконання додаттв з iнmeнcивнoю обробкою даних. Результати показують, що при реорган1зацИ звичайних кoмпoнeнmiв до-сягаються значнi покращення прoдукmивнocmi роботи додатюв, а рo6oчi характеристики САВ1 дозво-ляють ефективтший розподш даних у вузлах
Ключовi слова: сокети за архтектурою вiрmуальнoгo ттерфейсу, високопродуктивна мережа, сокети, iнmeнcивна обробка даних, кластери ПК
Performance and limitations on the Virtual Interface Architecture Sockets (VIAS) are studied, using a component framework designed to provide runtime support for data intensive applications. The experimental results show that by reorganizing certain components, the significant performance applications improvements are achieving and performance characteristics of VIAS allow a more efficient data partitioning on the nodes Keywords: Virtual Interface Architecture Sockets, high-performance network, sockets, data intensive computing, PC clusters
1. Вступ
Немала шльшсть дослщжень, що супрово-джують обробку даних з максимальною потужшс-тю, акцентують увагу на розвитку метод1в створен-ня складних обчислювальних додатшв у р1зних га-лузях: наущ, техшщ, медицин та шших. Под1бш програми, як правило, працюють в пакетному ре-жим1 1 можуть генерувати дуже велиш обсяги даних. Передов1 сенсорш технологи також дозволяють до-сягати високо! роздшьно! здатносп для багатовимь рних блошв даних. В результат! зростае штерес до розробки додатшв, яш в штерактивному режим1 до-слщжують, узагальнюють 1 анал1зують велиш об'еми наукових даних [1]. У данш робот розгля-даються под1бн1 додатки, тобто додатки для штен-сивно! обробки даних.
2. Постановка проблеми
Будучи побудованими !з стандартних апарат-них засоб1в, кластери ПК стають все рентабельшши-ми 1 життездатшшими альтернативами супер-комп'ютер1в основного потоку для широкого спектру додатшв, у тому числ1 для додатшв, що оперують !нтенсивними даними. Складтсть у шдтримщ таких ресурсоемних додатк1в на платформах полягае в тому, що велик обсяги даних повинш ефективно пере-мщатися м1ж процесорною пам'яттю. Для досягнен-ня високо! продуктивносл операци перемщення та обробки даних також повинш бути ефективно скоор-динованими засобами динам1чно! тдтримки. Поряд з вимогами плщного функцюнування, так1 додатки вимагають високого р1вня гарантш в галуз1 продуктивности пристосованосп до гетерогенних середо-вищ 1 наявносп ресурсних змш.
Базов! структури на основ! компонента [2-4] можуть забезпечити гнучке та ефективне середовище для додатшв з штенсивною обробкою даних на роз-
подшених платформах. У таких базових структурах додаток е розроблений з набору взаемодшчих про-грамних компоненпв, розмщення яких поряд з ресурсами обчислення вщграе важливють в ступеш гну-чкосп та оптим1зацй' продуктивносп програм.
Паралельна обробка даних може бути досягну-та шляхом виконання дек1лькох копш компонента в окол кластера збер^ання i вузл1в обробки [2]. Кон-веер - це ще один можливий механiзм для покращення продуктивности У багатьох додатках з штенсивною обробкою даних набiр (об'ем) даних може роз-подшятися на визначенi користувачем субблоки даних, обробка яких може проходити конвеерно.
Якщо при оргашзаци роботи обробка i зв'язок можуть перекриватися, то покращення продуктивносп також набувае залежносп ввд бло-ковостi обчислень i розмiру повiдомлень даних (тобто субблошв даних). Невеликi блоки даних призводять до покращення балансу навантаження i конвееризаци, а багато повiдомлень генеруються блоками малих розмiрiв. Однак блоки бшьшого розмiру зменшують кiлькiсть поввдомлень i дося-гають вищо! пропускно! здатностi каналу зв'язку, а значить, ймовiрно, створюють дизбаланс наванта-ження i зменшення конвеерностi.
З появою сучасних мiжкомпонентних висо-кошвидкiсних комушкацш, таких як Giganet [2], Myrinet [6], Gigabit Ethernet [7], АНВ [8] i Quadrics Network [9], "критична д^нка" у оргашзаци зв'язку змютилася до програмного забезпечення обмiну повщомленнями. Саме критична дiлянка досить оргашзовано i швидко дослiджувалася нау-ковцями, спричиняючи створення протоколiв на рiвнi користувача з малим часом затримки та висо-кою пропускною здатшстю [10-12]. Поряд з цими дослщженнями, кiлька галузей взяли на себе штативу стандартизацii протоколiв високо! продукти-
вност1 на piBHi користувача, таких як apximeKmypa вiртуального iнтерфейсу (АВ1) [10, 13].
Кшька додаткiв були розроблеш на 0CH0Bi базових протоколiв ядра, таких як TCP/UDP, що використовують сокетний iнтерфейс [14, 15]. Для !х пiдтримки на базi високопродуктивних протоко-лiв рiвня користувача без будь -яких змш в самому додатку, дослвдники пiдiйшли до реалiзащ! ряду пiдxодiв. Цi шдходи включають в себе сокетнi сполучення на рiвнi користувача в напрямку до протоколiв високо! продуктивностi. Додатки, на-писанi з використанням сокетних з'еднань базових протоколiв ядра, часто розробляються з урахуван-ням продуктивносл зв'язку в TCP/IP. З шшого боку, засоби високо! продуктивной мають рiзнi характеристики в порiвняннi з сокетними зв'язками на базi ядра. Це становить основу критично! дшян-ки продуктивностi, яку здатш забезпечити високо-продуктивнi засоби. Тим не менш, змiнивши деяш компоненти для додатка, такi як розмiр субблоку, що утворюють единий блок даних, дозволить дода-ткам взяти перевагу над робочими характеристиками високопродуктивних засобiв, роблячи !х бшьш вагомими i адаптованими.
В даному випадку описуеться ефективнiсть i обмеження тако! реалiзацi!, як САВ1, на промiжкаx продуктивно! роботи i гнучкосп, якi вона дозволяе, в контексп базового компонентного пiдxоду, пок-ликаного забезпечити вчасну шдтримку виконання для додатшв з iнтенсивною обробкою даних, такого як мехашзм роздшення загального блоку даних (БРД) [2]. Слщ отримати вiдповiдi на таш питання: чи може дозволити високопродуктивний сокет реа-лiзувати масштабний штерактивний додаток з га-рантiями продуктивносп до кiнцевого споживача; чи може високопродуктивний сокет покращити адаптованiсть додатшв з iнтенсивною обробкою даних в гетерогенних середовищах?
Отриманi експериментальнi результати по-казують, що шляхом реоргашзацп окремих компо-нентiв для додатшв можна отримати значнi покра-щення в продуктивностi, що призводить до висо-комасштабованостi додаткiв з гаранпями виконання. Це також дозволяе дрiбно-структурований баланс навантаження, роблячи таким чином додатки бiльш адаптованими до гетерогенних середовищ i наявностi ресурсних змш.
3. Огляд додатшв з штенсивною обробкою даних
3i зростанням обчислювально! потужностi i емносп дисков продовжуе реально зростати потен-цiал для створення додаткiв з метою збертання багатогiгабайтниx i багатотерабайтних блошв даних. Глибоке розумшня досягаеться за рахунок застосування поточного аналiзу та кодiв вiзуалiза-цп на збереженi данi. Наприклад, штерактивна вь зуалiзацiя опираеться на можлившть отримати вну-трiшнi уявлення, дивлячись на складну систему, в той час як аналiз даних так i вiзуальне дослiдження
великих блошв даних вiдiграють найважливiшу роль у багатьох галузях наукових дослiджень. Мо-ва йде про додатки, яш в iнтерактивному режимi роблять запити та аналiзують великi блоки наукових даних, тобто додатки з штенсивною обробкою даних. Прикладом додатка з штенсивною обробкою даних е оцифровування даних з мшроскопу.
Ключовою проблемою е шдтримка програм-ного забезпечення, яке необхвдне для збереження, пошуку, i опрацювання оцифрованих слайдiв, для забезпечення iнтерактивностi протягом робочих iнтервалiв в ходi стандартно! поведшки фiзичного мiкроскопу [16, 17]. Основна складшсть пов'язана з обробкою великих обсяпв даних для цифрового зображення, якi можуть варiюватися ввд декiлькох сотень мегабайт до декшькох гiгабайт. На базовому рiвнi системне програмне забезпечення повинно найбiльш точно ввдображати поточну роботу фiзи-чного мшроскопу, включаючи постiйне ввдслшко-вування змш та машпуляцп, пов'язанi зi збшьшен-ням. Обробка запитiв клiентiв вимагае проектуван-ня даних з високою роздшьною здатнiстю на ввд-повiдну область резолюцi! з вадповадним розподь лом пiкселiв для ввдображення однiе! роздiльно! точки. Розглянемо сервер вiзуалiзацi! для цифрово! мiкроскопi!. Клiент до цього сервера може генеру-вати рiзнi типи запитiв. Найбшьш поширеними з них е повне оновлення запипв, за допомогою яких подаеться повшстю нове зображення, а також час-ткове оновлення запиту, за допомогою якого зображення розглядаеться як злегка змщене або збь льшене. Сервер повинен бути призначений для обробки обох подiбних тишв запитiв.
Обробка даних в додатках, як подають запит i манiпулюють науковим набором даних, часто може бути представлена у виглядi ациктчного грубого потоку у виглядi визначених блоков вiд одного або декшькох джерел даних (наприклад, один або бшьше наборiв даних, яш розподiленi по системах збереження) до процесорних вузлiв клiента. Першi данi, що представляють iнтерес для такого запиту, отри-муються з вадповвдних наборiв даних. Потiм даш об-робляються за допомогою послвдовносп операцiй на вузлах обробки. Наприклад, в додатку цифрово! мш-роскопп данi, що представляють iнтерес, обробля-ються за допомогою операцiй об'еднання субблоков, операцiй перегляду [2, 18] ^ нарештi, обробленi данi посилаються клiенту.
Данi, що утворюють частини зображення, збертаються у виглядi блошв або фрагментiв з точки зору шдексацп, необхiдно! для отримання щ-лого блоку, навiть у випадку, якщо для цього пот-рiбна тiльки частина блоку. На рис. 1 показане повне зображення, що складаеться з декшькох блошв. Як видно з рисунка, при частковому запил оновлення (прямокутник з пунктирними лiнiями на кресленш) може знадобитися тiльки частина блоку. Тому розмiр i протяжшсть блоку впливае на кшь-шсть даних, необхiдних для отримання та переда-вання вищеописаних запитiв.
Рис. 1. Представления розмгтки розбиття повного блоку даних на субблоки. Частковий запит, обведений прямокутником з пунктирними лшями, який вимагае лише частину блоку
4. Завдання, пов'язаш з пiдтримкою проду-ктивносп виконання для додаткiв з штенсивною обробкою даних
Для додатшв з штенсивною обробкою даних, продуктившсть може бути покращена в дешлькох напрямках. По-перше, набори даних можна декласте-ризувати у всш систем! для удосконалення паралель зму вводу-виводу при ïx отриманш, як1 i представля-ють штерес запиту. При вiдповiдностi шдбору декла-стеризацiï запит потрапить до максимально можливо1 кiлькостi дисков. По-друге, потужиiсть обробки даних системою може бути використана ефективно, якщо додаток спроектований для використання пара-лелiзму при 1'х обробцi. 1ншим фактором, який може покращити продуктивнiсть, особливо в штерактивному дослщженш наборiв даних, е конвеерне виконання 1'х обробки. Загальний час виконання обробки додатком може бути зменшений при умов!, якщо данi роздiлити на блоки (шматки) i реал1зувати конвеерну 1'х обробку. У багатьох додатках, конвеерна обробка також забезпечуе меxанiзм, що поступово створюе сукупний продукт вих1дних даних. 1ншими словами, користувачевi не потрiбно чекати завершення обробки запиту, так як частковi результати будуть генеру-ватися поступово. Хоча це не може фактично змен-шити загальний час обробки, проте така особливiсть дуже ефективна в iнтерактивниx установках, особливо якщо область защкавлення постшно змiщуеться.
Робочий розподiл i розмiр блокiв даних впли-вають на продуктившсть конвеерного виконання. Розмiр блошв повинен бути ретельно пщбраний з урахуванням пропускноï здатностi мереж! i часу затримки (час очiкування, необхщний для передачi повiдомлення, включаючи обробки за допомогою протокол!в на всьому пром!жку передачi, починаю-чи вщ вiдправника i до кiнцевиx одержувачiв). 3i збiльшенням розм!ру блоку шльшсть повщомлень, яка необxiдна для передачi одного i того ж об'ему даних - зменшуеться. У цьому випадку, пропускна здатнiсть як характеристика стае важлившою, шж час затримки. Однак, з! збiльшенням розм!ру блоку час обробки на кожен такий блок також збшьшуеть-ся. В результат!, система стае менш чутливою, тобто, частота окремих/послщовних оновлень зменшуеться. З шшо1 сторони, якщо розм!р блоку менший -збшьшуеться к1льк1сть повщомлень. В результат! час очшування може стати дом!нуючим фактором у загальнш ефективносп додатку. Кр!м того, невелик! фрагменти спричиняють покращення балансу нава
нтаження м!ж кошями компоненпв додатка, але затрати на зв'язок можуть компенсувати прирют продуктивность
Велик! блоки даних дозволяють застосовувати кращий час реакцiï системи для повного оновлення запиту, пов'язаний з покращенням пропускно1 здат-носп. Тим не менше, частковий запит на оновлення приведе до зб!льшення кшькосп даних i, як результат, затрат на них. З шшого боку, з малим розм!ром блоку, частковий запит на оновлення не отримувати-ме багато непотр!бних даних, але повний запит на оновлення буде зазнавати втрат через зниження про-пускноï здатност!
До того ж, забезпечуючи бшьш високу про-пускну здатшсть i знижуючи р!вень затримки, сокети високо1' продуктивносп мають шш! щкав! мож-ливосп, показан! на рис. 2, а, б. Рис. 2, a показуе, що вони збшьшують пропускну здатшсть при наба-гато меншому розм!р! повщомлення в пор!внянш з вим!ряними на базових kernel-сокетах, таких як TCP/IP. Наприклад, для досягнення пропускно1' зда-тносп, базовим kernel-сокетам потр!бен розм!р по-вщомлення U1 байт, в той час як високопродуктивш сокети вимагають меншого розм!ру повщомлення U2 байт. Використовуючи шформацш, подану на рис. 2, б зауважимо, що вони призводять до зниження часу затримки повщомлення, понижуючи його вщ L1 до L2 при сталому розм!р! повщомлення U1 в байтах. Також виявлено, що високопродуктив-m сокети при використанш розм!ру повщомлення U2 байт (рис. 2, а) надал! скорочують час затримки вщ L2 до L3 i, в результат!, спостершаеться шдви-щення продуктивность
Неоднорвдшсть виникае в дешлькох ситуащях. По-перше, апаратне середовище може складатися з машин з р!зно1' потужносп роботи i емносп пам'яп. По-друге, ресурси можуть розподалятися м1ж шшими додатками. В результат!, наявтсть ресурав, таких як CPU i пам'ять може динам!чно зм!нюватися. У таких випадках, додаток повинен бути структурно продума-ним i пристосованим до гетерогенно1' природи середо-вища при оргашзаци його роботи. Вш також повинен бути отгашзованим з точки зору використання сшль-них ресурав i адаптованим до змш 1'х наявносп та до-ступносп до них. Це вимагае ввд додатка застосування мехашзм!в адаптаци, щоб збалансовувати робоче на-вантаження м!ж вузлами обробки в залежносп вщ об-числювальних можливостей кожного з них. Для мож-ливого виршення цього питання здшснюеться плану-вання заздалепдь вихвдних даних i розрахунк1в м!ж вузлами обробки. Дан! можуть бути розбип на фрагменти так, щоб це могло дозволяти здшснювати i обробку даних i комушкацш в конвеернму режим!.
До того ж, призначення фрагментаци даних для вузл!в обробки можна зробити з урахуванням схеми попиту, так щоб швидш! вузли отримали бшь-ше даних для обробки. Якщо швидкодшчий вузол сповшьнюеться (наприклад, через ди шших додат-к1в), то мехашзм, що лежить в основ! балансування навантаження, повинен бути здатним швидко вияв-ляти зм!ну наявносп та доступносп до ресурав.
1 __———
/"2 ч _._.--- ---
/yS необх. пропускна здатисть
/А - внсокопродуктиви сокети
// ! 2 - кегпе1-сокети
U1 U2 розмф пов1домпення
а
1 - внсокопродуктиви сокети
2 - Ьете]-сокетн
LI
L2
розыф повщомлення Ü1 U2
б
Рис. 2. а - Досягнення задано! пропускно! здатносп пром1жними високопродуктивними сокетами для меншого розм1ру поввдомлення в пор1внянн1 з kernel-сокетами; б - можливють досягнення прямого
i непрямого покращення продуктивносп високопродуктивними сокетами, обумовлених характеристиками додатшв
5. 1нфраструктура програмного забезпечен-ня для надання оцшки
Пiд час розробки додатшв i пiдтримки !х робо-ти компонентно-базовi засоби [2-4] можуть забезпе-чити ефективне середовище для виршення проблем у високопродуктивних додатках. Компоненти можуть бути розмщеш на рiзних обчислювальних ресурсах, а завдання i паралельна обробка даних може досягати вдосконалення шляхом конвеерного виконання бага-тьох копiй цих компонентiв. Таким чином, в данш роботi використовуеться базова компонентна шфра-структура блокового розбиття даних (БРД) [2], приз-начена для шдтримки додатк1в з штенсивною оброб-кою даних в розподшених середовищах. Також використовуеться високоефективний штерфейс сокетiв САВ1, розроблений для додатшв, що використовують TCP/IP, з метою надати переваги в реалiзацi! можли-востей продуктивностi АВ1.
Далi коротко опишемо структуру засобу дь лення даних на блоки БРД [2], який реалiзуе про-грамну фiльтр-потокову модель для розробки додатшв з штенсивною обробкою даних. У цш моделi структура робочого додатока реалiзована у виглядi набору компонентiв, названих фiльтрами, що здшс-нюють обмiн даними через абстрагування (роздь лення) потоку. 1нтерфейс для фiльтра складаеться з трьох функцiй:
1) функцiя iнiцiалiзацii, в яшй розмiщенi та ви-значаються Bci необхiднi ресурси, так1 як пам'ять для структури даних;
2) функщя обробки, в якiй операцп, визначенi користувачем, застосовуються на елементах даних;
3) функцiя завершения, в яшй проходить звь льнення ресурав, що задiянi в функцii iнiцiалiзацii.
Фiльтри з'eднанi за допомогою лопчних потоков. Потiк визначаеться як однонапрямлений потiк даних вiд одного фшьтра (вiдправника розсилань) до шшого (отримувача). Фiльтр необх1дний для читання даних з його вхвдних потошв i запису даних виключ-но в його вихвдш потоки. В робот визначено буфер даних у виглядi масиву елементiв, переданих ввд одного фiльтра до шшого. Орипнальна реалiзацiя логь чного потоку доставляе даш в буфери фшсованого розмiру i використовуе TCP для потоково1' взаемодп мiж цими точками.
Загальна структура обробки додатка реaлiзу-еться за допомогою ф№трово1' групи, яка являе собою набiр з'еднаних м1ж собою фiльтрiв за допомогою лопчних потошв. Коли група фiльтрiв запуска-еться для обробки запиту додатка, то перш шж поча-ти виконання запиту програми, робоча система в цей момент здiйснюе з'еднання сокетiв мiж фiльтрами, розмiщеними на рiзних хост-комп'ютерах. Фiльтри, розмiщенi на одному комп'ютер^ дшть як окремi нитки. Запит додатку обробляеться групою фiльтрiв як единий робочий модуль (£РМ). Прикладом може бути вiзуалiзацiя набору даних в залежностi ввд кута спостереження. Обробка £РМ може бути здшснена в конвеерному режим^ в якому рiзнi фiльтри можуть працювати з рiзними елементами даних одночасно. Вона починаеться, коли послуга ф^трацп викликае функцiю iнiцiалiзацii ф№тра, який знаходиться там, де можуть бути попередньо розташоваш всi необхвд-нi ресурси, наприклад, так1 як пам'ять. Далi активу-еться функщя обробки, призначена для читання даних з будь-яких вхвдних потошв, роботи з даними, що надходять i розмiщуються по буферах, i запису даних в будь-як1 вихвдш потоки. Пiсля обробки останнього буфера передаеться спещальний маркер вiд системи обробки, щоб ввдзначити к1нець для поточного £РМ (рис. 3, а). Функщя завершення або фшал1зацп викликаеться пiсля завершення обробки поточного £РМ з метою звiльнення задiяних ресур-сiв, таких як робочий проспр. Функцii iнтерфейсу можуть активуватися в подальшому з метою обробки наступного £РМ.
Модель програмування надае калька розподь лень для полегшення оптимiзацii продуктивности Прозора копiя фiльтра - це кошя у групi фiльтрiв (рис 3, б). Вона прозора в тому сена, що розподшяе п ж сaмi логiчнi вхiднi i вихiднi потоки вихiдного фiльтрa. Прозора котя фшьтра може бути зроблена, якщо ввдсутнш вплив семантик ф№тровано1' групи. Тобто, вих1дний вигляд робочого блоку повинен бути незмшним, незалежно вiд числа прозорих копiй. Прозорi копii дозволяють пaрaлелiзм даних тшьки для виконання одиничного запиту, в той час як юлька груп фiльтрiв дозволяють пaрaлелiзм мiж дешлькома запитами.
Ф1льтрова система в режим! виконання тдт-римуе щею единого лопчного потоку вщ точки до точки для оргашзацп зв'язку м1ж лопчним фшьтром-ввдправником i лопчним фшьтром-отримувачем. Вш ввдповвдае за елементи планування (або буфери) в потоцi даних мiж прозорими копiями фiльтра. Для прикладу, на рис. 3, б, якщо котя P1 видае операщю запису буфера в логiчнiй попк, який виконуе з'еднання вiд фшьтра P до фiльтра F, буфер може бути вщправлений у виглядi копiй в host3 або host4. Для розподiлу мiж прозорими примiрниками система виконання шдтримуе циклiчно мпруючий механiзм (ЦММ) i механiзм керування попитом (МКП) на ос-новi рiвня буфера споживання. МКП спрямований на ввдправку буферiв на ф!льтр, що найшвидше мав би обробляти !х. Коли фiльтр споживача починае оброб-ку буфера, отриманого вщ фiльтра-вiдправника, вiн посилае йому поввдомлення пiдтвердження, щоб вщ-мiтити, що буфер знаходиться в процеа обробки. Фiльтр-вiдправник вибирае споживчий фiльтр з мшь мальною к1льк1стю непiдтверджениx буферiв для ввдправки даних буферу i, таким чином, досягаючи кращого балансу м1ж навантаженням.
Незважаючи на розвиток протокол1в з малим часом затримки i високою пропускною здатнiстю на рiвнi користувача, багато додатк1в були розроблеш ранiше на основi £егяе/-протокол1в, таких як TCP i UDP, а деяк! з цих додатшв потребували досить багато часу для !х розробки. Спроби переписати щ додат-ки на основi протоколiв рiвня користувача е досить трудомюткими i непрактичними. З шшого боку, ште-рфейс сокетiв широко використовуеться в р!зномаш-тних додатках, написаних на основi протоколiв, таких як TCP i UDP. Мережа cLAN е апаратним вть ленням вiртуального iнтерфейсу АВ1 (архггектури вiртуального iнтерфейсу або в лiтературi - Virtual Interface Architecture (VIA)). £ двi типовi сокетнi реа-л!зацп у мереж! cLAN. Одна з них е для утримання сокета наслщування, TCP/UDP i IP р!вшв незмшни-ми, у той час як один додатковий рiвень вводиться для з'еднання /Р-р!вня i kernel-рiвня р!вня в!ртуаль-ного штерфейсу. Застосування LANE (LAN Емуля-тора) на р!вш сокетiв - це така реалiзацiя, яка вико-ристовуе р!вш в!д IP до В1 [10]. Завдяки вершинам системних виклишв (в тому числ! контекстний kernel-перемикч, заповнення кешу, обробка TLB, обробники пристро!в шдр!вшв i т.д.) i мультикотям, введеним в цю реал!зацш, додатки, що використо-вують LANE не були в змоз! досягти повно! переваги високо! продуктивносп, представлено! в базовш мереж!. 1нший тип сокепв в мереж1 cLAN реал!зований для забезпечення сокетного штерфейсу з викорис-танням б!блютек р!вня користувача, що базуються на АЫ-примггавах р!вня користувача. Реал1защя в данш робот! потрапляе в цю категорш. 1де посилання на визначений сокетний р!вень, такий як САВ1, в решп частини викладеного матер!алу. Так як реал!защя САВ1 не е основною в данш статп, то результата мшро-теспв для нашого р!вня сокепв будуть представлен! в наступному роздш. Для шших деталей, пов'язаних з розробкою та здшсненням САВ1, можна звернутися до роботи [20].
б
Рис. 3. БРД в потоковому абстрагуванш i тдтримка копш: a - розмщення буфер!в даних i маркер!в кшця роботи потоку; б - встановлення груп фшьтр!в P, F, C при використанш прозорих копш
6. Результати дослвдження
Оцтка ефективностi
Дал! буде представлено дв! групи результата. По-перше, буде дослщжуватись максимальна про-дуктившсть, надана через САВ1 у вигляд! мшь теспв на час затримки i пропускну здатшсть. Подруге, буде розглянуто прямий i непрямий вплив на продуктившсть, представлену високопродуктивни-ми сокетами в додатках, реал!зованих з використан-ням БРД для того, щоб оцшити обидв! характеристики: час затримки i аспекти пропускно! здатносп на шляху контролю.
Експерименти проводилися на кластер! ПК, який складаеться з (16 виход!в) 420 вузл!в, з'еднаних мережами Giganet cLAN i Fast Ethernet. Використо-вуються хост-адаптери cLAN 1000 i кластерш св!ч! cLAN5300. Кожен вузол мае два процесори частоти 1 ГГц типу Pentium III, побудованих навколо Intel 840 чшсет, який мае чотири 32-бггаих 33 МГц PCI роз'еми. Ц вузли оснащен! 512 Мбайт SDRAM i 256 К кеш-пам'яттю р!вня L2. Верая ядра Linux-2.2.17.
Рис. 4, а демонструе час затримки, досягнутий високопродуктивним сокетом в пор!внянш з результатом, що досягаеться за допомогою традицшно! ре-ал!зацп сокепв на вершин! TCP i безпосереднього застосування VIA (базово! VIA). Реал!зований сокетний р!вень дае низьку затримку - 9,5 с, що дуже бли-зька до пе!, що надае VIA. Кр!м того, спостерйаеться покращення майже в п'ять раз!в в пор!внянш з часом затримки, що задаеться на р!вш традицшних сокепв через TCP/IP.
Рис. 4, б показуе пропускну здатшсть, досяг-нуту високопродуктивним сокетом в пор!внянш з використанням традицшних сокепв при базовому
використанш cLAN VIA. САВ1 досягае тково! про-пускно! здатносп 763 Мбайт/с в пор1внянш з 795 Мбайт/с, надано! VIA i 510 Мбайт/с, що нада-ються традицшною реалiзацiею TCP. Спостерiгаеться покращення майже на 50 %.
б
Рис. 4. Порiвняльнi графiки: а - часу затримки; б - пропускно! здатностi
Продуктивтсть i поведтка додатку
У цих експериментах використовувалися два види додатк1в. Перший додаток емулював сервер вДзуалДзацп. Це програма, що використовуе чотирьо-хступiнчатий конвеер з залученим фiльтром вДзуалД-зацД! на останньому етапi. Крiм того, проводились три копи кожного фшьтра в конвеерД, з метою покращення кДнцево! пропускнно! здатностi (рис. 5). Ко-ристувач вiзуалiзуе зображення у вузлi вДзуалДзаци, на якому знаходиться фшьтр вДзуалДзаци. Необхiднi данi витягуються зi сховища даних i передаються на iншi фiльтри, кожен з яких розмiщений на iншому вузлi в системi, що охоплюеться конвеером.
Кожне зображення, що розглядаеться користува-чем, вимагае даних об'емом в 16 Мбайт, яю отриму-ються i обробляються. Цд данi зберiгаються у виглядД фрагментДв заздалегДдь визначеного розмДру, яю нази-вають розмДром блоку розподшу. Для типового розмДру блоку розподшу повний образ складаеться з декшькох блоков (рис. 1). Коли користувач запрошуе оновлення для зображення (часткового або повного), вщповщт блоки повинш бути доставленi Д включет в едине зображення. Кожен блок витягуеться цшсно, що потен-цДйно може призводити до активащ! додаткових непо-трДбних даних, якД можуть бути передаю по мережД.
В роботД були змодельованД два види запитДв. Перший запит являе собою повне оновлення або за-
пит на нове зображення. ВДн вимагае, щоб всД блоки, що вДдносяться до запиту, були штегроваю в одне зображення. Цей вид оновлення е чутливим до пропускно! здатностД, тому було б добре використовува-ти великий розмДр блоку. Таким чином, як описано вище, для звичайного рДвня оновлення запитДв з пев-ною швидкДстю повинен бути використаний звичай-ний визначений розмДр блоку (або бшьший).
Рис. 5. Оцiнка ефективностi на основi гарантi! -експериментальна установка
Другий запит реалiзував часткове оновлення. Цей тип запиту виконуеться, коли користувач част-ково змiщуе вiкно вiзуалiзацi!', або намагаеться змь нити масштаб зображення, що розглядаеться в даний час. Для часткового оновлення запиту потрiбно тшьки додати надлишковi блоки, яких, як правило, невелика кшьюсть у порiвняннi з к1льк1стю блок1в, що утворю-ють повне зображення. Цей вид оновлення е чутливим до часу затримки. Кр!м того, фрагмента в цшому ввдно-влюються (витягуються або звужуються). Таким чином, було б корисно мати невелик! блоки.
Якщо розм!р блоку досить великий, часткове оновлення, ймов!рно, займе б№ше часу, так як весь блок видозмiнюеться, навiть якщо потрiбна невелика його частина. Якщо ж розм!р блоку занадто малий, повне оновлення займе довший час, так як повинш бути видозмшею багато менших за розм!ром блоков. Таким чином для додатку, який дозволяе обробку обидвох вид!в запитiв, необхвдно встановити продук-тивний компромю м!ж виконанням цих двох титв запитiв. У наступних експериментах демонструеться покращення масштабованосп додатку з VIA-сокетом у пор!внянш з TCP та гарантиями виконання для кожного виду оновлення. Результата будуть представленi нижче.
Другий додаток, що розглядаеться - це меха-юзм балансування навантаження програмного забез-печення, один !з таких, що використовуеться засобом БРД. Коли даю обробляються кшькома вузлами, то идеальна конвеернiсть даних досягаеться тод!, коли час, необхвдний для механiзму балансування навантаження для того, щоб посилати один блок повадом-лення до вузла обробки, дорiвнюе часу, витраченому вузлом обробки, щоб його обробити. У цьому додатку, типовий розм!р блоку вибираеться так, щоб дося-гти досконало! збалансовано! конвеерностi м!ж обро-бкою i комунiкацiею. Вважаеться, що потужюсть обчислення вузл!в не змiнюеться в ход! процесу виконання програми. В гетерогенному динашчному середовищi це припущення не тдтримуеться. У наших експериментах в однорщнш обстановцi доско-нала узгоджена конвеерюсть досягаеться при
16 Кбайт i при 2 Кбайт для TCP/IP i VIA, вщповвдно. Це означае, що po3Mip блоку необхiдний для TCP/IP значно б№ший, нiж для VIA. Однак в гетерогенних мережах, коли розмiр блоку помiтно великий, помил-ка в балансуванш навантаження (передача блоку да-них до сповiльненого вузла) може стати занадто "дорогою" (рис. 6). Вплив на продуктившсть з такою неоднорiднiстю буде розглянутий нижче.
Разом з САВ1 покращення продуктивносп роботи додатка з реоргашзащею його деяких компоненпв (розм!р блоку в даному випадку) дозволяе досягти значних переваг не тшьки в робот!, але i в масштабо-ваносп з гаранпями продуктивность
Рис. 6. Експериментальне представлення даних для ефекту гетерогенного кластера
Оцтка ефективностi на 6asi гарантИ
В!зьмемо до уваги ефект до^дження серед-нього часу затримки з гарантieю на оновлення за кожну секунду. У першш серп експерименпв корис-тувач намагаеться удосконалити заданий покадровий р!вень (тобто кшьшсть згенерованих нових зобра-жень або повних оновлень, виконаних за секунду). З цим обмеженням дослвджуеться середне значения часу затримки, що спостертаеться при частковому запит! на оновлення. Рис. 7, а, б демонструють ефек-тившсть роботи, досягнуту додатком. При заданш частот! кадр!в для нових зображень TCP вимагае пе-вного розм!ру поввдомлення для досягнення необхвд-но! пропускно! здатносп. З фрагментащею даних на частини, зробленою вщповвдно до ще! вимоги, час затримки для часткового оновлення за допомогою TCP повинен би вщповщати часу затримки для цього фрагменту повщомлення (позначений як TCP на легенд!). З тим же розм!ром фрагменту розбиття даних САВ1 забезпечуе б!льш високу продуктившсть (поз-начка САВ1 на легенд!). Проте САВ1 вимагае набага-то меншого розм!ру поввдомлення, щоб досягти пропускно! здатносп для повних оновлень. Так при пе-рероздшенш даних (ПД) на блоки з урахуванням часу затримки i пропускно! здатносп для САВ1, час за-тримки може бути додатково зменшений (позначка САВ1 з ПД на легенд!). Рис. 7, а демонструе продуктившсть без будь-яко! обробки. Цей експеримент тдкреслюе важливу вигоду, отриману за допомогою САВ1 без впливу наявних обчислювальних затрат на кожному вузль Можна спостертати, що TCP не може досягти обмеження оновлення бшьшого, шж 3,25 повних оновлень за секунду. Однак САВ1 (з поз-наченням ПД), як i рашше, можуть досягти цього кадрового р!вня без помггаого попршення в продуктивность Результати, отримаш в цьому експеримент!, показують покращення бшьш шж в 3,5 рази без будь-яких змш в блоковому перерозподш i б!льш шж в 10 раз!в з наявшстю блокового перерозпод!лу даних.
б
Рис. 7. Вплив високопродуктивних сокепв на середнiй час затримки з гаранпями оновлень в секунду: а - без обчислення вартостц б - з лiнiйним обчисленням вартостi
Рис. 7, б демонструе роботу додатка з ураху-ванням затрат на обробку, яка е лшшною вiд розмiру повiдомлення в експериментах. Було проведено ви-мiрювання часу обробки, необхвдного для вiзуалiзацii частини додатка цифровоi мшроскопп, названоi' вiр-туальним мшроскопом [17], на БРД i виявлено, що це становить 18 nc на один байт поввдомлення. Подiбнi програми, що використовують перегляд цифрованих мiкроскопiчних слайдiв, мають низьш затрати обробки на пiксель. Це програми, що отримують перевагу в залежносп вiд низького часу затримки i високо! пропускноi здатностi промiжних вузлiв. Таким чином, в цш роботi зосередження формуеться на подiб-них додатках.
На вiдмiну ввд попереднього експерименту, в цьому експерименп навиъ САВ1 (з ПД) не змогли досягти рiвня, вищого за 3,2. Причина цього полягае в тому, що пропускна здатшсть, задана САВ1, обмежена
затратами обробки в кожному вузлг У цьому експе-риментi спостертаеться покращення б!льш шж на 4 рази безблокового перерозподалу даних та на 12 ра-з!в з блоковим перерозподiлом даних, вщповщно.
Розглянемо ефект оновлення за секунду з га-panmiMMu часу затримки. У другш серп експеримен-лв ще намагання максимально збшьшити к1льк1сть повних оновлень в секунду, коли конкретне значення часу затримки е тково-результуючим для часткового запиту на оновлення. Рис. 8, а, б демонструють покращення продуктивносл, досягнуто! додатком. Для конкретно заданого часу затримки TCP не може мати розм!р блоку б!льший, шж певне значення. З розбит-тям даних, вщтвореним вщповщно до ще! вимоги, покращення пропускно! здатностi е дуже обмеженим, як видно на малюнку з позначкою "TCP". З таким же розм!ром блоку САВ1 досягае набагато кращо! продуктивносл, що демонструеться на рисунку з позначкою "САВ1". Однак, перефрагментащя даних, що враховуе час затримки i пропускну здатнiсть САВ1, що згадувались в результатах обговорення вище, до-сягае набагато вищо! продуктивносл, як показано на рисунку (з! значенням продуктивносл, позначено! "САВ1 ПД"). Рис. 8, а подае значення продуктивносл без будь-яко! обробки даних, а значення продуктивносл з урахуванням затрат на обробку даних, що ль ншно залежить вщ розм!ру блоку, демонструеться в експериментальних результатах на рис. 8, б. Без затрат на обробку, коли час затримки обмежуеться i стае досить низьким, б!ля 100 |as, TCP р!зко падае. Однак, САВ1 продовжуе роботу з характеристиками, близькими до ткових значень. Результата експери-менту демонструють покращення б!льше шж в 6 ра-з!в без будь-якого перерозпод!лу блоков даних, а та-кож бшьш шж у 8 раз!в з застосуванням блокового перерозпод!лу даних. Враховуючи витрати на обробку даних можна бачити, що з великою гаранлею часу затримки робота з TCP i САВ1 дуже схожа. Причина в цьому полягае в затратах на обробку на шляхах сполучення. З затратою на обробку у 18 пс/байт, об-робка даних все-таки виходить на р!вень незростання з VIA, а з використанням TCP система передач! ско-рше досягае цього р!вня. З однаково! причини, на вщм!ну вщ TCP, кадровий р!вень, досягнутий САВ1, непомггно зм!нюеться з! зменшенням часу затримки. Результати цього експерименту показують шдви-щення р!вня продуктивносл до 4 раз!в.
Дал! розглянемо ефект впливу декшькох запитiв на середнт час зворотньо'1 реакцН. У третш сер!! екс-перименлв розглянута модель з наявтстю двох вид!в запилв. Перший тип запиту - це запит на масштабу-вання або збшьшення, а другий - запит на повне онов-лення. Перший запит охоплюе невелику область зо-браження, що вимагають лльки чотири блоки даних, яю повинш бути вщновлеш Другий запит охоплюе все зображення, таким чином ва блоки даних повинш бути вщновлеш i оброблеш Рис. 9, а, б вщображають середнш час зворотнього вщклику на запити. Вюь х показуе частину запилв, як1 вщповщають другому типу. Решта запилв вщповщають першому типу. Об'ем блоку даних, встановлений для кожного запиту, залежить вщ розбиття повного обсягу даних на блоки.
Оскшьки частина запипв кожного виду не може бути вщома апрюрно, то анал!зуеться ефектившсть TCP i САВ1 з р!зними розм!рами подшу. Якщо повний наб!р даних не роздшений на блоки, запит мае доступ до вах даних, тому затрати часу не зм!нюються з! змшою частки запилв. Переважаючий вклад САВ1 в пор!в-нянш з TCP полягае лише у властивш переваз! САВ1 i не мае шчого спшьного з розм!рами блоюв. Однак з перерозподшом набору даних на бшьш др!бш блоки, р!вень зростання часу вщклику стае досить високий для TCP в пор!внянш з САВ1. Таким чином, для будь-якого середнього фшсованого часу вщклику САВ1 може витримувати б!льш! змши в частщ р!зних титв запипв, шж TCP. Наприклад, при середньому час! зворотнього вщклику 150 мс i 64 блоки на повний на-б!р даних, TCP може щдтримувати змши в даапазош до ~60 % (у вщсотках вщ повного оновлення запипв), але шсля цього спадае. При таких же умовах САВ1 може щдтримувати змши в дапазош до ~90 % перед незначним зниженням. Це показуе, що в тих випадках, коли розм!р блоку не може бути передбачений i наперед визначений, або коли тшьки е правильний виб!р розм!ру блоку, САВ1 д!е набагато краще.
■ TCP
П CABI П САШ з ПЛ
Р
I Г ! ■■ I I ПН
час затримки*J0 мод ■ с
Р I I
Irin 1111111 г
б
Рис. 8. Ефект впливу високоефективних сокелв на оновлення за секунду з гаранлями часу затримки: а - без врахування затрат на обробку; б - з лшшними затратами на обробку
а
Вплив САВ1 на гетерогент кластери
У експериментах анал1зуеться ефект впливу САВ1 на кластер з набором гетерогенних обчислю-вальних вузл1в. Емулюються пов1льн1ш1 вузли в мереж1, змушуючи деяш вузли обробляти даш бшьш шж один раз. Для хост-протокол1в, таких як TCP, зменшення швидкосп обробки може призвес-ти до попршення часу зв'язку, а заодно, до попршення часу обробки. Все ж, в цих експериментах припускаеться, що час комушкацп залишаеться сталим, i тшьки змшюеться час обробки.
Розглянемо вплив ци^чног схеми планування на гетерогеннi кластери. В цьому експерименп роз-глядаеться вплив на продуктившсть в буферi з ЦММ, запланованому в БРД з використанням TCP i САВ1. Для досягнення iдеальноï конвееризацп час, необхвд-ний для передачi даних до вузла, повинен дорiвнюва-ти часу обробки даних на кожному з вузлiв. Для цього експерименту розглядаеться баланс розподiлу на-вантаження мiж фiльтрами додатка вiзуалiзацiï (пер-шi вузли в конвеернiй лши на рис. 6). Час обробки даних в кожному фiльтрi е лтйним вiд розмiру повь домлення i становить ~18 пс/байт повщомлення. З участю TCP iдеальну конвеерють було досягнуто для поввдомлень до 16 Кбайт, а для САВ1 цей показник було досягнуто за допомогою повщомлень в 2 Кбай-ти. Таким чином, балансування навантаження може охоплювати бiльшу деталiзацiю.
Рис. 10 демонструе кiлькiсть часу, необхщну для балансування навантаження, необхiдного для досягнення гетерогенносп вузлiв зi збшьшенням фактора гетерогенностi в мереж1. Фактор неодно-рiдностi спiввiдноситься зi швидшстю обробки найшвидших i найповiльнiших процесорiв. З використанням TCP розмiр блоку е великим (16 Кбайт). Таким чином, коли при балансуванш навантаження виникае помилка (блок передаеться до бшьш повь льного вузла), це призводить у повшьному вузлi до затрати значно бiльшоï кшькосп часу на обробку цього блоку. Це збшьшуе час, який балансування навантаження потребуе для реалiзацiï його помил-ки. З шшого боку, з використанням САВ1 розмiр блоку малий. То ж коли при балансуванш навантаження виникае помилка, кшьшсть часу, що ви-трачаеться на повшьному вузлi для обробки цього блоку, менша порiвняно з TCP. Таким чином, час реакцп балансування навантаження е меншим. Результата цього експерименту показують, що при САВ1 час реакцп балансування навантаження спа-дае з коефщентом 8 в порiвняннi з TCP.
Розглянемо вплив сплановано'1 схеми керування попитом на гетерогеннi кластери. Для цього експерименту розглянуто вплив на продуктившсть керування запитом (МКП) буферного планування в БРД при використанш TCP i САВ1. З пе1' ж причини, що i при використанш схеми циктчного планування (зга-дуеться в попередньому пункп) розмiр блоку 2 Кбай-ти був обраний для САВ1 i розмiр блоку 16 Кбайт -для TCP. Рисунок 11 демонструе час виконання дода-тку. Передбачаеться, що вузол повинен ставати в чай динамiчно пов№шшим. Iмовiрна сповiльненiсть вузла змiнюеться на осi абсцис. Таким чином, ймовiр-
нiсть 30% означае, що 30% обробки даних здшсню-еться в б№ш повiльному темпi, а iншi 70% здшсню-ються в темт початково1' фази вузла. Позначення САВ1(п) на рисунку позначае додатки, що працюють з використанням САВ1 i коефiцiентом неоднорiдностi n. Iншi позначення легенди iнтерпретуються таким же способом.
a
частина поешстю оновленого запиту
б
Рис. 9. Вплив високопродуктивних сокепв на середнш
час зворотно1' реакцп запипв: а - без врахування затрат обробки; б - з лшшними затратами на обробку
■ CAEI ■ TCP
1
■
фактор гетерогенности
Рис. 10. Вплив неоднорвдносп на швидк1сть обробки при балансуванш навантаження з використанням циктчно!' схеми планування
-*- без подшу (САВГ) 8 блоыв (САВГ) 64 блоки (САВГ) —без подшу (TCP) -»- S блоыв (TCP) -*- 64 блоыв (TCP)
без подшу (САВГ) 8 блоыв (САВГ) 64 блоки (САВГ) —без подшу (TCP) — 8 блоыв [TCP) -*- 64 блоыв (TCP)
В 14
nl
s 112
110 s
U 8
— С ABI Ц)
• САШ (4)
• CAB 1(8)
TCP (2)
-*- TCP (4)
Ефект гетерогенности в кластер! . TCP (8)
....
10
30 50 70
ШОВфШСТЬ СПОБШЬНеННЯ. %
90
Рис. 11. Вплив неоднорщносп на швидк1сть обробки при балансуванш навантаження за допомогою схеми планування керованого попиту
Видно, що продуктившсть додатшв, що вико-ристовують протоколи TCP е близькою до таких же, що використовують САВ1. Це, в основному, стаеться через факт, що призначення блоков даних за допомогою керування запитом до споживач1в дозволяе спрямовано виконувати б1льшу роботу на менш зава-нтажених процесорах. До того ж, конвееризаця результата даних забезпечуе хороше перемщення 1х м1ж комушкащею i обробкою. Отже результати пока-зують, що якщо високопродуктивнi сокети не наявш на апаратнiй конфшураци, додатки повиннi бути структурованi так, щоб скористатися конвееризащею в процесi обробки i динамiчним плануванням даних. Однак, як показують результати, використання висо-копродуктивних сокетiв е бажаним для гарантш часу очiкування i продуктивность
5. Висновки та перспективи подальших до-слiджень
Разом з вимогами продуктивносп додатки з iнтенсивною обробкою даних мають також i iншi вимоги, так1 як гарантiя продуктивносп, масштабо-ванiсть цих гарантiй i пристосовнiсть до гетероген-них мереж. Як правило, так додатки, написаш з ви-користанням iнтерфейсу сокета на базi kernel та TCP/IP. Щоб дозволити таким додаткам мати перевагу використовувати високоефективш протоколи, дос-лвдники наблизились до цього через опрацювання ряду методiв, в тому чи^ i високопродуктивних шарiв сокетiв через протоколи на рiвнi користувача, таких як АВ1 i АНВ. Тим не менше, щ рiвнi сокетiв принципово обмеженi тим, що додатки, яш використовують 1х, були написанi зi збереженням продукти-вностi зв'язку в TCP/IP.
У робот вивчаються можливостi та обмежен-ня для високопродуктивних сокета САВ1 у ходi ро-боти по вщношенню до компонентного тдходу, пок-ликаного забезпечити текучу тдтримку процесу ви-конання додатк1в з штенсивною обробкою даних, що називаеться також БРД. Експериментальш результати показують, що шляхом реоргашзаци окремих компонента додатк1в, досягаються значнi покращен-ня в продуктивностi, що приводить до пвдвищення масштабованостi додатк1в з гарантами виконання i дрiбноблокового балансування навантаження, яке, в
свою чергу, робить 1х бiльш адаптованими до гетеро-генних мереж. Експериментальнi результати також показують, що рiзнi характеристики роботи САВ1 дозволяють ефективнiший подш даних на вихiдних вузлах, що покращуе продуктивнiсть в деяких випад-ках аж до рiвня тдвищення на порядок. Це свiдчить, що в поеднанш з високою продуктивною сокети з низькими накладними затратами надають можливiсть додаткам досягти яшсних показник1в в ходi 1х реаль зацй' у багатьох напрямках вимiрювання. Цi результати мають чггке застосовуються у проектуваннi, розробцi та реалiзацil додатк1в з iнтенсивною обробкою даних нового поколшня на сучасних кластерах.
Лггература
1. Guerin, R. Network Quality of Service, The Grid: Blueprint for a New Computing Infrastructure [Text] / R. Guerin, H. Schulzrinne; I. Foster, C. Kesselman, (Eds.). -Morgan Kaufmann, San Francisco, 1999. - 479-503.
2. Beynon, M. D. Distributed processing of very large datasets with DataCutter [Text] / M. D. Beynon, T. Kurc, U. Catalyurek, C. Chang, A. Sussman, J. Saltz // Parallel Computing. - 2001 - Vol. 27, Issue 11. - Р. 1457-1478. doi: 10.1016/s0167-8191(01 )00099-0
3. Oldfield, R. Armada: A parallel file system for computational [Text] / R. Oldfield, D. Kotz // In Proceedings of CCGrid2001, 2001. - Р. 194-201. doi: 10.1109/ccgrid. 2001.923193
4. Plale, B. dQUOB: Managing Large Data Flows by Dynamic Embedded Queries [Text] / B. Plale, K. Schwan // IEEE High Performance Distributed Computing (HPDC), 2000. - Р. 1-8. doi: 10.1109/hpdc.2000.868658
5. GigaNet Corporations [Electronic resource] / Available at: http://www.giganet.com
6. Boden, N. J. AGigabitper-Second Local Area Network. [Electronic resource] / N. J. Boden, D. Cohen, R. E. Felderman, A. E. Kulawik, C. L. Seitz, J. N. Seizovic, W. K. Su Myrinet. - Available at: http://www.myricom.com
7. Frazier, H. Gigabit Ethernet: from 100 to 1000Mbps [Text] / H. Frazier, H. Johnson // IEEE Internet Computing. -1999. - Vol 3, Issue 1. - Р. 24-31. doi: 10.1109/4236.747317
8. Infiniband Trade Association [Electronic resource] / Режим доступу: http://www.infinibandta.org
9. Petrini, F. The Quadrics Network (QsNet): HighPerformance Clustering Technology [Text] / F. Petrini, W. Feng, A. Hoisie, S. Coll, E. Frachtenberg // HOT 9 Interconnects. Symposium on High Performance Interconnects. - 2001. -Vol. 9. - Р. 125-130. doi: 10.1109/his.2001.946704
10. GigaNet Corporations [Text] / cLAN for Linux: Software Users' Guide.
11. Myricom Corporations [Text] / The GM Message Passing System.
12. Pakin, S. High Performance Messaging on Workstations: Illinois Fast Messages (FM) [Text] / S. Pakin, M. Lauria, A. Chien // In Proceedings of Supercomputing, 1995. -P. 55. doi: 10.1145/224170.224360
13. Buonadonna, P. BVIA: An Implementation and Analysis of Virtual Interface Architecture [Text] / P. Buo-nadonna, A. Geweke, D. E. Culler // In Proceedings of Supercomputing, 1998. - P. 7-13. doi: 10.1109/sc.1998.10052
14. Kim, J. S. SOVIA: A User-level Sockets Layer over Virtual Interface Architecture [Text] / J. S. Kim, K. Kim, S. I. Jung // In the Proceedings of IEEE International Con-ference on Cluster Computing, 2001. - P. 1-10. doi: 10.1109/clustr.2001.960006
15. Shah, H. V. High Performance Sockets and RPC over Virtual Interface (VI) Architecture [Text] / H. V. Shah, C. Pu, R. S. Madukkarumukumana // In the Proceedings of
CANPC workshop (held in conjunction with HPCA Conference), 1999. - P. 91-107. doi: 10.1007/10704826_7
16. Afework, A. Digital dynamic telepathology - the Virtual Microscope [Text] / A. Afework, M.D. Beynon, F. Bustamante, A. Demarzo, R. Ferreira, R. Miller, M. Silberman, J. Saltz, A. Sussman, H. Tsang // In Proceedings of the 1998 AMIA Annual Fall Symposium. American Medical Informatics Association, November, 1998. - P. 1 -10.
17. Catalyurek, U. The virtual microscope [Text] / U. Catalyurek, M. D. Beynon, C. Chang, T. Kurc, A. Sussman, J. Saltz // IEEE Transactions on Information Technology in Biomedicine. To appear. - 2003. - Vol. 7, Issue 4. - P. 230248. doi: 10.1109/titb.2004.823952
18. Beynon, M. Design of a framework for dataintensive wide-area applications [Text] / M. Beynon, T. Kurc, A. Sussman, J. Saltz // In Proceedings of the 9th Heterogneous Computing Workshop (HCW2000), IEEE Computer Society Press, 2000. - P. 116-130. doi: 10.1109/hcw.2000.843737
19. Balaji, P. Impact of High Performance Sockets on Data Intensive Applications [Text] / P. Balaji, J. Wu, T. Kurc, U. Catalyurek, D. K. Panda, J. Saltz // Technical Report OSU-CISRC-1/03-TR05, The Ohio State University, Columbus, OH, 2003. - P. 1-10. doi: 10.1109/hpdc.2003.1210013
References
1. Guerin, Roch and Schulzrinne, Henning (1999). Network quality of service, in The Grid: Blueprint for a Future Computing Infrastructure, I. Foster and C. Kesselman, eds., Morgan Kaufmann Publishers, 479-503.
2. Beynon, M. D., Kurc, T., Catalyurek, U., Chang, C., Sussman, A., Saltz, J. (2001). Distributed processing of very large datasets with DataCutter. Parallel Computing, 27 (11), 1457-1478. doi: 10.1016/s0167-8191(01)00099-0
3. Oldfield, R., Kotz, D. (2001). Armada: A parallel file system for computational. In Proceedings of CCGrid2001, 194201. doi: 10.1109/ccgrid.2001.923193
4. Plale, B., Schwan, K. (2000). dQUOB: Managing Large Data Flows by Dynamic Embedded Queries. IEEE High Performance Distributed Computing (HPDC), 1-8. doi: 10.1109/hpdc.2000.868658
5. GigaNet Corporations. Available at: http://www. giganet.com
6. Boden, N. J., Cohen, D., Felderman, R. E., Kulawik, A. E., Seitz, C. L., Seizovic, J. N., Su, W. K. Myrinet: AGiga-bitper-Second Local Area Network. Available at: http://www.myricom.com
7. Frazier, H., Johnson, H. (1999). Gigabit Ethernet: from 100 to 1000Mbps. IEEE Internet Computing, 3 (1), 2431. doi: 10.1109/4236.747317
8. Infiniband Trade Association. Available at: http://www.infinibandta.org
9. Petrini, F., Feng, W., Hoisie, A., Coll, S., Frachtenberg, E. (2001). The Quadrics Network (Qsnet): HighPerformance Clustering Technology. HOT 9 Interconnects. Symposium on High Performance Interconnects, 9, 125-130. doi: 10.1109/his.2001.946704
10. GigaNet Corporations. cLAN for Linux: Software Users' Guide.
11. Myricom Corporations. The GM Message Passing System.
12. Pakin, S., Lauria, M., Chien, A. (1995). High Performance Messaging on Workstations: Illinois Fast Messages (FM). In Proceedings of Supercomputing, 55. doi: 10.1145/ 224170.224360
13. Buonadonna, P., Geweke, A., Culler, D. E. (1998). BVIA: An Implementation and Analysis of Virtual Interface Architecture. In Proceedings of Supercomputing, 7-13. doi: 10.1109/sc.1998.10052
14. Kim, J. S., Kim, K., Jung, S. I. (2001). SOVIA: A User-level Sockets Layer over Virtual Interface Architecture. In the Proceedings of IEEE International Conference on Cluster Computing, 1-10. doi: 10.1109/clustr.2001.960006
15. Shah, H. V., Pu, C., Madukkarumukumana, R. S. (1999). High Performance Sockets and RPC over Virtual Interface (VI) Architecture. In the Proceedings of CANPC workshop (held in conjunction with HPCA Conference), 91 -107. doi: 10.1007/10704826_7
16. Afework, A., Beynon, M. D., Bustamante, F., Demarzo, A., Ferreira, R., Miller, R., Silberman, M., Saltz, J., Sussman, A., Tsang, H. (1998). Digital dynamic telepathology -the Virtual Microscope. In Proceedings of the 1998 AMIA Annual Fall Symposium. American Medical Informatics Association, 1 -10.
17. Catalyurek, U., Beynon, M. D., Chang, C., Kurc, T., Sussman, A., Saltz, J. (2003). The virtual microscope. IEEE Transactions on Information Technology in Biomedicine, 7 (4), 230-248. doi: 10.1109/titb.2004.823952
18. Beynon, M., Kurc, T., Sussman, A., Saltz, J. (2000). Design of a framework for data-intensive wide-area applications. In Proceedings of the 9th Heterogneous Computing Workshop (HCW2000), IEEE Computer Society Press, 116-130. doi: 10.1109/hcw.2000.843737
19. Balaji, P., Wu, J., Kurc, T., Catalyurek, U., Panda, D. K., Saltz, J. (2003). Impact of High Performance Sockets on Data Intensive Applications. Technical Report OSU-CISRC-1/03-TR05, The Ohio State University, Columbus, OH, January, 1-10. doi: 10.1109/hpdc. 2003.1210013
Рекомендовано до публiкацii д-р техн. наук, професор Максимович Л. В.
Дата надходження рукопису 20.05.2015
Мельник Василь Михайлович, кандидат ф!зико-математичних наук, доцент, кафедра комп'ютерно! ш-женери, Луцький нацюнальний техшчний ушверситет, вул. Льв!вська, 75, м. Луцьк, Укра!на, 43018 E-mail: melnyk_v_m@yahoo.com
Мельник Катерина BiKTopiBHa, кандидат техшчних наук, доцент, кафедра комп'ютерно! шженерп, Луцький нацюнальний техшчний ушверситет, вул. Льв!вська, 75, м. Луцьк, Укра!на, 43018 E-mail: ekaterinamelnik@gmail.com
Багнюк Нaтaлiя Boлoдимиpiвнa, кандидат техшчних наук, доцент, кафедра комп'ютерно! !нженери, Луцький нацюнальний техючний уюверситет, вул. Льв!вська, 75, м. Луцьк, Укра!на, 43018
