Динамическая миграция на устройствах GPU-P

В этой статье описывается функциональная структура динамической миграции разнородных вычислительных устройств (GPU, NPUs и т. д.), виртуализированных с помощью секционирования SR-IOV (виртуализация единого корневого ввода-вывода). Устройства, поддерживающие секционирование через модели драйверов WDDM и MCDM, теперь являются неотъемлемой частью наших предложений виртуализации. Таким образом, важно поддерживать динамическую миграцию и помочь нашим абстракциям виртуализации стать максимально надежными для воздействия на клиентов при изменении назначений ресурсов. В этой статье также описывается быстрая миграция этих устройств.

Динамическая миграция поддерживается начиная с Windows 11 версии 24H2 (WDDM 3.2). Как правило, это расширение DDIS паравиртуализации GPU (GPU-P) для драйверов, которые предоставляют возможности. Драйверы MCDM, реализующие интерфейсы виртуализации GPU-P, могут также реализовать эти динамические интерфейсы миграции, включая их расширение с событиями обработки.

В этой статье "GPU" просто относится к устройствам, которые реализуют платформу виртуализации GPU-P, будь то WDDM или MCDM, и будь то GPU, NPU или другое разнородное вычислительное устройство.

Типы и назначение миграции ресурсов

Миграция ресурсов — это возможность перемещения виртуализации в новые физические ресурсы. Существуют различные способы перемещения виртуализированного выполнения, в том числе:

• Тяжелая мощность вниз. Виртуальная материнской платы может быть отключена напрямую, остановив выполнение виртуальных ресурсов. Все приложения, которые не терпимы к powerhit-toler, теряют данные, с которыми они работают, и все состояние устройства очищается. Затем виртуальный жесткий диск (VHD) можно виртуализировать на другом компьютере узла, что приводит к холодной загрузке.

• Мягкая мощность вниз. Это питание отличается от жесткого выключения в том, что он просто отправляет запрос питания в гостевую ОС. Затем гостевая ОС распределяет механизм выключения питания для приложений, чтобы полностью завершить работу. Приложения могут использовать это уведомление для безопасного хранения всех данных и регистрации для перезапуска при загрузке, хотя оно зависит от программирования каждого приложения. Для работы с мягким питанием требуется гостевая ОС, которая поддерживает этот механизм чистого завершения работы и соответствующие службы для хранения текущего состояния и перезапуска при перезагрузке.

• Спящего режима. Эта другая технология, созданная гостевыми пользователями, позволяет гостевым переходить к быстро начинающемся состоянию питания спящего режима, когда все процессы приложения заморожены, состояние устройства очищается в память ЦП, а затем все память отправляется в хранилище, чтобы позволить оборудованию отключать питание. Затем виртуальный жесткий диск хранилища виртуальных машин можно перезапустить на другом компьютере, а память загружена, состояние устройства восстановлено, а также процессы распаковки. Гибернация доступна только в гостевых операционных устройствах, поддерживающих его. Это довольно инвазивный процесс, который зависит от стабильности гостя, но он предоставляет механизм для восстановления процессов приложений с состоянием, что механизмы отключения не предоставляют.

• Быстрая миграция (также известная как сохранение и восстановление виртуальной машины). Благодаря этой технологии виртуальная машина приостановлена (виртуальные ЦП перестает планировать) и все состояние, необходимое для восстановления состояния на новых физических ресурсах, собирается в ОС узла, включая память виртуальной машины и состояние всех устройств. Затем это состояние передается на новый узел, который создает виртуальную машину со всеми загруженными контекстами виртуальных ЦП, сопоставляет память с пространством виртуальной машины и восстанавливает состояния устройства. Затем PowerOnRestore перезапускает выполнение виртуальных ЦП. Эта технология не зависит от гостевой ОС и не зависит от выполнения в гостевой среде, поэтому это более надежный способ поддержания процесса и состояния устройства, чем гибернация. Пользователь виртуализации может заметить значительное время простоя, так как память виртуальной машины может быть много ГБИТ/с, а время передачи может быть заметно.

• Динамическая миграция. Если у нас есть возможность передавать содержимое, пока виртуальные ресурсы по-прежнему активны, и мы можем отслеживать содержимое, которое становится грязным, мы можем передать значительное содержимое при выходе из активной виртуализации. Затем, когда виртуальная машина приостановлена, гораздо меньше содержимого необходимо передать, и мы можем свести к минимуму время, когда виртуализация не выполняется. Результат сводится к минимуму, так как все операции, происходящие во время миграции, продолжают неунижаться, и влияние на скорость потребления ресурсов сокращается до сих пор. В частности, крайние сроки сбоя (ограничения внешнего времени для сбоя виртуализации, такие как время ожидания TCP и других протоколов с внешними конечными точками), можно свести к минимуму или устранить.

Каждое прогрессии уменьшает или удаляет некоторые (часто крупные) сведения о изменении физического назначения виртуализации, что делает виртуализацию более полной и прозрачной для пользователя. Наряду с другими технологиями (например, изоляцией аварийного сбоя узла), которые отделяют зависимости клиентов от инфраструктуры, она перемещает наше решение виртуализации в направлении идеала независимости назначения и истинных временных вычислений.

Крупномасштабный дизайн

Динамическая миграция передает содержимое виртуализации с исходного узла на целевой узел. Виртуализация состоит из различных устройств с отслеживанием состояния, которые могут включать память, вычисления и хранилище, каждый из которых должен передаваться с устройств из источника на устройства на целевые устройства. Исполнительные агенты, управляющие виртуализацией между кластерами, взаимодействуют с узлами, чтобы сообщить им о настройке оркестрации для исходной миграции существующей виртуальной машины (когда содержимое покидает узел) или для целевой миграции на новую виртуальную машину (для получения содержимого). Основные игроки в этом взаимодействии отображаются на следующей схеме.

:

Эпохи исходного узла

На следующей схеме показаны состояния миграции на стороне источника.

:

Загрузка на стороне источника

При загрузке узла, как правило, KMD сообщает о возможностях устройства в ядро с помощью различных вызовов инициализации.

Когда KMD получает вызов DxgkDdiQueryAdapterInfo для DXGKQAITYPE_GPUPCAPS данных, он может задать бит LiveMigration, добавленный в DXGK_GPUPCAPS. Если KMD задает этот бит, он указывает, что драйвер поддерживает динамическую миграцию.

Предварительным условием для динамической миграции является поддержка отслеживания измененных страниц VRAM во всех сегментах памяти gpu, как описано в разделе "Грязное отслеживание битов". Эта поддержка сообщается через другие вызовы DxgkDdiQueryAdapterInfo для других указанных типов информации. Драйвер, который сообщает о поддержке динамической миграции, также должен сообщать о поддержке отслеживания грязное битов. Поддержка динамической миграции, но не грязное отслеживания битов является недопустимой конфигурацией, и Dxgkrnl не запускает адаптер.

Виртуальные машины в сети

После загрузки узла и стека управления в сети действие виртуальной машины начинает поступать в сеть. Запросы на запуск и остановку виртуальных машин начинают поступать, и мы начинаем видеть графические процессоры GPU-P, проецируемые в эти виртуализации.

Предполагая, что возможность грязное битовой плоскости, Dxgkrnl вызывает DxgkDdiStartDirtyTracking после резервирования ресурсов VRAM для VF (виртуальная функция), которая позволяет системе отслеживать чистоту VRAM в случае, когда VF позже участвует в сценарии миграции.

Этот запуск виртуальной машины начинает перехватывать доступ к таблице прерываний для виртуализации поддержки прерываний, которая продолжается в течение всего времени существования виртуальной машины.

Подготовка к отправке динамической миграции

Стек управления отправляет событие, чтобы начать динамическую миграцию при указании его элементов управления, и управление машиной состояния миграции собирает все состояние с виртуального устройства, которое неизменяемо для времени существования метрики конфигурации секции vGPU для восстановления vGPU на целевом объекте. После готовности начинается процесс подготовки буферов транспорта и инициализации стека транспорта.

Эта эпоха создает вызов введенного DDI DxgkDdiPrepareLiveMigration DDI. KMD должен установить политики планирования PF/VF, которые обеспечивают возможность потоковой миграции потоковой передачи грязное содержимого из VRAM на узле, сохраняя справедливую производительность для VF. Если отслеживание грязное сообщается как неперформантное, это также то, где запускается отслеживание грязное.

Отправка динамической миграции

:

Затем мы введем активный этап передачи грязное VRAM. Этот этап включает вызовы через грязное bitplane DDI, чтобы получить моментальные снимки кадра VF framebuffer, а затем разбиение этих страниц из GPU в буферы ЦП, подготовленные ранее.

На этой передаче происходит этап, когда виртуальная машина и все его виртуальные устройства приостановлены. VF может перестать планироваться для гостя, и в настоящее время любое дополнительное время, которое можно предоставить PF, чтобы завершить разбиение содержимого на страницах должно быть. Так как виртуальный ЦП и виртуальный ЦП приостановлены на виртуальной машине, после этого не должно быть никаких дополнительных изменений в переносе содержимого (ЦП или локальной памяти устройства).

Приостановленная отправка миграции

Последние итерации грязное страниц передаются при приостановке. На этом этапе выполняется вызов для сбора всех последних частей устройства и состояния драйвера, которые были изменяемыми во время активности и не могли быть переданы в ходе предыдущей подготовки. Это состояние может быть любое восстановление состояния, необходимое на другой стороне, любые структуры отслеживания или вообще все сведения, необходимые для завершения восстановления состояния VF на целевой стороне.

Разрыв динамической миграции

Наконец, когда виртуальная машина и все его виртуальные устройства перенесли свое состояние в новые физические реализации, исходная сторона может очистить остатки виртуальной машины. Буферы и другие состояния миграции очищаются, и виртуальный ЦП уничтожается.

Эпохи целевого узла

На следующей схеме показаны состояния миграции на стороне целевого объекта.

:

Загрузка на стороне целевого объекта

Загрузка на целевом объекте выглядит так же, как и в источнике. Загрузка выполняется для всей системы, которая может быть источником и целевым объектом на разных виртуальных машинах на протяжении всего жизненного цикла. Драйвер просто должен указать поддержку динамической миграции для участия.

Подготовка к динамической миграции

На целевой стороне виртуальная машина создается, как если бы она была новой виртуальной машиной. Создается виртуальная машина и виртуальные устройства. Этот процесс создания включает виртуальный GPU, созданный с помощью тех же параметров, с которыми он был создан на стороне источника. После создания данные проверки получаются и передаются драйверу, чтобы убедиться, что целевая сторона совместима с источником для восстановления виртуальной машины. На этом этапе он должен гарантировать, что все, что может повлиять на такую совместимость, включая версию драйвера, версии встроенного ПО и другие внешние состояния целевой системы и драйвера. Драйвер настроит доступ к PF для всех разбиения по страницам, которые обычно будут назначены VF, в то время как виртуальная машина еще не активна.

Получение динамической миграции

:

Получение данных грязное страницы аналогично сцене источника, за исключением направления разбиения по страницам из буферов ЦП в VRAM. Все трансферы выполняются в то время как VF приостановлена, поэтому весь трансфер можно сделать в рамках бюджета VF.

Запуск и разрыв виртуальной машины

После завершения миграции VRAM виртуальный ЦП получает возможность настроить любое дополнительное состояние, необходимое для передачи (окончательные изменяемые данные сохранения). Затем мы запустите виртуальную машину в целевом объекте и разорвать состояние миграции, включая буферы, используемые для передачи.

Цели производительности

Важной частью динамической миграции является его скорость реагирования. В частности, она сводит к минимуму время простоя виртуализации, к которой она не отвечает внешним образом (пользователю виртуализации или любым конечным точкам, к которой она может быть подключена). Многие протоколы сетевого стека имеют время ожидания на удаленных компьютерах, которые довольно кратко перед повторным повтором или восстановлением завершается ошибкой, и поэтому может быть нарушено для пользователя при удалении. Как общая фиксированная цель, общее время приостановки передачи и запуска должно быть менее трех четвертей секунды (750 мс), что приводит к истечении времени ожидания времени ожидания при большинстве наиболее распространенных тайм-аутов стека.

Кроме того, изменения производительности активной системы не должны активировать другие нарушения работы конечных пользователей, если это возможно. На устройствах, использующих эти DDIs, система не должна значительно увеличивать скорость TDR, замедляя запланированное время ожидания. Теперь мы ожидаем, что большинство TDR не длинные пакеты, но зависание устройств вместо этого, а удвоение или удвоение времени выполнения пакета не должно отправлять большинство пакетов в течение больших тайм-аутов секунд. Но мы должны знать, что не активируют время ожидания в общем рисунке производительности.

Интерфейсы драйверов устройств

Как правило, DDIS динамической миграции относятся к общим понятиям DDIS WDDM и MCDM и DDis виртуализации GPU-P, в частности.

• hAdapter обычно относится к маркеру дескриптора, представляющего определенное устройство, которое управляет этим драйвером. Системы с несколькими физическими устройствами, перечисленными системой, могут иметь драйвер управления несколькими hAdapters, поэтому hAdapter локализуется на определенном устройстве.

• vfIndex определяет, на какую виртуальную функцию или vDEV ссылается. Он локализуется на конкретное виртуальное устройство. Иногда это также называется идентификатором секции.

• DeviceLuid также локализует конкретное виртуальное устройство, но вниз на языке интерфейса UMED с помощью управления виртуальными устройствами.

• SegmentId определяет определенную уязвимость сегмента VidMm при ссылке на содержимое, хранящееся на устройстве, например резерв VRAM.

Примечание по определениям интерфейса

Эта статья относится к динамическим структурам размера. Эти структуры реализуются с помощью динамически размеров массивов, которые описываются на эталонных страницах следующим образом:

    size_t       ArraySize;
    ElementType  Array[ArraySize];

где интерфейс передает размер массива ранее в структуре и синтаксический анализ объекта интерфейса, а затем выполняет итерацию по нескольким элементам при указании массива. Эти объявления недопустимы, так как эти языки выражают фрагменты статического размера. Сначала считывается в структуру статического размера, а затем динамически анализируется в коде.

Отчеты о запуске и ограничениях устройства

В DXGK_GPUPCAPS добавляются следующие возможности:

• Ограничение LiveMigration указывает на поддержку драйвера для функции динамической миграции (как правило, добавленные DDIs, упоминание, указанные в этой статье, за исключением DxgkDdiSetVirtualGpuResources2).
• Ограничение ScatterMapReserve указывает на поддержку драйвера dxgkDdiSetVirtualGpuResources2, который будет добавлен в будущий выпуск.

KMD должен заполнить эти ограничения, когда ОС вызывает DxgkDdiQueryAdapterInfo с запросом DXGKQAITYPE_GPUPCAPS. ОС запрашивает ограничения во время инициализации устройства после вызова DxgkDdiStartDevice и когда адаптер поддерживает секционирование GPU.

Если драйвер возвращает крышку ScatterMapReserve , необходимо предоставить добавленный DXGKQAITYPE_SCATTER_RESERVE тип со следующими связанными структурами, чтобы ОС мог запрашивать возможности точечного резервирования драйвера:

• DXGK_QUERYSCATTERRESERVEIN для pInputData
• DXGK_QUERYSCATTERRESERVEOUT для pOutputData

Поддержка точечной разбиения по страницам

Для поддержки передачи неконтентных страниц грязное в кадр и с фреймбуфера эта функция является одной из первых для выполнения сопоставлений GPU-VA, которые не поддерживаются смежными физическими адресами. Текущие интерфейсы разбиения на страницы не нужно обновлять для этой поддержки, так как она всегда была общей возможностью, поддерживаемой таблицами страниц. Но любые скрытые сведения о реализации, которые сделали предположения о параллелизме, скорее всего, подвергаются этому изменению. Поэтому важно понять этот механизм ОС, как он выполняет виртуальные интерфейсы разбиения по страницам и обеспечить надежность разбиения по страницам для этого изменения.

В частности, интерфейс TransferVirtual теперь передает диапазоны va, которые не сопоставляются последовательно на кадре.

Запуск динамической миграции на стороне отправки

Когда система запускает динамический компонент миграции, необходимо вызвать добавленный DDI-файл DxgkDdiPrepareLiveMigration DDI. Этот вызов уведомляет драйвер о том, что эта эпоха была запущена и позволяет настроить политику планирования VF для миграции, которая должна выложить некоторые из бюджета бесплатной и миграции VF для разбиения по страницам PF.

Dxgkrnl затем вызывает dxgkDddiDdiSaveImmutableMigrationData DDI для сбора сведений об устройстве для восстановления на целевой стороне.

После сбора и отправки неизменяемых данных и данных проверки основной итеративный цикл отправки грязное начинается.

Итеративное сохранение и отправка

Как описано в разделе обзора, операция итерации сохранения использует DxgkDdiQueryDirtyBitData для моментального снимка текущего битового плана грязное для VF в начале каждой итерации и использует стандартную операцию DXGK_OPERATION_VIRTUAL_TRANSFER для страницы сообщаемых грязное страниц. Если эта операция возникает на устройстве, сообщаемом в своих возможностях отслеживания грязное, что это не является незначительным воздействием на производительность, элемент управления итерацией системы сначала включает грязное отслеживание, а затем передает весь фреймбуфер перед первым вызовом запроса грязное битового плана.

Для виртуальной передачи основное обновленное поведение заключается в том, что сопоставление не является смежным в VA с смежным PA. Вместо этого в сопоставлении могут быть отключены страницы PA. В противном случае поведение описано в исходной документации по отслеживанию по страницам и грязное битового плана, и эта функция не добавляется в эту функцию.

Динамическая миграция на стороне отправки

В конце миграции система должна собрать все состояния устройства и драйвера, необходимые для завершения перестроения состояния и отслеживания, которые еще не перенесены. Эти данные не удалось передать, так как они не соответствовали неизменяемости предыдущих данных миграции и не были грязное содержимого VRAM. Dxgkrnl вызывает добавленный dxgkDdiSaveMutableMigrationData DDI для этого. Использование DDI аналогично dxgkDdiSaveImmutableMigrationData.

В конечном итоге, когда больше не требуется конфигурация миграции в этом VF, вызывается dxgkDdiEndLiveMigration. Все планирование и состояние должны вернуться в конфигурацию, не относясь к немиграции.

Запуск динамической миграции на стороне получения

Когда неизменяемые данные приходят на принимающей стороне, система передает его непосредственно в KMD через вызов DxgkDdiRestoreImmutableMigrationData.

Этот DDI должен вызываться только для виртуальных машин, которые в настоящее время приостановлены.

Итеративное восстановление и получение

Опять же, точечная разбиение выполняется в итеративном режиме, но на этот раз без вызовов проверки грязное битового плана, связанного с фреймбуфером, зарезервированным VF, потому что грязное битовый план на целевом объекте создается по страницам. Направление разбиения по страницам обратно. Содержимое в полученных буферах передается в VRAM с размещением страниц, диктуемых.

Динамическая миграция на стороне получения

После завершения миграции система принимающей стороны вызывает функцию DxgkDdiRestoreMutableMigrationData с окончательным пакетом состояния для восстановления. Этот пакет должен предоставить все содержимое, которое осталось для драйвера, чтобы передать для восстановления состояния и отслеживания, а также для оставшегося восстановления состояния VF.

Этот DDI должен вызываться только для виртуальных машин, которые в настоящее время приостановлены.

После этого вызова система вызывает функцию DXGkDdiDdiEndLiveMigration, чтобы сообщить целевой стороне о том, чтобы очистить любое состояние вокруг динамической миграции, включая восстановление обычного планирования VF.

Обмен данными с UMED

Интерфейс БИБЛИОТЕКи DLL (UMED) в пользовательском режиме расширен с помощью интерфейса IGPUPMigration, чтобы предоставить возможность сохранять и проверять содержимое во время динамической миграции.

HRESULT SaveImmutableGpup(
    [in]     PLUID     DeviceLuid,
    [in,out] UINT64 *  Length,
    [in,out] BYTE *    SaveBuffer
    );

HRESULT RestoreImmutableGpup(
    [in] PLUID   DeviceLuid,
    [in] UINT64  Length,
    [in] BYTE *  RestoreBuffer
    );

Во время действий подготовки динамической миграции, в которых KMD вызывается аналогично, UMED имеет возможность отправлять все сведения, которые могут быть полезны для подготовки UMED для миграции или проверки, что поддержка среды миграции на уровне UMED. Это необязательный интерфейс для UMED с стандартными контрактами интерфейса для UMED (контекст потоков и процессов, ограниченное воздействие ОС и т. д.). Его вызывающий шаблон имитирует DDD-идентификаторы KMD с двухэтапным сохранением. В этих вызовах нет флагов состояния, таких как другие интерфейсы сохранения и восстановления UMED, так как они должны быть допустимыми и постоянными в течение всего времени существования устройства и его LUID.

Изменяемое состояние UMED передается в существующем интерфейсе сохранения и восстановления. В прошлом этот интерфейс был заблокирован для выполнения с драйверами GPU-P, но разблокируется при поддержке KMD отчетов для LiveMigration. Это связывание функции выноски UMED и возможности KMD намеренно. Динамическая миграция — это то, как система реализует быструю миграцию для виртуализации этих устройств. Такая же последовательность задач выполняется, и вы можете представить быструю миграцию (сохранить и восстановить) как особый случай динамической миграции, в которой нет активной передачи. UMED, поддерживающий сохранение и восстановление, по-прежнему должен иметь KMD, поддерживающий динамические DD-идентификаторы миграции. Аналогичным образом, UMED должен знать интерфейс IGPUPMigration и оценивать необходимость в его проектировании, прежде чем KMD может жить миграцией.

Виртуализация прерываний

Физическое адресация управления прерываниями гостя должна быть виртуализирована для правильного доступа к таблице MSI-X в качестве базовых изменений оборудования во время миграции. UMED должен перехватывать таблицу прерываний MSI-X для всех драйверов, поддерживающих динамическую миграцию. Все операции чтения или записи в поля "Верхний адрес сообщения" и "Адрес сообщения" должны соответствовать фактическим значениям оборудования. Dxgkrnl поддерживает сопоставление виртуализированного (или гостевого) адреса и выполняет подстановку при необходимости в стеке вызовов.

ОС управляет виртуализацией или сопоставлением гостевых физических адресов, которые считывает или записывает таблица, может ссылаться на гостевую сторону с физическими адресами узла, необходимыми для фактического обслуживания прерываний. Этот общий путь не требует отдельной реализации UMED или перенаправления ядра, и ОС не уведомляет UMED, когда ОС перехватывает таблицу. Единственное требование для UMED заключается в том, что для страниц bar таблицы необходимо задать устранение рисков для устройства.

Однако в ядре Dxgkrnl хочет, чтобы KMD обслуживал фактические записи. KMD делает это путем реализации добавленной функции обратного вызова DxgkDdiWriteVirtualizedInterrupt .

Никогда не должно быть необходимости чтения, так как UMD локально отслеживает записи (в виртуализированной или гостевой преобразованной форме), чтобы они не требовали дорогого прыжка ядра. Это отслеживание переносится с виртуальным устройством.

Синхронизация DDI и контексты IRQL

DDI	Уровень синхронизации	IRQL
DxgkDdiPrepareLiveMigration	0	PASSIVE
DxgkDdiEndLiveMigration	0	PASSIVE
DxgkDdiSaveImmutableMigrationData	0	PASSIVE
DxgkDdiSaveMutableMigrationData	0	PASSIVE
DxgkDdiRestoreImmutableMigrationData	0	PASSIVE
DxgkDdiRestoreMutableMigrationData	0	PASSIVE
DxgkDdiWriteVirtualizedInterrupt	0	PASSIVE
DxgkDdiSetVirtualGpuResources2	0	PASSIVE
DxgkDdiSetVirtualFunctionPauseState	0	PASSIVE
IGPUPMigration::SaveImmutableGpup	0	PASSIVE
IGPUPMigration::RestoreImmutableGpup	0	PASSIVE

Важные рекомендации по планированию VF

Эффективность передачи строго определяется планированием разбиения по страницам на PF. Чем больше доступа к подсистемам разбиения по страницам устройства, PF может использовать для насыщения шины и получения оптимальной пропускной способности, тем более производительность передачи в целом и приостановка передачи в частности. Чем больше содержимого, которое может быть захвачено и отправлено в течение определенного времени, тем лучше; по крайней мере до насыщенности сети.

Предпочтительнее изменить планирование только на подсистеме разбиения по страницам и ни один другой ресурс устройства, но не все проекты планирования VF могут позволить это. Как минимум, необходимо, чтобы планирование:

• Только возьмите бюджет из переносимого или неназначаемого расписания VF.
• Не унизите производительность для других виртуализаций на компьютере.

Обратите внимание, что на целевой стороне эти условия можно гораздо проще выполнить, так как VF приостановлен весь трансфер и что весь бюджет доступен. На стороне источника требуется балансировка потребностей миграции и потребностей виртуальной машины с конечной потребностью в выполнении целей приостановки передачи.