Лучше один раз измерить, чем сто раз гадать
Сергей Юдицкий, Владислав Борисенко, Петр Адаскин
Если возможности имеющихся в вашем распоряжении диагностических средств не
позволяют определить причину сбоев в сети, то следует воспользоваться
методом активного тестирования сети.
Если пользователи сети жалуются, что приложения работают медленно,
периодически сбоят, а одну и ту же работу приходится выполнять по
несколько раз, то это означает, что пора проводить тестирование. Главный
вопрос, на который предстоит ответить администратору сети, состоит в
следующем: «В чем причина медленной работы пользовательских приложений — в
«узких местах» или дефектах сети, либо же в неправильной настройке или
недостатках самих пользовательских приложений?» (Под термином «сеть» мы
будем понимать все компоненты сети в комплексе: пассивное сетевое
оборудование — кабель, розетки, панели переключений; активное сетевое
оборудование — коммутаторы, маршрутизаторы, а также рабочие станции и
серверы сети с установленными на них сетевыми ОС.)
Возможны два подхода к решению данной задачи. Первый подход —
«эмпирический», в настоящее время он доминирует в России. В соответствии с
этим подходом администраторы сети пытаются решить проблему, руководствуясь
только интуицией и здравым смыслом. Одни осуществляют замену сетевого
оборудования, особо не задумываясь при этом, действительно ли именно
оборудование «виновато» в медленной работе приложений. Другие начинают
производить различные изменения в топологии или архитектуре сети,
устанавливают или убирают поддержку различных протоколов, меняют форматы
кадров, изменяют параметры настройки прикладного ПО, оборудования или ОС.
Третьи просто уходят от проблемы, перекладывая решение задачи на компанию,
которая устанавливала сеть или прикладное ПО. Однако в общем случае ни
один из этих способов не гарантирует решения проблемы.
Второй подход основан на поиске причин медленной работы приложений с
помощью различных диагностических средств. Данный подход пока не очень
распространен в России. И причина этого состоит, вероятно, в том, что
«психологически» значительно проще истратить несколько тысяч долларов США
на новое оборудование, чем на диагностическое средство (особенно
программное), и уж тем более на услуги по диагностике сети. В результате
диагностические средства для решения конкретных задач используют, как
правило, только в тех случаях, когда «эмпирический» подход оказался
нерезультативным, и другого выхода просто нет.
И даже когда компания в результате неудач «эмпирической» модернизации
сети, казалось бы, должна была осознать необходимость продуманного
профессионального подхода к приобретению новых средств, стратегия многих
компаний в отношении диагностических средств часто удивляет своей
иррациональностью. Вместо выяснения того, какое диагностическое средство
для решения какого типа задачи предназначено, многие компании при его
выборе руководствуются принципами «как у соседа» или «где дешевле». Так,
одни компании выбрасывают десятки тысяч долларов на престижные системы
управления сетью. Однако при всех своих достоинствах такие системы
оказываются зачастую неэффективными для решения специфических задач
диагностики сети, а кроме того, требуют приобретения дополнительных зондов
или специализированных приложений, стоимость которых немногим меньше
стоимости самой системы управления. Другие же приобретают «игрушечные
средства», которые в принципе не предназначены для решения сложных задач и
поэтому оказываются малоэффективными.
Традиционная методология диагностики сети и ее ограничения
Традиционными средствами диагностики сети являются анализаторы сетевых
протоколов и программы на основе SNMP с поддержкой RMON1/RMON2. Для
краткости мы будем называть их пассивными средствами диагностики. Методика
использования пассивных средств основана на анализе сетевого трафика.
Анализируя и декодируя сетевой трафик, эти средства позволяют выявить
симптомы медленной работы приложений. Мы достаточно подробно рассмотрели
такие симптомы в наших предыдущих статьях (см. статьи по диагностике в
предыдущих номерах LAN). Однако чтобы лучше понимать проблематику поиска
дефектов и «узких мест» в сети, мы хотели бы все же сказать несколько слов
о методологии процесса диагностики сети с помощью пассивных средств.
Поиск дефектов и «узких мест» сети с помощью пассивных средств диагностики
можно охарактеризовать как поиск «от противного». Это означает, что о
качестве работы сети судят по отсутствию симптомов дефектов. Так,
например, как известно, доля искаженных кадров не должна превышать 1% от
общего числа кадров. Поэтому вы измеряете, сколько в вашей сети искаженных
кадров. Кроме того, число широковещательных и групповых кадров в сети не
должно превосходить 8—10% от общего числа кадров, и поэтому вы измеряете,
какова их доля в вашей сети. Далее, утилизация канала разделяемой сети
Ethernet не должна быть больше ~35%, и поэтому вы измеряете значение этого
параметра. Перечень симптомов можно продолжить и далее.
Очевидно, что эффективность метода «от противного» зависит от двух
основных факторов.
Фактор №1. Возможности используемого диагностического средства по фиксации
симптомов проблем. Чем больше симптомов может выявить диагностическое
средство и чем больше компонентов сети им охватывается, тем оно
эффективней.
Например, эффективность диагностического средства зависит от того, какие
типы ошибок при передаче данных позволяет обнаружить диагностическое
средство и все ли кадры оно перехватывает при высокой загруженности сети;
от его способности фиксировать сбои в полнодуплексных каналах связи, а
также сбои или перегрузку конкретных систем сервера (например, сетевой
платы) и рабочих станций, видеть не только искаженные кадры, но и шум в
линии связи, определять число повторных передач на транспортном уровне
сети, время реакции каждого узла сети, факты перегрузки сервера.
Очевидно, что самая дорогая система на базе SNMP будет бесполезна, если в
сети отсутствуют зонды SNMP/RMON или если они контролируют только
незначительную часть сети, например только центральный коммутатор.
Очевидно также, что анализатор сетевых протоколов не позволит со
100-процентной вероятностью локализовать дефект, если он не способен
фиксировать симптомы дефектов на транспортном уровне сети.
Фактор №2. Умение администратора сети правильно интерпретировать
получаемую с помощью диагностического средства информацию.
Если диагностическое средство позволяет фиксировать несколько десятков
характеристик работы сети, а администратор сети следит только за
утилизацией портов коммутатора и долей искаженных кадров, то вряд ли это
можно назвать эффективным использованием диагностического средства.
Очевидно, что чем большими возможностями обладает диагностическое
средство, тем оно дороже. Стоимость средств для сбора полной информации о
работе сети составляет сумму в диапазоне от 15 000 до 25 000 долларов, не
считая стоимости экспертной системы. Вывод же о своем умении
интерпретировать характеристики работы сети мы предлагаем каждому читателю
сделать самостоятельно.
Иметь дорогое многофункциональное диагностическое средство лучше, чем его
не иметь. Так же, как «лучше быть здоровым и богатым, чем бедным и
больным». Однако, приобретая диагностическое средство, вам следует
проанализировать не только его потенциальные возможности, но и то,
насколько эффективно оно может быть использовано именно в вашей сети.
Например, оно может быть эффективно использовано для работы только с
определенным типом оборудования и таким образом потребует замены большей
части активного сетевого оборудования или закупки автономных аппаратных
зондов RMON.
Благодаря удобству использования средства пассивной диагностики (метод «от
противного») являются основным инструментом для локализации дефектов и
«узких мест» сети. С их помощью администратор сети, не сходя со своего
рабочего места, может наблюдать за всеми процессами в сети. Однако это
далеко не единственная причина.
Скрытые и явные дефекты в локальных сетях
Все многообразие дефектов в локальных сетях можно условно разделить на две
категории: «скрытые» и «явные». К категории «явных» относятся дефекты,
следствием которых является искажение кадров в процессе их передачи по
сети. Дефекты, относящиеся к категории «скрытых», замедляют работу сети,
но не вызывают появления искаженных кадров.
Основной причиной искажения кадров в сети являются дефекты пассивного
сетевого оборудования и некоторые неисправности приемо-передающих модулей
активного сетевого оборудования. По разным оценкам, доля дефектов только
пассивного сетевого оборудования составляет от 65 до 85%. В отличие от
скрытых, явные дефекты сети достаточно просто обнаружить с помощью средств
пассивной диагностики. Для этого все проходящие по сети кадры достаточно
проанализировать на предмет наличия в них искажений. Именно преобладание
дефектов пассивного сетевого оборудования над другими дефектами сети
является одной из причин того, что средства пассивной диагностики
оказываются основным инструментом для локализации дефектов сети.
Тенденция развития сетевых технологий такова, что относительная доля явных
дефектов постоянно снижается. С одной стороны, это вызвано переходом с
коаксиального кабеля на витую пару и оптику, что повышает
помехоустойчивость каналов передачи информации. С другой стороны, активное
сетевое оборудование становится все более сложным, и это повышает
вероятность появления в нем «скрытых дефектов». Вот несколько примеров
наиболее распространенных «скрытых дефектов» сети.
«Сетевая плата плохо слышит паузу». Одним из широко распространенных
недостатков сетевых плат является дефект, когда датчик паузы в сетевой
плате настроен на время, несколько большее, чем 9,6 мкс (для Ethernet). В
этом случае, при наличии нескольких активных станций, станция с такой
сетевой платой будет ждать более длинной паузы и, следовательно, уступать
канал всем остальным станциям, когда те одновременно с ней хотят
передавать данные. Свои кадры «глухая» станция будет передавать только в
те моменты, когда ни одна другая станция коллизионного домена не имеет
кадров для передачи. В результате «глухая станция» будет работать
медленней всех остальных станций, однако никаких искаженных кадров в сети
не появится.
«Искажение информации после проверки контрольной последовательности CRC».
Этот недостаток может встречаться в любом активном сетевом оборудовании и
заключается в том, что искажение информации происходит уже после ее приема
из сети и проверки CRC. Предположим, что сетевая плата или коммутатор
принимает кадр из сети, проверяет поле CRC и, не обнаружив ошибки,
передает данные драйверу. Если из-за какой-либо ошибки, например дефекта
приемного буфера сетевой платы, данные окажутся искажены, то такое
искажение информации может остаться незамеченным сетевой ОС (при
отсутствии проверки контрольной суммы на транспортном уровне). Как и в
предыдущем случае, никаких искаженных кадров в сети не появится.
«Скрытые дефекты» в микропрограммном обеспечении коммутаторов». Недостатки
в микропрограммном обеспечении коммутаторов приводят к удалению кадров из
обращения при высокой пиковой нагрузке или к взаимной блокировке портов
(высокая пиковая загрузка одного порта вызывает блокировку другого порта).
Разработчики пассивных средств диагностики отреагировали на тенденцию
увеличения доли «скрытых дефектов» выпуском экспертных систем для
обнаружения симптомов «скрытых дефектов». Первой это сделала компания
Network General (сейчас Network Associates) в анализаторе протоколов
Sniffer, обеспечив себе в течение двух лет доминирующую позицию на рынке
анализаторов протоколов. Затем в гонку вступила компания Hewlett-Packard с
продуктом LAN Internetwork Advisor, а вслед за ней компания Wandel &
Goltermann (сейчас Wavetek Wandel Goltermann) с продуктом Mentor. Сегодня
все серьезные игроки на рынке диагностических средств предлагают
экспертные системы в качестве интегральной составляющей анализатора
сетевых протоколов или дополнительной опции. Таким образом, экспертная
система становится обязательным атрибутом для эффективной диагностики
сети, что иногда очень существенно удорожает стоимость диагностического
средства.
Какие выводы можно сделать на основании измерений числа искаженных кадров
и утилизации сети
В настоящее время в России наличие экспертной системы у администратора
сети является скорее исключением, чем правилом. Большинство
администраторов сетей делают выводы о наличии дефектов и «узких мест» в
сети только на основании простейших наблюдений за работой сети. Чаще всего
это измерения утилизации сети и доли искаженных кадров. Чтобы лучше
представлять, какие выводы можно, а какие нельзя сделать на основании
измерения утилизации сети и доли искаженных кадров, мы рассмотрим в
качестве примера фрагмент упрощенной модели некоторой сети (см. Рисунок
1).
Рисунок 1. Изображенный фрагмент сети можно условно
представить в виде пяти взаимосвязанных компонентов:
рабочей станции, коллизионного домена А, коммутатора,
коллизионного домена В, сервера.
Изображенный на Рисунке 1 фрагмент сети состоит из пяти взаимосвязанных
компонентов: рабочей станции, коллизионного домена А, коммутатора,
коллизионного домена В, сервера. Каждый коллизионный домен может
представлять собой концентратор вместе с кабельной системой (как в домене
А) или только полу/полнодуплексное соединение между рабочей
станцией/сервером и коммутатором (как в домене В). При этом большинство
компонентов сами являются сложными системами.
Так, рабочая станция состоит, как минимум, из двух взаимосвязанных систем:
вычислительной платформы и сетевого интерфейса (см. Таблицу). Коммутатор —
из трех взаимосвязанных систем: сетевого интерфейса А, вычислительной
платформы и сетевого интерфейса В. Сервер — также из трех взаимосвязанных
систем: сетевого интерфейса, вычислительной платформы и дисковой системы.
Каждая из перечисленных систем состоит из нескольких подсистем. Каждая
подсистема может быть потенциальным «узким местом» сети или носителем
дефекта. В Таблице показаны 23 такие подсистемы (от 1а до 10с).
Компонент сетиСистема сетиПодсистема сети
СерверДисковая системаДиски10С
КаналВ
Приемо-передающий буферыА
Вычислительная платформаПроцессор9С
ОЗУВ
Системная шинаА
Сетевой интерфейсПриемо-передающий буферы8С
Системное ПО стека протоколаВ
Сетевая платаА
Коллизиционный домен ВКабельная система7
КоммутаторСетевой интерфейс В 6
ПлатформаПриемо-передающий буферы5С
ПО (микропрограммное обеспечение)В
Внутренняя магистраль или матрицаА
Сетевой интерфейс А 4
Коллизиционный домен АКабельная система3В
КонцентраторА
Рабочая станцияСетевой интерфейсСетевая плата2С
Приемо-передающий буферыВ
Системное ПО стека протоколовА
Вычислительная платформаСистемная шина1С
ОЗУВ
ПроцессорА
Системы и подсистемы фрагмента сети, изображенного на Рисунке 1.
Практически каждая подсистема
может быть потенциальным «узким местом» или источником дефекта.
Утверждение №1. При отсутствии или незначительном числе искаженных кадров
в сети достоверные выводы можно делать только об отсутствии дефектов в
аппаратуре коллизионных доменов сети. В Таблице — это подсистемы 3а, 3b,
7. При этом делать вывод об отсутствии «скрытых дефектов» в остальных
компонентах сети нельзя.
Даже при наличии в сети определенного количества искаженных кадров их
влияние на работу пользовательских приложений не следует переоценивать.
Если кабельная система сети была протестирована, искаженные кадры следует
рассматривать, в первую очередь, как симптомы других, более опасных
дефектов активного оборудования. В большинстве сетей, диагностику которых
мы проводили, доля искаженных кадров редко превышала один процент от
общего числа кадров. При этом очень часто сеть имела серьезные дефекты,
наличие которых существенно замедляло работу пользовательских приложений.
Утверждение №2. Если утилизация коллизионных доменов (или портов
коммутатора) и процессора сервера низкая, то это еще не означает
отсутствие в сети «узких мест».
Если глубоко не вдаваться в детали и, в частности, не рассматривать
проблему скрытых «узких мест», то для неискушенного взгляда локализация
«узкого места» сети представляется относительно простой задачей.
«Узким местом» сети называют обычно ресурс сети с наименьшей пропускной
способностью и, следовательно, — с наибольшей загрузкой. Поэтому, измерив
утилизацию (степень загрузки) всех ресурсов, вы можете определить наиболее
загруженный ресурс. Однако все на самом деле не так просто, здесь мы
должны учитывать целый ряд факторов.
Фактор №1. Работа всех систем сети взаимосвязана. Наличие хотя бы одной
перегруженной системы влияет на максимальную утилизацию других систем
сети.
Например, перегруженная платформа рабочей станции (система 1 в Таблице)
ограничивает максимальную утилизацию коллизионного домена А (система 3).
Перегруженная дисковая система сервера (система 10) ограничивает
максимальную утилизацию сетевого интерфейса сервера (система 8),
перегруженная платформа коммутатора — максимальную утилизацию всех систем
рабочей станции и сервера и т. д. Поэтому, чтобы локализовать «узкое
место» сети, утилизацию всех систем сети требуется измерить в одном
временном разрезе. В общем случае анализ только загрузки процессора
сервера и коллизионных доменов сети недостаточен для выяснения того, в чем
причина низкой загруженности этих систем — в низкой загруженности сети или
перегруженности каких-то других систем сети.
Фактор №2. Загрузку ряда систем сети сложно измерить.
Если утилизацию коллизионных доменов (системы 3 и 7) и процессора сервера
(система 9) измерить достаточно просто, то утилизацию остальных систем
измерить не всегда возможно. Особые сложности могут возникнуть при оценке
утилизации платформы коммутатора и сетевого интерфейса сервера. Подобное
измерение можно провести только в том случае, если это позволяют
возможности активного оборудования. Например, утилизацию сетевого
интерфейса сервера можно измерить только при наличии на сетевой плате
сервера специального встроенного SNMP-агента (как это сделано, например, в
сетевой плате Intel PRO/100+ Server Adapter).
Однако даже при наличии средств для измерения утилизации всех основных
систем сети попытка увидеть измеренные значения в едином временном разрезе
может натолкнуться на значительные препятствия. Основные выводы, которые
мы хотим сделать, заключаются в следующем.
Эффективность пассивных средств диагностики очень существенно зависит от
архитектуры диагностируемой сети и от возможностей активного
оборудования по предоставлению информации, характеризующей его работу.
Для локализации всех дефектов и «узких мест» сети проведение измерений
только утилизации сети и доли искаженных кадров может оказаться
недостаточно.
Теперь самое время вернуться к задаче, которую мы сформулировали в начале
статьи: как с помощью пассивных средств диагностики определить, почему
пользовательские приложения работают медленно или сбоят?
Традиционно данную задачу принято решать с помощью анализатора сетевых
протоколов с поддержкой декодирования всех протоколов, включая протоколы
прикладного уровня, и «умной» экспертной системы с возможностью выявления
симптомов не только «скрытых дефектов» и перегрузки сервера, но и
неэффективной работы пользовательских приложений. Примерами таких средств
являются аппаратные анализаторы серии Domino и экспертная система Mentor
компании Wavetek Wandel Goltermann, а также HP LAN Internetwork Advisor.
Такой путь вполне реален и практичен, если пользовательские приложения
вашей сети работают со стандартными прикладными протоколами, например,
если пользовательские приложения написаны на Oracle, Sybase и т. п. Однако
в России доля приложений на базе стандартных прикладных протоколов
незначительна, как и число компаний, которые могут позволить себе
приобрести диагностическое средство стоимостью около 25 000 долларов.
Однако данную задачу можно попытаться решить другим, несколько более
«дешевым» способом. Естественно предположить, что если дефекты и «узкие
места» в сети отсутствуют, то приложения должны работать быстро и
устойчиво. Если в процессе диагностики сети вы достоверно определите, что
в сети нет «скрытых дефектов» и «узких мест», значит «виноваты»
пользовательские приложения. Теоретически эту задачу можно решить,
используя менее дорогие, чем в первом случае, средства диагностики. Однако
для этого необходимо наличие, как минимум, четырех составляющих.
Во-первых, анализатор сетевых протоколов с поддержкой декодирования всех
протоколов до транспортного уровня включительно и «умная» экспертная
система для выявления «скрытых дефектов» сети. Примером такого анализатора
протоколов и экспертной системы могут служить, например, Observer v.6.1 и
Expert Extension компании Network Instruments. Во-вторых, программы на
базе SNMP (например, SNMP Extension и RMON Extension компании Network
Instruments) для сбора информации от встроенных в активное оборудование
зондов RMON. В-третьих, и это особенно важно, зонды RMON на всех
компонентах тракта «рабочая станция—сервер» (см. Таблицу). В-четвертых,
эксперт, который сможет правильно интерпретировать полученные с помощью
этих средств результаты. Третий способ решения поставленной задачи
заключается в сочетании метода пассивной диагностики и метода активного
тестирования сети. Он предполагает наличие относительно недорогого
анализатора сетевых протоколов или программы на базе SNMP и специальных
тестов для измерения скорости работы сети. Если в качестве критерия
эффективности рассматривать «оперативность решения задачи/(стоимость *
сложность)», то, с нашей точки зрения, данный способ является наиболее
эффективным. Его-то мы и собираемся рассмотреть более подробно.
Метод активного тестирования расширяет возможности средств пассивной
диагностики
Метод активного тестирования сети состоит в том, что выводы о наличии в
сети «скрытых дефектов» и «узких мест» делаются не только в результате
пассивного наблюдения за работой сети, но и на основании измерений
скорости работы сети в процессе ее эксплуатации.
Методология активного тестирования в чем-то аналогична поиску
неисправностей в электронном устройстве. Профессиональный электронщик
редко ограничивается методом «от противного». Поиск неисправностей обычно
только начинается с проверки наличия или отсутствия сигналов в неких
опорных точках (метод «от противного»). При отсутствии результата
первичной проверки электронщик, как правило, устанавливает генератор
сигналов или запускает тестовую программу и, в соответствии с
принципиальной электрической схемой устройства, проверяет прохождение
сигналов по всем цепям. Другими словами, зная, как устройство должно
работать, он проверяет, как оно реально работает. А это уже не метод «от
противного», а метод активного тестирования. Давайте задумаемся, что дает
метод активного тестирования применительно к диагностике сетей. На самом
деле, измеряя такие характеристики работы сети, как утилизация сети и
сервера, число ошибок на канальном и транспортном уровне, доля
широковещательных кадров и многое другое, мы прежде всего думаем о том,
какое влияние все эти характеристики оказывают на скорость работы сети.
Другими словами, все измеряемые пассивными средствами диагностики
характеристики являются, по сути, косвенными признаками того, как работает
сеть. Основным же или «прямым» показателем состояния сети служит именно
скорость сети, т. е. то, как быстро сеть обрабатывает заявки
пользовательских приложений. Поэтому зная, с какой скоростью сеть должна
работать, и измерив, как сеть реально работает, мы можем сделать выводы о
факте наличия в сети дефектов или «узких мест». После этого более
детальная локализация дефектов и «узких мест» осуществляется средствами
пассивной диагностики.
Как измерить скорость сети? Это не столь тривиальная задача, как может
показаться на первый взгляд. Тестовое приложение для измерения скорости
сети должно удовлетворять следующим основным требованиям.
Требование №1. Тестовое приложение должно измерять реальную скорость сети.
В частности, измеряемые значения скорости не должны зависеть от объема
кэш-памяти компьютера, где оно выполняется. Иначе измеренные значения
будут недостоверны.
Требование №2. Тестовое приложение должно тестировать весь тракт «рабочая
станция—сервер», начиная от вычислительной платформы рабочей станции
(система 1 в Таблице) и заканчивая дисковой системой сервера (система 10 в
Таблице). Другими словами, наличие «скрытого дефекта» или «узкого места» в
любой системе тракта «рабочая станция—сервер» не должно остаться
незамеченным для тестового приложения.
Требование №3. Тестовое приложение должно быть таким, чтобы в случае
наличия дефекта или «узкого места» в любой системе тракта «рабочая
станция—сервер» оно позволяло локализовать источник проблемы.
Требование №4. Работа тестового приложения не должна существенным образом
сказываться на функционировании пользовательских приложений в сети.
Другими словами, тестовое приложение должно оказывать как можно меньше
влияния на работу всех систем сети, за исключением компьютеров, на которых
оно выполняется.
«Скорость сети» следует отличать от «пропускной способности сети». Под
пропускной способностью сети (throughput) принято понимать максимальный
объем данных, который сеть может передать за фиксированный промежуток
времени. Под скоростью сети в данной статье мы будем понимать скорость
выполнения файловых операций. Скорость выполнения файловой операции
получается при делении длины дисковой записи (в килобайтах) на время ее
чтения/записи (в секундах). Полученные значения усредняются за заданный
временной интервал. Таким образом, под скоростью сети мы будем понимать
время реакции сети при выполнении файловых операций.
Выбор именно файловых операций обусловлен следующим. Файловые операции
являются наиболее распространенным типом операций прикладного уровня сети.
Большинство используемых в России приложений базируется именно на файловых
операциях. Кроме того, анализ скорости выполнения файловых операций числа
ошибок прикладного уровня проверяет функционирование всего стека
протоколов на рабочей станции и сервере, а также всех систем тракта
«рабочая станция—сервер», в том числе, что особенно важно, дисковой
системы сервера (Требование №2). Далее, если скорость выполнения файловых
операций недопустимо низкая или наблюдаются ее «провалы», то причину этого
определить легко, так как в качестве транспортного протокола при файловых
операциях чаще всего используются TCP/IP, IPX/SPX, NetBEUI, а эти
протоколы дешифруются практически всеми анализаторами сетевых протоколов
(Требование №3).
Рисунок 2. Информация о текущей скорости сети, измеряемая агентом
пакета FTest. График показывает изменение скорости выполнения
файловых операций чтения и записи (Read/Write Rates) с усреднением
за пятисекундный интервал времени. Интервал усреднения может быть
задан произвольным. Минимальный интервал равен одной секунде.
Многие могут справедливо возразить, что в общем случае «скорость сети» и
«скорость выполнения файловых операций в сети»