Содержание к диссертации
Введение
1 Применение систем распределённых вычислений для решения обратных задач геофизики 38
1.1 Обзор ключевых принципов работы высокопроизводительных систем 38
1.2 Особенности высокопроизводительных систем, созданных в рамках этой работы 42
1.2.1 Доступ к данным в высокопроизводительных системах, созданных в рамках этой работы 45
1.2.2 ПО для организации распределённых вычислений 49
1.2.3 Программная архитектура используемых вычислительных ресурсов 56
1.2.4 Программная архитектура платформы интеграции и проблемно-специфических приложений 58
1.3 Применение разработанного ПО для решения задачи опреде ления параметров анизотропии по волновым формам 66
1.3.1 Описание задачи 66
1.3.2 Программное решение 69
1.3.3 Использование реляционной СУБД 69
1.3.4 Анализ и визуализация результатов 73
1.4 Выводы 77
2 Создание элементов автономного оперативного регистратора сей смических данныхиданных ГНСС 78
2.1 Введение 78
2.2 Опыт создания портативной автономной сейсмологической станции, работающей по протоколу реального времени 79
2.3 Создание пункта сбора данных и оперативного мониторинга ГНСС 87
2.4 Использование технологий виртуальных частных сетей для сбора данных оперативных систем геофизических наблюдений 90
2.5 Заключение 99
Заключение 101
Глоссарий 102
Список рисунков 105
Список таблиц 106
Список литературы
- Доступ к данным в высокопроизводительных системах, созданных в рамках этой работы
- Применение разработанного ПО для решения задачи опреде ления параметров анизотропии по волновым формам
- Опыт создания портативной автономной сейсмологической станции, работающей по протоколу реального времени
- Использование технологий виртуальных частных сетей для сбора данных оперативных систем геофизических наблюдений
Доступ к данным в высокопроизводительных системах, созданных в рамках этой работы
Сбор геофизических данных в современном его понимании – это комплексная работа на всех уровнях – от установки прибора в полевых условиях – до организации оперативной обработки поступающих от множества регистраторов данных. Регистраторы в составе станций сбора данных занимают одно из ключевых мест в системе оперативного геофизического мониторинга. От их параметров зависят как качество получаемых данных, так и стоимость эксплуатации. Под стоимостью эксплуатации понимается объем вмешательства специалиста в процессы установки и обслуживания, а также стоимость расходных материалов и услуг – батарей или услуг по электроснабжению и услуг передачи данных. Во второй главе описаны основные требования к регистраторам, работающим под управлением операционных систем Linux и Windows, с точки зрения ПО и аппаратуры.
Описывая требования к ПО регистратора необходимо обозначить два разных типа данных, с которыми работают регистраторы. Первый тип данных – временные ряды. Такие данные производят сейсмометры, акселерометры, магнитометры и другие приборы, применяемые в геофизике. Основными характеристиками таких данных является частота дискретизации (англ. sampling rate), количество каналов, разрядность получаемых значений. В современных дата-центрах сбор таких данных осуществляется по общепринятым протоколам реального времени. Если вновь устанавливаемая станция поддерживает такие стандарты, то их легко включить в существующую систему обработки информации в центрах без дополнительной загрузки персонала этих центров. Помимо этого, такой подход позволяет существенно снизить затраты при разворачивании густой сети станций в зонах афтершо-ковой активности после крупных землетрясений, и делать это в максимально сжатые сроки. Наконец, при отсутствии широкополосных каналов при организации интернет-соединения становится существенной загрузка канала, вызванная использованием сетевых служб высокого уровня. Поэтому актуальной задачей развития стало создание программных средств, которые позволят реализовать сейсмические протоколы реального времени для передачи данных в портативной телеметрической сейсмической станции.
На текущий момент используются в той или иной мере следующие протоколы: SeedLink[27], Earthworm[28], Antelope[29], LISS, SCREAM, CD-1.1, ComServ. Seedlink – это протокол для «надежной» передачи данных посредством TCP/IP. «Надежность» протокола заключается в том, что клиенты могут терять и восстанавливать соединения без потерь данных. Seedlink устойчив к разрывам связи за счет использования кольцевого буфера, который хранит некоторый объем данных, и разорванное соединение сможет «догнать» реальное время. Программная архитектура серверной части позволяет передавать данные нескольких станций и нескольких каналов в одном потоке данных, причем позволяет это делать выборочно для каждого подключения. Данные внутри потока данных Seedlink представляют собой 512-байтные записи miniSEED[30]. Протокол используется в сейсмических сетях IRIS[31] Геологической службы США и сетях системы GEOFON Научно-исследовательского центра наук о Земле GFZ Potsdam[32]. Доступны программные интерфейсы для C/C++, Python, Java и некоторых других программных платформ.
Проект Earthworm был начат в 1993 как ответ на растущие потребности региональных сейсмических сетей. Система позиционируется как центральное звено для обработки сейсмических данных. Для передачи используется формат Waveform[33] внутри датаграмм UDP или, в современных версиях WaveServer – компонента для передачи данных через Интернет – посредством TCP. Встроенные механизмы позволяют минимизировать потери данных при разрывах или нестабильной связи.
Antelope Realtime System – коммерческая мультиплатформенная гибкая система, создававшаяся для осуществления полного цикла сейсмических наблюдений в реальном времени – от сбора данных с нескольких регистраторов до автоматического определения параметров событий. Antilope не вынуждает пользователя использовать какой-либо определённый формат, так как внутри протокола передачи данных ORB, используемом в Antilope, могут быть любые форматы: SEED, mSEED, netCDF и прочие. Система может быть использована как ядро центра сбора геофизических данных, собирая данные по протоколу ORB с нескольких регистраторов и выполняя автоматический анализ, но последнее требует разработки под конкретные задачи с помощью программных интерфейсов Antelope.
LISS (англ. Live Internet Seismic Server) – протокол передачи данных, разработанный в USGS. Изначально протокол использовался как для получения данных с регистраторов, так и для распространения от центров данных к потребителям. Позже для протокола осталась только последня роль. На сегодняшний момент практически вышел из употребления и вытеснен SeedLink ом.
CD-1.1 (англ. Continuous Data) предоставляет способ надежной передачи непрерывного потока данных. Назначением разрабатываемоговрамках подготовительной комиссии организации договора о всеобъемлющем запрещении ядерных испытаний с 1995 года протокола являлось стандартизация всего программного обеспечения в международном центре обработки данных (англ. International Data Center, IDA) и национальных центрах обработки данных (англ. National Data Center, NDA).
Решения производителей оборудования (SCREAM, ComServ и пр.) зачастую являются устройство-зависимыми либо имеют недостаточную поддержку в распространенных программных решениях и, иногда, закрытыми, поэтому в рамках данной работы не рассматриваются.
Второй тип данных, на котором специализируются регистраторы – это сложные типы данных, например, данные измерений систем Глобальных Навигационных Спутниковых Систем. В таких данных получаемые со спутника сигналы представляют собой набор сообщений, содержащих самую разную информацию (характеристики эмитируемого сигнала, положение спутника, информация о состоянии приёмника) и имеющих нетривиальную лексическую структуру. Такая организация данных не может быть сведена к набору простых временных рядов, хотя бы потому, что имеется значительное число сообщений, содержащих массивы переменной длины.
Стандартная процедура регистрации, рекомендованная производителем приёмников, подразумевает запись всех сообщений в бинарном виде в формате производителя. Однако такая форма организации данных плохо приспособлена для осуществления доступа как при необходимости поиска и выборки из архива, так и для передачи данных в режиме реального времени. Бинарный формат тем более не может использоваться для обмена данными с широким набором потребителей. Обычно для этих целей используется стандартные форматы обмена RINEX (англ. Receiver Independent Exchange Format)[34], а также протокол передачи данных в реальном времени NTRIP (англ. Network Transport of RTCM via Internet Protocol)[35]. К сожалению, эти форматы также не могут рассматриваться как основа для создания оперативной службы, т.к. NTRIP не передаёт всех данных, которые поставляет приёмник, а RINEX, кроме той же проблемы, ещё и не предусматривает оперативную передачу в своём стандарте. Причина ограничения разнообразия данных является результатом договоренности производителей приемного оборудования: ни RINEX, ни, тем более, NTRIP не могут содержать все данные, получаемые с конкретного регистратора, поэтому их нельзя использовать для сбора и хранения данных в универсальном и, вместе с тем, полном виде. Таким образом, необходим универсальный формат для передачи и хранения данных в полном виде.
Кроме принципиально разных типов собираемых и передаваемых данных ПО регистратора должно быть гибким и надежным. В частности, регистратор должен реализовывать интерфейсы для информирования эксплуатирующей группы о состоянии оборудования: напряжения питания, температуры, целостности корпуса, а так же обеспечивать возможности оперативной перенастройки и обновления ПО. Регистраторы геофизических данных могут применяться в самых разных условиях - от полевых установок при тяжелых климатических условиях до установки внутри помещения. В первом случае основными аппаратными характеристиками являются низкое энергопотребление, компактные размеры, устойчивость к внешним воздействиям. Для удобства в рамках данной работы обобщим такие устройства как просто «регистраторы с низким энергопотреблением». Вторая группа - регистраторы, устанавливаемые в помещениях. Как правило, такие места установки не ограничены по электропитанию (в масштабах десятков ватт), поэтому вполне допустимо использовать потребительские настольные компьютеры, в частности, неттопы. Нет-топ - это обычный персональный компьютер, имеющий небольшой корпус (обычно не более 30 см диагонально и 5-10 см в толщину), и, часто, пассивное охлаждение. Последнее является особой характеристикой, т.к. такие системы обычно более надежны ввиду меньшего тепловыделения в целом.
Применение разработанного ПО для решения задачи опреде ления параметров анизотропии по волновым формам
В высокопроизводительных системах ключевым программным механизмом является система запуска и управления очередями (иначе говоря – планировщик). Система запуска – это та система, которая непосредственно взаимодействует с пользователем, получая от него необходимые для выполнения расчетов данные и параметры. В распределенных вычислитель ных системах используются похожие по функционалу системы, заметным отличием последних принято считать возможность работать в гетерогенной среде и подключаться к другим системам запуска. ПО для организации распределённых вычислений – это специальный класс ПО, называемый промежуточное ПО (англ. middleware), призванный организовать многопользовательскую работу в распределенных системах, а так же обезопасить распределенную систему от несанкционированного использования. Распределенные системы, использующие такое ПО, называются грид-системами, или просто грид. Промежуточное ПО можно условно разделить на две группы по принципу используемых вычислительных ресурсов: ресурсы специально выделенных для этого компьютеров в первом случае – Globus Toolkit, UNICORE, ARC – и простаивающие ресурсы персональных компьютеров – BOINC, XtremWeb. Грид-системы, использующие ПО первой группы, часто называют волонтерскими или добровольными грид-системами. Проекты, основанные на волонтерских грид-системах, обычно в течение длительного периода решают одну задачу, например: поиск путей улучшения климатических моделей [59], проверки гипотезы Коллатца [60], поиск радиосигналов внеземных цивилизаций [61] и множество других проектов. Для организации подобного проекта необходимо расчетную задачу реализовать с использованием программных интерфейсов выбранного промежуточного ПО, кроме этого необходимо настроить специальный сервер проекта и предоставить к нему надежный доступ из интернета. Использование ПО второй группы является менее технически сложным, чем реализация проекта с использованием волонтёрских грид-систем. Грид-системы, состоящие из спе 51
циально выделенных для распределенных вычислений высокопроизводительных компьютеров, используют вторую группу промежуточного ПО,к которой, в первую очередь, следует отнести такое ПО как Globus Toolkit, gLite, UNICORE, ARC и другие. В большинстве реализаций можно выделить пять основных компонентов этого ПО: службу аутентификации пользователей, инструментарий для запуска задач или программные интерфейсы, планировщик задач, средства доставки данных и средства мониторинга. Приведенные компоненты могут различаться по функциональности и сложности, быть частью другого ПО и даже отсутствовать. Это обусловлено, в первую очередь, различными требованиями к нему со стороны решаемых задач, аппаратной организации, либо политики доступа. Подобные различия удобно привести на примере проектов Globus Toolkit и gLite. ПО gLite разработано Европейским советом по ядерным исследованиям и частично основано на ПО Globus Toolkit, которое является одним из старейших ПО этого класса. Несмотря на общие корни, программные продукты имеют существенные отличия. gLite предоставляет полную инфраструктуру из компонентов всех уровней: от комплексного подхода к организации доступа групп пользователей до собственного менеджера нагрузки (англ. Workload manager/WLM, в терминах gLite) на вычислительных узлах (англ. Computing Element, CE). Это ограничивает универсальность архитектуры конечной грид-системы. Такое решение обусловлено тем, что gLite создаётся прежде всего в рамках инициатив Европейского совета по ядерным исследованиям и выпускаемый продукт ориентирован для тесной интеграции с проектами ЦЕРН. Это во многом обусловливает тот факт, что в самой минимальной конфигурации gLite менее эффективен, чем Globus Toolkit. Главным отличием Globus Toolkit является свобода выбора компонентов промежуточного ПО, что позволяет точнее подойти к вопросу о необходимости тех или иных функций, что способно значительно сократить сложность использования и накладные расходы на запуск задач. Кроме того, последние версии Globus Toolkit имеют обширную и подробную документацию всех уровней – от установки до использования. Необходимо отметить, что gLite, являясь продуктом ЦЕРН, разрабатывается исключительно для Red Hat Enterprise Linux-основанных сборок (CentOS и Scientific Linux), а Globus Toolkit доступен так же и для ряда других крупных дистрибутивов, например Debian или Slackware.
Следующим витком в развитии ПО для грид стало ПО, способное гибко аггрегировать несколько грид-узлов и/или кластеров, являясь «метаплани-ровщиком». Примером такого ПО может служить Gridway или EGEE WMS (поглощено gLite)[62]. Метапланировщик принимает задания от пользователя, проверяет состояние подключенных к нему грид-систем и кластеров и отправляет задание (целиком или частично) на доступные и подходящие. Кроме этого, он берёт на себя проблемы доставки данных на грид-системы и кластеры, а так же отслеживание процесса выполнения задачи. Подключенные грид-системы и кластеры не утрачивают возможности выполнять задания, отправленные непосредственно на них без использования метаплани-ровщика.
Кластеры, в свою очередь, имеют собственные системы очередей и системы централизованного запуска. Типичными представителями таких систем являются ПО TORQUE[63][64] или ПО Condor (ныне HTCondor[64]. Эти системы работают в рамках кластера и подразумевают исключительный контроль над вычислительными ресурсами. Таким образом, запускать задачи на кластере допустимо только через подобную систему. На данный момент большинство кластеров работают под управлением различных вариантов менеджеров ресурсов, предпосылки к использованию которых приведены ниже. Для выполнения расчётов на каждом узле запускается свой экземпляр исполняемого кода, которому даётся соответствующий ему набор входных данных. Очевидно, что в случае, если узлов много, становится актуальным вопрос об автоматизации запусков. Кроме большого количества машин ещё одну сложность представляет большое количество пользователей, т.к. одновременное выполнение различных задач одной машиной в большинстве случаев приводит к увеличению времени выполнения всех задач. Система управления ресурсами управляет вычислительной нагрузкой путём предотвращения возникновения «гонки» за ограниченные вычислительные ресурсы. Обычно система управления ресурсами состоит из менеджера ресурсов, а так же планировщика задач. Большинство систем управления имеют встроенный планировщик, но многие системы допускают использование внешнего. В обоих случаях планировщик получает информацию об очередях, нагрузке на вычислительные узлы и доступных ресурсах для принятия решения. В большинстве реализаций система управления вычислительными ресурсами выполняется на головном узле, а так же на всех вычислительных узлах и обслуживает очередь, посредством которой пользователи могут отправлять и удалять свои задания, а так же получать информацию об их состоянии
Опыт создания портативной автономной сейсмологической станции, работающей по протоколу реального времени
Идея технологии основана на использовании понятия апостериорной функции распределения (АПФР) вероятности. Как уже отмечалось выше, точное определение параметров модели по имеющимся данным наблюдения не только не всегда возможно, но и часто просто бессмысленно. Поэтому моделирование можно рассматривать как реализацию случайного процесса, и вероятность того, что параметры модели, адекватно описывающие наблюдаемую систему, имеют некоторое фиксированное значение, определяется АПФР. Таким образом, задача сводится к определению этой функции, что позволит оценить качество решения, рассчитывать маргинальные оценки, выявлять и интерпретировать мультимодальные распределения. Такой подход был реализован для задачи определения параметров сейсмической анизотропии коры и верхней мантии по данным телесейсмических наблюдений. С вычислительной точки зрения цель проводимых вычислений - табуляция функции р переменных на прямоугольной сетке в р-мерном гиперпространстве. Для каждого из варьируемых параметров заданы его минимальное xmin, максимальное хтах значения, а также величина шага Ах .Таким образом, область определения каждой из переменных разбивается на
Применительно к организации вычислений, можно суммировать следующее: полное время вычислений равно сумме времен расчета каждого узла и накладных расходов на запуск задачи (ввод-вывод, постановка в очередь и прочее) время расчета одной модели невелико - порядка 0.1 секунды; основные временные затраты связаны с количеством расчетных точек, чье число катастрофически возрастает с усложнением модели (увеличением числа слоев). Последнее известно как «проклятье размерности»[ ], и, кроме разработки новых методов решения, справиться с этой проблемой позволяют высокопроизводительные системы. 1.3.2 Программное решение
Прикладной компонент «Определение параметров анизотропии по волновым формам» разработан в рамках этой работы первым приложением. Его реализация позволяет пользователю произвести расчеты аналогично [26], но без использования специфических знаний о грид-системах и высокопроизводительных системах вообще. Пользователь взаимодействует с минималистичным интерфейсом, а так же получает доступ к средствам визуализации. Процесс запуска описан в пункте . Для сбора результатов используется отвязанный от промежуточного ПО механизм динамически создаваемых экземпляров СУБД, который описан ниже.
В момент создания вычислительного проекта (набора параметров с исходными данными) обслуживающее приложение создаёт новую базу данных и запускает экземпляр СУБД для неё. Затем управляющее приложение создаёт первичную структуру в ней, после чего запущенный экземпляр ждёт заполнения данными. В процессе вычислений «рабочий процесс» соединяется с определённым экземпляром СУБД и передаёт результаты.
В качестве СУБД используется ПОMariaDB, вариант MySQL. Важной особенностью платформы интеграции является динамическое создание экзем 70 пляров СУБД для расчётных задач. Это позволяет изолированно от других процессов использовать СУБД исключительно для целей расчётной задачи. Достоинством этого метода является возможность сохранять данные на любых других компьютерах - достаточно, что бы на них работало обслуживающее приложение и компьютер обладал необходимыми для хранения и работы с данными ресурсами.
Данные сохраняются как N(p, г), где N - номер модели,/? - параметры и г - значения целевых функций, т.е. таблица имеет несколько колонок и большое количество строк (миллионы и десятки миллионов). Для ускорения доступа к данным в базе данных результатов применяются индексы. Индексы в MariaDB используются для быстрого поиска рядов с определёнными значениями определённых колонок. В отсутствие индексов MariaDB начнёт просматривать таблицу начиная с первого и до последнего ряда. Чем больше таблица - тем больше потребуется времени. Если таблица имеет индекс для одной из колонок, по которым заданы ограничения, то MariaDB сможет быстро обнаружить необходимый ряд без просмотра всей таблицы. Несмотря на это преимущество использование индекса не всегда оправдано - возможны ситуации, когда просмотр всей таблицы выполняется быстрее просмотра индекса и просмотра участка таблицы. Кроме быстрого поиска значений MariaDB использует индексы для следующих операций: исключение неискомых рядов из поиска, операций объединения данных из разных таблиц, быстрого получения минимального и максимального значения в колонке, а так же для сортировки данных таблицы. В MariaDB существует несколько типов индексов, каждый из которых даёт преимущество при определённых условиях. В большинстве случаев, когда не упоминается какой-то конкретный тип индексов, имеется ввиду Bree индекс (Рисунок 4). Этот тип индексов, как можно заметить, использует Б-деревья для хранения своих данных. Б-дерево – это дерево поиска, в котором поиск, последовательный доступ, вставки и удаления производятся сравнительно быстро. Следуя природе Б-дерева особенностью индекса на Б-деревьях является то, что все значения записаны по порядку и все терминальные вершины дерева одинаково удалены от корня. Для поиска данных СУБД начинает просмотр с корня дерева, затем поиск переходит в одну из ветвей исходя из указанных для этой ветви верхней и нижней границе данных. Таким образом СУБД достигает терминальной вершины. Терминальныевершины отличаютсяответвей тем, что содержат указатели не на другие ветви индекса, а на сами данные, где СУБД выбирает искомые строки простым перебором, однако, границы перебора значительно сокращены[68, с. 77]. СУБД MariaDB так же поддержи-ваетидругие схемы организации индексов, однаковрамках данного раздела рассматривается лишь необходимость их использования в целом.
Использование технологий виртуальных частных сетей для сбора данных оперативных систем геофизических наблюдений
В этом случае для доступа к локальным компьютерам извне необходимо предпринимать специальные усилия по настройке NAT-сервера. Как правило, такая процедура затруднительна или, например, при использовании сотовых сетей, практически исключена. Использование технологии динамической системы доменных имен (см., например, [77]) также не дает универсального решения проблемы, поскольку требует наличия у регистратора реального IP-адреса. По существу, единственное универсальное решение возможно лишь на основе организации выделенного канала внутри Интернет соединения. Речь идет о создании так называемой виртуальной частной сети (VPN, Virtual Private Network), которая позволяет не только осуществлять двусторонне взаимодействие между произвольными компьютерами, в том числе и размещенными за NAT-серверами, но и попутно решает вторую задачу – защиту передаваемых данных от несанкционированного доступа. Это достигается за счет использования шифрования, аутентификации, инфраструктуры открытых ключей и других средств защиты. Так как VPN-соединение обеспечивает двунаправленную связь между сервером и клиентом, то в интересующих нас системах регистрации, помимо собственно передачи информации в центр сбора, хранения и обработки данных, наличие VPN-канала позволяет осуществлять удаленное администрирование, наладку и обслуживание приемного оборудования. Такой подход существенно снижает время реагирования на аварийные ситуации, а также сокращает расходы на командировки и привлечение дополнительного персонала в удаленных пунктах регистрации. Основное требование при построении сети устройств с оперативной регистрации - установка гарантированного соединения без необходимости локального администрирования. Кроме того, предпочтителен выбор решения, не требующего дополнительных затрат на приобретение специализированного программного обеспечения. Фактически это означает выбор между двумя реализациями VPN-технологии: встроенный в операционную систему Microsoft Windows протокол SSTP (Secure Socket Tunneling Protocol) и открытое кросс-платформенное решение - OpenVPN[78]. Оба этих решения допускают организацию канала по порту TCP 443, что гарантирует возможность установления связи VPN-клиента с сервером, в том числе и при достаточно строгой политике безопасности, принятой в локальной сети со стороны клиента.
Виртуальная частная сеть - как на базе протокола SSTP, так и с использованием OpenVPN - основана на двух компонентах: средстве сопряжения с сетевым стеком операционной системы и SSL-сессии между шлюзом и клиентом. Средства сопряжения «внедряют» пакеты виртуальной сети в сетевой стек операционной системы. Отличительная особенность рассматриваемых решений - отсутствие необходимости использования специальных типов соединений, прохождение которых через серверы NAT и брандмауэры не гарантировано. Вместо этого используется стандартное TCP-соединение на основе защищенной сессии SSL (Secure Sockets Layer), внутри которой передаются пакеты виртуальной частной сети. Именно использование TCP и обеспечивает работоспособность как SSTP, так и OpenVPN в сетях с NAT [79]. Отличия между протоколами заключаются в деталях организации передачи данных внутри SSL-сессии. К сожалению, гарантия возможности установления соединения приводит к ухудшению некоторых других характеристик, особенно в нестабильных каналах с большим количеством потерь и задержек передачи пакетов. Во-первых, использование TCP-канала «встроенного» в другой TCP-канал увеличивает накладные расходы на передачу данных. Во-вторых, при высоком уровне задержек и потерь в канале может произойти явление так называемого «TCP-перегрева» (TCP meltdown). Термин впервые был введен в работе [80].
В общих чертах процесс выглядит следующим образом: при обнаружении потерь транспортный уровень, обеспечивающий работу туннеля, должен повторить передачу утраченного пакета. Если этого не произошло в пределах времени ожидания RTO (Retransmission Timeout), то процесс ретрансмиссии повторяется снова. В то же время, транспортный уровень внутри туннеля обнаруживает потерю и инициирует собственные процедуры ретрансмиссии. Это приводит к лавинообразному заполнению пропускной способности канала, вплоть до разрыва внутреннего TCP-соединения из-за невозможности выполнить передачу вовремя. В конечном счете, взаимодействие этих факторов, по сути, определяет возможность использование канала, так как увеличение трафика увеличивает вероятность «TCP-перегрева», т.е. непосредственно определяет пропускную способность. Поэтому было проведено тестирование двух видов. В первом случае сравнивалась передача данных в условиях, приближенных к реальным, во втором с помощью специально собранной виртуальной лаборатории исследовалась работа канала в условиях контролируемых помех.
