Mlr ошибки что это

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

Все отслеживаемые параметры делятся на два типа: одни относятся к качеству обслуживания (Quality of Service — QoS), другие — к качеству восприятия (Quality of Experience — QoE). В этой статье поговорим об основных параметрах QoS.

Отсутствие сигнала — самый критичный параметр, который относится к «красному» состоянию доставки. Такое событие возникает, когда система мониторинга по какой-либо причине не может получить данные для анализа. Чтобы решить эту проблему, необходимо выяснить её причину и быстро определить место её возникновения: сторона контент-провайдера, оборудование или сеть. Для этого потребуется несколько анализаторов или распределенная система мониторинга с несколькими клиентами (зондами).

Для IP вещания в первую очередь необходимо отслеживать два параметра: потеря пакетов и джиттер.

Если пакеты не теряются и гладко проходят всю цепочку доставки, то качество сигнала можно считать высоким. Если возникает потеря пакетов или джиттер превышает пороговые значения, проблемы с доставкой становятся очевидными для пользователей. Поэтому эти два параметра являются важнейшими для обеспечения высокого качества обслуживания. Потерю пакетов можно оценить, проверив счетчик непрерывности (Continuity Counter), встроенный в заголовок TS.

Ошибки Continuity Counter (CC) возникают, если обнаружен некорректный порядок пакетов, если один пакет повторяется более двух раз, или если пакет потерян.

Media Loss Rate (MLR) — метрика, позволяющая детально оценить потери пакетов. Показывает количество потерянных транспортных пакетов в секунду.

Inter-packet Arrival Time (IAT) — значение времени между приходящими пакетами, зафиксированное за одну секунду измерений. Максимальное значение IAT является мерой джиттера. Джиттер определяется как сравнение временных интервалов между приходящими пакетами.

Коэффициент задержки (Delay Factor) — еще один из наиболее значимых параметров мониторинга. Это временное значение, показывающее сколько миллисекунд данных должны содержать буферы, чтобы устранить временные искажения (джиттер). Как индикатор качества при мониторинге сети доставки вещания видеосервисов, чувствительной к джиттеру и потере данных, может быть использован индекс MDI (Media Delivery Index — DF:MLR).

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

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

TR 101 290 — стандарт, описывающий порядок измерений для спутниковых, кабельных, эфирных цифровых телевизионных систем. Стандарт содержит пороговые значения для событий, однако для IPTV-потоков строгое соответствие требованиям стандарта не требуется. Анализ TR 101 290 применяется как для IPTV, так и для нешифрованных OTT-сервисов (или для тех, которые могут быть дешифрованы), основанных на технологии фрагментированного транспортного потока. При ошибках TR 101 290 возникают такие дефекты изображения как пикселизация, шумы, замирания аудио и видео, черный экран и другие.

Итак, это важнейшие ошибки QoS, которые важно отслеживать с помощью системы мониторинга.
Для иллюстраций была использована система мониторинга Elecard Boro.

Повышение QoE — залог удержания клиентов

Системы кеширования становятся одними из наиболее востребованных элементов сетевой инфраструктуры, таким же как коммутатор доступа или пограничный маршрутизатор. При этом данный элемент необходим как провайдерам и операторам связи для оптимального планирования расширения каналов передачи данных, так и корпоративным структурам для оптимизации бизнес-приложений.
Для больших корпоративных структур системы кеширования используются для оптимизации арендованных каналов связи для работы CRM и ERP систем.
Cервис-провайдеры сталкиваются с растущими проблемами. P2P и Internet HTTP/video приложения потребляют значительную часть производительности сети, вдобавок к растущему количеству мобильных устройств, с которых осуществляется выход в интернет отовсюду. Подписчики требуют все больше и больше сервисов, а также оперативности действий по их немедленной доступности.
Системы кеширования повышают QoE провайдеров.
Для избежания неудовлетворености услугами и потери клиентов мы рекомендуем провайдерам внедрять системы кеширования для оптимизации производительности аплинк- каналов и увеличения скорости доставки наиболее часто запрашиваемого контента.

Компоненты MDI
На рис. 1 приведена стандартная схема подключения сетевой инфраструктуры провайдера связи.

MDI относится ко всей сети и может быть определен между точками источника видео и STB приставкой пользователя. MDI обычно отображается как два отдельных значения, которые разделяются двоеточием — Delay factor (DF) и Media loss rate (MLR) (DF: MLR)

DF: MLR

DF (Фактор задержки)
Для того, что бы понять суть параметра Delay Factor (DF), полезно рассмотреть соотношение между джиттером (дрожанием) и буферизацией. Джиттером является изменение задержки сигнала по времени. Пакеты, прибывающие в место назначения с постоянной задержкой по времени имеют нулевой джиттер, а пакеты с непостоянной задержкой — не нулевой. Схемы на рис. 2 иллюстрируют это отличие.

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

Рассмотрим типичный MPEG видеопоток (3,75 Mb/s). Декодер в точке назначения будет принимать поток 3,75 Mb/s, но данные могут приходить со скоростью выше и ниже заявленной величины. Буферы в декодере используются для сбора определенного количества пакетов, прибывающих с разными скоростями и передачи их для декодирования, с постоянной скоростью. Чем больше джиттер, тем больше буферов необходимо для его устранения. Задача больших буферов в том, что они вносят задержку для сигнала большой степени дрожания. Кроме того, буферы ограниченных размеров в совокупности с чрезмерным джиттером приходят к переполнению или не дополнению. Переполнение происходит тогда, когда пакеты приходят с такой скоростью, что происходит полное заполнение буфера, тогда происходит потеря пакетов в приемнике.
Не дополнение к  этому ситуация, когда пакеты прибывают так медленно, что буферу недостаточно данных для передачи их в декодер. Обе эти ситуации нежелательны, так как они ведут к ухудшению QoE пользователя.

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

DF — это компонент MDI, который является временным значением и определяет количество секунд, которое буфер должен удерживать пакет для устранения явления джиттера. Он определяет, насколько прибывающие пакеты доходят до пользователя, через заданные интервалы времени (обычно 1 секунда) и вычисляется как:
Разница между принятыми буфером и доставленными до пользователя байтами в каждом приходящем пакете – виртуальная глубина буфера MDI (∆):
∆ = “принятые байты” – “доставленные байты”
Отношение разницы между минимальной и максимальной величиной виртуальных глубин буферов к скорости потока данных:

DF=((max⁡(∆)- min(∆)))/(скорость потока);

В качестве примера еще раз рассмотрим видео поток MPEG. Если в течении односекундного интервала, максимальная величина виртуальной глубины буфера MDI составляет 3.775 Mb, а минимальная около 3.740 Mb, то фактор задержки (DF) будет определяться как:

DF=(3.755Mb-3.740Mb)/(3.75Mb/s)= 15kb/(3.75Mb/s)=4ms;

Следовательно, для того чтобы избежать потери пакетов при наличии такого джиттера, буфер приемника должны быть 15kb, что вводит 4 миллисекунды задержки.
DF может быть использован при доставке видео контента, как оценка качества видео с точки зрения пользователей и обозначать QoE. Он также может быть использован для определения влияния каждого сетевого элемента вдоль пути доставки видео. При сравнении DF на входе и DF выходе из устройства, можно определить задержку (footprint), которую вносит устройство. Устройства не вносящие джиттер, должны иметь наименьшее значение задержки (footprint) – они лучше подходят для построения сетей доставки видео.
Acceptable Delay Factor (Допустимый фактор задержки)

Фактор задержки допустимый для множества сетевых элементов сильно варьируется, так как в них доступен широкий диапазон размеров буфера. В большинстве STBs используются RAM модули. Только часть этого RAM используется по прямому назначению, а часть в используется в качестве буфера для ликвидации джиттера входящих IP потоков, именно поэтому большинство STBs не имеет, в списке общих характеристик, указания величины размера буфера. Фактический размер буфера каждого STB может быть определен путем тестирования в конкретных условиях. Множество QoE стандартов, которые разработаны DSL форумом в части WT-126 рекомендуют, что бы джиттер элементов сетевой инфраструктуры не превышал значения 50мс, тем не менее, большинство STBs среднего и высокого уровней могут предложить значение намного ниже. Тестирования ряда STBs низкого уровня показали среднее значение величины джиттера равное 9ms.
Эти два значения немного меняются в зависимости от величин потов, но незначительно (менее чем 10%). Расхождение между двумя значениями (50 мс и 9 мс) объясняется большим разбросом в качестве доступных STBs. Точный максимально допустимый DF должен быть настроен на размер буфера STB. Необходимо установить максимальный размер джиттера, который поддерживает ваша STB, с целью предотвращения появления какие-нибудь искажений.

Media loss rate (MLR)

Media loss rate (MLR) просто определяется, как количество потерянных или пришедших не по порядку медиа пакетов в секунду. Неупорядоченность пакетов важна, потому что большинство устройств не питаются изменить их порядок перед представлением в декодер. Любые потери пакетов – представляются как не нулевой MLR – негативно повлияют на качество видео, приведут к негативным искажениям или к неравномерности воспроизведения видео. MLR является удобным параметром для определения уровня обслуживания (SLA) с точки зрения потерь пакетов. Так, в совокупности с предыдущим параметром DF, показатель MDI 4:0.001 говорит о том, что устройство имеет фактор задержки 4 мс и показатель потерь пакетов в секунду 0.001.
количества пропущенных пакетов. Так, взятые в контексте с предыдущим компонентом DF, устройство с MDI из 4:0.001 будет означать, что устройство имеет задержку в 4 раза миллисекунд и скорости СМИ потере 0,001 СМИ пакетов в секунду.
Acceptable MLR (Допустимый MLR)

MDI есть простым и понятным способом определения оценки влияния сети на видео, а следовательно и на QoEпользователя. Два компонента, составляющих MDI, фактор задержки и коэффициент потери пакетов, в целом определяют качество предоставления услуг IPTV.

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

Как выбрать систему кеширования?

Что бы подойти к выбору системы кеширования удовлетворяющей требованиям конкретной сети, необходимо понимать основные параметры и их влияние на работу сети. Конечно же, одним из важнейших параметров любой системы является производительность и система кеширования не исключение. Тем не менее, некоторые параметры нуждаются в рассмотрении для правильного понимания их истинного значения.
Определение производительности системы кеширования (Net Cache Out)
Трафик, входящий в кэш определяется как Cache In, а трафик выходящий из кеш как Cache Out. Мы не должны путать Cache Out с показателями производительности всей системы кеширования. Есть небольшие отличия в функциональности систем кеширования с точки зрения определения параметра Cache Out — out-of-band и in-line системы:
— out-of-band – в данном случае Cache Out зависит только от кешированного контента. В этм случае Cache Out можно сопоставлять со значением производительности системы кеширования.
— В in-line системах, Cache Out параметр является суммой значения кешированного контента распространяющегося из кеш и добавления потока трафика проходящего через систему от входа к выходу без кеширования. Это связано с требованием симметричности маршрутизации. Таким образом, с точки зрения in-line систем кеширования, Cache Out не может быть использован как показатель производительности системы кеширования.

Развертывания систем кеширования больших провайдеров показывают, что производительности out-of-band систем кеширования могут достигать 100Gbps (Cache Out = 100gbps). В то время как in-line системы кеширования призванные отрабатывать 20Gbps, обычно дают не более 4Gbps Cache Out – производительности кеширования.
Максимальная эффективность (наивысший коэффициент попадания в кэш)
Важным параметром HTTP/Video производительности есть коэффициент попадания в кэш. Этот коэффициент на HCS (HTTP Cache Server) считается как общее количество видео запросов, которые успешно были доставлены кэш-сервером по отношению к общему количеству запросов пользователей. Коэффициент попадания в кэш может составлять 80% для YouTube трафика или даже 100% для MS обновлений. Очевидно, что высокий коэффициент попадания в кэш определяет высокую эффективность кэширования.
На рисунках представлен возможный вид графиков для YouTube и MS update контента.

Стоит отметить, что in-line решения кэширования, разворачиваемые в больших сетях, требуют множества систем кэширования и не поддерживают глобального анализа трафика. Ко всему, множество систем кэширования – без централизованного управления – дублируют одинаковых контент много раз. Как результат, in-line решения кэширования дают намного меньшую производительность и есть намного менее эффективными, чем решения out-of-band.

From Wikipedia, the free encyclopedia

The Media Delivery Index (MDI) is a set of measures that can be used to monitor both the quality of a delivered video stream as well as to show system margin for IPTV systems by providing an accurate measurement of jitter and delay at network level (Internet Protocol, IP), which are the main causes for quality loss. Identifying and quantizing such problems in this kind of networks is key to maintaining high quality video delivery and providing indications that warn system operators with enough advance notice to allow corrective action.^[1]

The Media Delivery Index is typically displayed as two numbers separated by a colon: the Delay Factor (DF) and the Media Loss Rate (MLR).^[2]

Context[edit]

The Media Delivery Index (MDI) may be able to identify problems caused by:

Time distortion[edit]

If packets are delayed by the network, some packets arrive in bursts with interpacket delays shorter than when they were transmitted, while others are delayed such that they arrive with greater delay between packets than when they were transmitted from the source (see figure below). This time difference between when a packet actually arrives and the expected arrival time is defined as packet jitter or time distortion.^[3]

A receiver displaying the video at its nominal rate must accommodate the varying input stream arrival times by buffering the data arriving early and assuring that there is enough already stored data to face the possible delays in the received data (because of this the buffer is filled before displaying).

Similarly, the network infrastructure (switches, routers,…) uses buffers at each node to avoid packet loss. These buffers must be sized appropriately to handle network congestion.

Packet delays can be caused by multiple facts, among which there are the way traffic is routed through the infrastructure and possible differences between link speeds in the infrastructure.

Moreover, some methods for delivering Quality of Service (QOS) using packet metering algorithms may intentionally hold back packets to meet the quality specifications in the transmission.^[4][5]

The effects of all these facts on the amount of packets received by a specific point in the network can be seen in the next graphics:

Packet loss[edit]

Packets may be lost due to buffer overflows or environmental electrical noise that creates corrupted packets. Even small packet loss rates result in a poor video display.

Description[edit]

Packet delay variation and packet loss have been shown to be the key characteristics in determining whether a network can transport good quality video. These features are represented as the Delay Factor (DF) and the Media Loss Rate (MLR), and they are combined to produce the Media Delivery Index (MDI), which is displayed as:

Components[edit]

The different components of the Media Delivery Index (MDI) are explained in this section.

Delay Factor (DF)[edit]

The Delay Factor is a temporal value given in milliseconds that indicates how much time is required to drain the virtual buffer at the concrete network node and at a specific time. In other words, it is a time value indicating how many milliseconds’ worth of data the buffers must be able to contain in order to eliminate time distortions (jitter).^[3]

It is computed as packets arrive at the node and is displayed/recorded at regular intervals (typically one second).

It is calculated as follows:

1. At every packet arrival, the difference between the bytes received and the bytes drained is calculated. This determines the MDI virtual buffer depth:

2. Over a time interval, the difference between the minimum and maximum values of Δ is taken and then divided by the media rate:

Maximum acceptable DF:^[5] 9–50 ms

Media Loss Rate (MLR)[edit]

The Media Loss Rate is the number of media packets lost over a certain time interval (typically one second).^[3]

It is computed by subtracting the number of media packets received during an interval from the number of media packets expected during that interval and scaling the value to the chosen time period (typically one second):

Maximum acceptable channel zapping MLR:^[5] 0

Maximum acceptable average MLR:

• SDTV: 0.004
• VOD: 0.004
• HDTV: 0.0005

It must be said that the maximum acceptable MLR depends on the implementation. For channel zapping, a channel is generally viewed for a brief period, so one would be bothered if any packet loss occurred. For this case the maximum acceptable MLR is 0, as stated before, because any greater a value would mean a loss of one or more packets in a small viewing timeframe (after the zap time).

Use[edit]

Generally, the Media Delivery Index (MDI) can be used to install, modify or evaluate a video network following the next steps:^[3]

1. Identify, locate, and address any packet loss issues using the Media Loss Rate.
2. Identify and measure jitter margins using the Delay Factor.
3. Establish an infrastructure monitor for both MDI components to analyze any possible scenarios of interest.

Given these results, measures must be taken to provide solutions to the problems found in the network. Some of them are: redefining system specifications, modifying the network components in order to meet the expected quality requirements (or number of users), etc.

Other parameters[edit]

Other parameters may also be desired in order to troubleshoot concerns identified with the MDI and to aid in system configuration and monitoring. Some of them are:^[3]

• Network Utilization. Tracking the instantaneous, minimum, and maximum overall network utilization is needed to verify that sufficient raw bandwidth is available for a stream on a network. High utilization level is also an indicator that localized congestion is likely due to queue behavior in network components. The DF provides a measure of the results of congestion on a given stream.
• Video stream statistics such as:
  • Instantaneous Flow Rate (IFR) and Instantaneous Flow Rate Deviation (IFRD). The measured IFR and IFRD confirm a stream’s nominal rate and, if not constant over time, gives insight into how a stream is being corrupted.
  • Average Rate in Mbit/s. This measure indicates whether the stream’s rate being analyzed conforms to its specified rate over a measurement time. This is the longer term measurement of IFR.
  • Stream Utilization in percent of network bandwidth. This measure indicates how much of the available network bandwidth is being consumed by the stream being analyzed.

References[edit]

External links[edit]

• ITU IPTV Focus Group
• IPTV industry resources

From Wikipedia, the free encyclopedia

The Media Delivery Index (MDI) is a set of measures that can be used to monitor both the quality of a delivered video stream as well as to show system margin for IPTV systems by providing an accurate measurement of jitter and delay at network level (Internet Protocol, IP), which are the main causes for quality loss. Identifying and quantizing such problems in this kind of networks is key to maintaining high quality video delivery and providing indications that warn system operators with enough advance notice to allow corrective action.^[1]

The Media Delivery Index is typically displayed as two numbers separated by a colon: the Delay Factor (DF) and the Media Loss Rate (MLR).^[2]

Context[edit]

The Media Delivery Index (MDI) may be able to identify problems caused by:

Time distortion[edit]

If packets are delayed by the network, some packets arrive in bursts with interpacket delays shorter than when they were transmitted, while others are delayed such that they arrive with greater delay between packets than when they were transmitted from the source (see figure below). This time difference between when a packet actually arrives and the expected arrival time is defined as packet jitter or time distortion.^[3]

A receiver displaying the video at its nominal rate must accommodate the varying input stream arrival times by buffering the data arriving early and assuring that there is enough already stored data to face the possible delays in the received data (because of this the buffer is filled before displaying).

Similarly, the network infrastructure (switches, routers,…) uses buffers at each node to avoid packet loss. These buffers must be sized appropriately to handle network congestion.

Packet delays can be caused by multiple facts, among which there are the way traffic is routed through the infrastructure and possible differences between link speeds in the infrastructure.

Moreover, some methods for delivering Quality of Service (QOS) using packet metering algorithms may intentionally hold back packets to meet the quality specifications in the transmission.^[4][5]

The effects of all these facts on the amount of packets received by a specific point in the network can be seen in the next graphics:

Packet loss[edit]

Packets may be lost due to buffer overflows or environmental electrical noise that creates corrupted packets. Even small packet loss rates result in a poor video display.

Description[edit]

Packet delay variation and packet loss have been shown to be the key characteristics in determining whether a network can transport good quality video. These features are represented as the Delay Factor (DF) and the Media Loss Rate (MLR), and they are combined to produce the Media Delivery Index (MDI), which is displayed as:

Components[edit]

The different components of the Media Delivery Index (MDI) are explained in this section.

Delay Factor (DF)[edit]

The Delay Factor is a temporal value given in milliseconds that indicates how much time is required to drain the virtual buffer at the concrete network node and at a specific time. In other words, it is a time value indicating how many milliseconds’ worth of data the buffers must be able to contain in order to eliminate time distortions (jitter).^[3]

It is computed as packets arrive at the node and is displayed/recorded at regular intervals (typically one second).

It is calculated as follows:

1. At every packet arrival, the difference between the bytes received and the bytes drained is calculated. This determines the MDI virtual buffer depth:

2. Over a time interval, the difference between the minimum and maximum values of Δ is taken and then divided by the media rate:

Maximum acceptable DF:^[5] 9–50 ms

Media Loss Rate (MLR)[edit]

The Media Loss Rate is the number of media packets lost over a certain time interval (typically one second).^[3]

It is computed by subtracting the number of media packets received during an interval from the number of media packets expected during that interval and scaling the value to the chosen time period (typically one second):

Maximum acceptable channel zapping MLR:^[5] 0

Maximum acceptable average MLR:

• SDTV: 0.004
• VOD: 0.004
• HDTV: 0.0005

It must be said that the maximum acceptable MLR depends on the implementation. For channel zapping, a channel is generally viewed for a brief period, so one would be bothered if any packet loss occurred. For this case the maximum acceptable MLR is 0, as stated before, because any greater a value would mean a loss of one or more packets in a small viewing timeframe (after the zap time).

Use[edit]

Generally, the Media Delivery Index (MDI) can be used to install, modify or evaluate a video network following the next steps:^[3]

1. Identify, locate, and address any packet loss issues using the Media Loss Rate.
2. Identify and measure jitter margins using the Delay Factor.
3. Establish an infrastructure monitor for both MDI components to analyze any possible scenarios of interest.

Given these results, measures must be taken to provide solutions to the problems found in the network. Some of them are: redefining system specifications, modifying the network components in order to meet the expected quality requirements (or number of users), etc.

Other parameters[edit]

Other parameters may also be desired in order to troubleshoot concerns identified with the MDI and to aid in system configuration and monitoring. Some of them are:^[3]

• Network Utilization. Tracking the instantaneous, minimum, and maximum overall network utilization is needed to verify that sufficient raw bandwidth is available for a stream on a network. High utilization level is also an indicator that localized congestion is likely due to queue behavior in network components. The DF provides a measure of the results of congestion on a given stream.
• Video stream statistics such as:
  • Instantaneous Flow Rate (IFR) and Instantaneous Flow Rate Deviation (IFRD). The measured IFR and IFRD confirm a stream’s nominal rate and, if not constant over time, gives insight into how a stream is being corrupted.
  • Average Rate in Mbit/s. This measure indicates whether the stream’s rate being analyzed conforms to its specified rate over a measurement time. This is the longer term measurement of IFR.
  • Stream Utilization in percent of network bandwidth. This measure indicates how much of the available network bandwidth is being consumed by the stream being analyzed.

References[edit]

External links[edit]

• ITU IPTV Focus Group
• IPTV industry resources

Mlr ошибки что это

Будь в курсе последних новостей из мира гаджетов и технологий

Важнейшие параметры QoS для определения ошибок вещания

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

Все отслеживаемые параметры делятся на два типа: одни относятся к качеству обслуживания (Quality of Service — QoS), другие — к качеству восприятия (Quality of Experience — QoE). В этой статье поговорим об основных параметрах QoS.

Отсутствие сигнала — самый критичный параметр, который относится к «красному» состоянию доставки. Такое событие возникает, когда система мониторинга по какой-либо причине не может получить данные для анализа. Чтобы решить эту проблему, необходимо выяснить её причину и быстро определить место её возникновения: сторона контент-провайдера, оборудование или сеть. Для этого потребуется несколько анализаторов или распределенная система мониторинга с несколькими клиентами (зондами).

Уведомления об отсутствии сигнала в системе мониторинга

Для IP вещания в первую очередь необходимо отслеживать два параметра: потеря пакетов и джиттер .
Если пакеты не теряются и гладко проходят всю цепочку доставки, то качество сигнала можно считать высоким. Если возникает потеря пакетов или джиттер превышает пороговые значения, проблемы с доставкой становятся очевидными для пользователей. Поэтому эти два параметра являются важнейшими для обеспечения высокого качества обслуживания. Потерю пакетов можно оценить, проверив счетчик непрерывности (Continuity Counter), встроенный в заголовок TS.
Ошибки Continuity Counter (CC) возникают, если обнаружен некорректный порядок пакетов, если один пакет повторяется более двух раз, или если пакет потерян.

CC ошибки и их влияние на поток

Media Loss Rate (MLR) — метрика, позволяющая детально оценить потери пакетов. Показывает количество потерянных транспортных пакетов в секунду.
Inter-packet Arrival Time (IAT) — значение времени между приходящими пакетами, зафиксированное за одну секунду измерений. Максимальное значение IAT является мерой джиттера. Джиттер определяется как сравнение временных интервалов между приходящими пакетами.

IAT:MLR график в системе мониторинга

Коэффициент задержки (Delay Factor) — еще один из наиболее значимых параметров мониторинга. Это временное значение, показывающее сколько миллисекунд данных должны содержать буферы, чтобы устранить временные искажения (джиттер). Как индикатор качества при мониторинге сети доставки вещания видеосервисов, чувствительной к джиттеру и потере данных, может быть использован индекс MDI (Media Delivery Index — DF:MLR).

Индекс MDI в системе мониторинга

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

Несколько источников вещания. Когда несколько источников мультикаст вещания начинают передавать данные в одной группе, могут возникать различные ошибки.
TR 101 290 — стандарт, описывающий порядок измерений для спутниковых, кабельных, эфирных цифровых телевизионных систем. Стандарт содержит пороговые значения для событий, однако для IPTV-потоков строгое соответствие требованиям стандарта не требуется. Анализ TR 101 290 применяется как для IPTV, так и для нешифрованных OTT-сервисов (или для тех, которые могут быть дешифрованы), основанных на технологии фрагментированного транспортного потока. При ошибках TR 101 290 возникают такие дефекты изображения как пикселизация, шумы, замирания аудио и видео, черный экран и другие.

Источник

Важнейшие параметры QoS для определения ошибок вещания

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

Все отслеживаемые параметры делятся на два типа: одни относятся к качеству обслуживания (Quality of Service — QoS), другие — к качеству восприятия (Quality of Experience — QoE). В этой статье поговорим об основных параметрах QoS.

Отсутствие сигнала — самый критичный параметр, который относится к «красному» состоянию доставки. Такое событие возникает, когда система мониторинга по какой-либо причине не может получить данные для анализа. Чтобы решить эту проблему, необходимо выяснить её причину и быстро определить место её возникновения: сторона контент-провайдера, оборудование или сеть. Для этого потребуется несколько анализаторов или распределенная система мониторинга с несколькими клиентами (зондами).

Для IP вещания в первую очередь необходимо отслеживать два параметра: потеря пакетов и джиттер.

Если пакеты не теряются и гладко проходят всю цепочку доставки, то качество сигнала можно считать высоким. Если возникает потеря пакетов или джиттер превышает пороговые значения, проблемы с доставкой становятся очевидными для пользователей. Поэтому эти два параметра являются важнейшими для обеспечения высокого качества обслуживания. Потерю пакетов можно оценить, проверив счетчик непрерывности (Continuity Counter), встроенный в заголовок TS.

Ошибки Continuity Counter (CC) возникают, если обнаружен некорректный порядок пакетов, если один пакет повторяется более двух раз, или если пакет потерян.

Media Loss Rate (MLR) — метрика, позволяющая детально оценить потери пакетов. Показывает количество потерянных транспортных пакетов в секунду.

Inter-packet Arrival Time (IAT) — значение времени между приходящими пакетами, зафиксированное за одну секунду измерений. Максимальное значение IAT является мерой джиттера. Джиттер определяется как сравнение временных интервалов между приходящими пакетами.

Коэффициент задержки (Delay Factor) — еще один из наиболее значимых параметров мониторинга. Это временное значение, показывающее сколько миллисекунд данных должны содержать буферы, чтобы устранить временные искажения (джиттер). Как индикатор качества при мониторинге сети доставки вещания видеосервисов, чувствительной к джиттеру и потере данных, может быть использован индекс MDI (Media Delivery Index — DF:MLR).

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

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

TR 101 290 — стандарт, описывающий порядок измерений для спутниковых, кабельных, эфирных цифровых телевизионных систем. Стандарт содержит пороговые значения для событий, однако для IPTV-потоков строгое соответствие требованиям стандарта не требуется. Анализ TR 101 290 применяется как для IPTV, так и для нешифрованных OTT-сервисов (или для тех, которые могут быть дешифрованы), основанных на технологии фрагментированного транспортного потока. При ошибках TR 101 290 возникают такие дефекты изображения как пикселизация, шумы, замирания аудио и видео, черный экран и другие.

Итак, это важнейшие ошибки QoS, которые важно отслеживать с помощью системы мониторинга.
Для иллюстраций была использована система мониторинга Elecard Boro.

Источник

IPTV в России

Мониторинг IPTV или MDI и с чем его едят…

« previous entry | next entry »
май. 7, 2007 | 05:28 pm

Запись опубликована IPTV в России.Пожалуйста, оставляйте коментарии там.

В связи с тем, что тема мониторинга достаточно актуальна, но практически не раскрыта на блоге, я решил написать немного на эту тему… Начать же хочу с описания самой распространенной на данный момент методики — RFC 4445.

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

В связи с этим был утвержден индекс MDI (Media Delivery Index) определенный в методике RFC 4445. Он основан на принципе формирования интегральной оценки качества по совокупности двух самых важных параметров качества на всех участках транспорта IPTV инфраструктуры — джиттера и количества потерянных пакетов. И логика метода MDI заключается в том, что если с транспортом пакетов проблем не будет, то не будет проблем и с контентом. Эти параметры определены как уровень задержки Delay Factor (DF) и уровень потерянных пакетов Media Loss Rate (MLR).

MDI вычисляется за произвольный промежуток времени, обычно это 1 секунда

• MDI-DF показывает наибольшее значение параметра джиттера пакетов за период измерения
• MDI-MLR показывает количество транспортных пакетов , потерянных за период измерения

И если с измерениями уровня MLR, выполняющимися методами пассивного мониторинга все предельно понятно, то с DF дело обстоит сложнее. Джиттером в MDI является задержка между ожидаемым и реальным временем приема пакета (см. рисунок).

где IAT — среднее время доставки соседних IP-фреймов.

По сути DF определяет критический размер буфера на стороне приемника, и в отличие от MLR измерение параметра задержки DF не может быть реализовано методами пассивного мониторинга.

MDI — это простой алгоритм мониторинга уровня транспорта для квалификации качества уровня услуг. За счет применения MDI можно осуществить мониторинг параметров качества на всех основных узлах транспорта начиная HeadEnd и заканчивая STB, выявить участок, где происходит ухудшение качества, и определить в какой степени это критично для услуги IPTV.

Источник

Машинное обучение на языке R с использованием пакета mlr3

В этом сообщении мы рассмотрим самый продуманный на сегодняшний день подход к машинному обучению на языке R — пакет mlr3 и экосистему вокруг него. Данный подход основан на «нормальном» ООП с использованием R6-классов и на представлении всех операций с данными и моделями в виде графа вычислений. Это позволяет создавать упорядоченные и гибкие пайплайны для задач машинного обучения, но на первых порах может показаться сложным и запутанным. Ниже постараемся внести определенную ясность и замотивировать к использованию mlr3 в ваших проектах.

Содержание:

1. Немного истории и сравнение с конкурирующими решениями

caret — старый, но не бесполезный

Пакет caret является первой реализацией инфраструктуры для построения моделей машинного обучения на R и одной из первых библиотек такого рода в целом (релиз на CRAN состоялся в 2007 году). В 2013 году по уже классическому на тот момент пакету была издана не менее классическая книга Applied Predictive Modeling, которую в комплекте с официальной документацией и сейчас можно рекомендовать в качестве вводного практического руководства по машинному обучению.

• простота использования для стандартных задач (без экзотических схем кросс-валидации и многоуровневого стекинга);
• реализованы классические способы разбивки данных для (кросс-)валидации, функции предварительной обработки типа шкалирования, импутации и удаления коррелирующих признаков, метрики качества и методы отбора признаков;
• поддерживается огромное количество моделей, работать с которыми по отдельности без caret-овских оберток довольно неудобно из-за неунифицированных интерфейсов;
• достаточно разумный выбор настраиваемых гиперпараметров — например, для xgboost это оказывающие наибольшее влияние на качество параметры nrounds , max_depth , eta , gamma , colsample_bytree , min_child_weight и subsample .

• первый минус является следствием последнего из перечисленных преимуществ — если хочется настраивать дополнительные гиперпараметры, придется написать свою обертку для соответствующей модели. Создание таких оберток является достаточно трудоемким;
• модели трактуются как алгоритмы машинного обучения без этапа предварительной обработки данных и создания признаков: этот этап выполняется на всех данных, а не внутри ресемплов при перекрестной проверке. Пакет recipes частично решает данную проблему, но об этом ниже;
• нет вложенной кросс-валидации (nested resampling), ограниченные возможности для создания ансамблей при помощи пакета caretEnsemble.

tidyverse strikes back

Своебразной работой над ошибками стало создание семейства пакетов под общей вывеской tidymodels, основными из которых являются recipes (отвечает за создание «рецептов» предварительной обработки данных, исполняемых внутри ресемплов с обучением на обучающей выборке и применением на обучающей и валидационной), rsample (обеспечивает различные варианты разбивки данных) и относительно новый tune (реализует собственно тюнинг гиперпараметров).

• «рецепты» позволяют выполнять предварительную обработку данных внутри ресемплов, что является верным подходом для борьбы с переобучением;
• продвинутые методы предварительной обработки, в том числе реализованные в пакетах embed и textrecipes;
• можно настраивать любые гиперпараметры моделей, а не определенное разработчиками пакета их подмножество. Также можно настраивать гиперпараметры этапов предобработки (пакет tune);
• пакет workflows добавляет абстракцию для модели как комбинации «рецепта» и алгоритма машинного обучения.

• чтобы работать с самими вариантами предобработки как с гиперпараметрами, возможностей пакета tune недостаточно. «Рецепт» нужно параметризировать, написав для этого функцию, а затем перебрать разные варианты предобработки при помощи цикла либо apply / map -функции;
• создание собственных этапов предобработки является исключительно запутанным и сложным для дебага. Например, для реализации кодирования средним или медианой пришлось написать 200 строк кода;
• вложенную кросс-валидацию и ансамбли нужно реализовывать вручную.

mlr3 vs все остальные

Пакет mlr3 и экосистема вокруг него также представляют собой попытку исправить недостатки как более раннего пакета mlr тех же авторов, так и рассмотренных выше caret и tidymodels. mlr подробно рассматривать не будем ввиду того, что его развитие было остановлено в пользу mlr3.

• в основе лежат R6-классы, в качестве бекенда по умолчанию для табличных данных используется data.table;
• все процессы построения моделей объединены в граф вычислений. В составе этого графа можно задать любую схему перекрестной проверки и ансамблирования, перебрать разные модели с тюнингом гиперпараметров для каждой из них и разные варианты предобработки;
• вместо отдельных этапов с разными API для предобработки, создания признаков и обучения модели используется learner — абстракция для модели как совокупности алгоритма машинного обучения и всех этапов трансформации данных;
• модульность и относительная простота расширения.

• стандартные проблемы пакетов на стадии активной разработки: не все фичи реализованы, местами не хватает примеров (этот недостаток активно исправляется), попадаются мертвые ссылки в документации;
• выбор поддерживаемых моделей пока что невелик.

2. Технические детали: R6-классы и пакет data.table

В основе экосистемы mlr3 лежат «нормальное» ООП, реализуемое путем использования R6-классов. R6-объекты являются изменяемыми, что позволяет работать с ними без копирования и перезаписи. Подробно изучить тему можно по официальной документации и книге Advanced R, мы же ограничимся кратким примером, позаиствованным из упомянутой книги.

Новый R6-класс создается вызовом функции R6Class() :

Имя объекта должно совпадать с именем класса — в данном случае это «Accumulator» .

У объектов есть метод new() , который позволяет создавать (или, как любят говорить настоящие программисты, инстанцировать) экземпляры класса:

Функции, заданные внутри списка при определении класса, доступны как методы у экземпляров данного класса:

R6-объекты передаются по ссылке:

Поэтому для создания копий нужно вызывать метод clone() (указав clone(deep = TRUE) для рекурсивного копирования вложенных объектов):

Это все, что нужно знать об R6 в контексте использования пакетов семейства mlr3.

Также целям устранения ненужного копирования и повышения скорости работы служит использование data.table в качестве бекенда по умолчанию (можно почитать перевод документации, недавний хабрапост Вокруг data.table и короткий обзор data.table: выжимаем максимум скорости при работе с данными в языке R). Киллер-фичей для использования в задачах машинного обучения является изменяемость таблиц data.table , позволяющая добавлять новые столбцы при помощи оператора := без перезаписи всей таблицы. Например, можно добавить столбец предсказанных значений к таблице с обучающей выборкой, не используя при этом 2х памяти относительно объема, занимаемого самой таблице. А при последовательном добавлении признаков в таблицу становится заметной еще и экономия по времени, и чем тяжелее таблица, тем экономия существеннее.

3. Основные составляющие ML-пайплайна в mlr3

Минимальный пример решения задачи машинного обучения при помощи mlr3 выглядит следующим образом:

В процессе участвуют две сущности: задача (task) и модель (learner).

Задача создается как экземпляр соответствующего класса ( TaskClassif для классификации, TaskRegr для регрессии и т.д.) путем вызова метода new() . Нужно указать идентификатор задачи id , таблицу с данными backend и целевую переменную target ; в случае бинарной классификации положительный класс задается параметром positive . Стандартные задачи можно получить с использованием альтернативного синтаксиса: mlr_tasks$get(«iris») или tsk(«iris») .

Модель извлекается из списка mlr_learners при помощи метода get() и затем обучается посредством вызова метода train() , в который передается наша задача task и строки выборки, участвующие в обучении. Но удобнее создавать модели с использованием синтаксического сахара: lrn(«classif.rpart», predict_type = «prob», minsplit = 50) . В этом случае можно сразу задать настройки модели ( predict_type = «prob» ) и значения гиперпараметров ( minsplit = 50 ). После создания модели их тоже легко поменять: learner_rpart$predict_type , learner_rpart$param_set$values$minsplit = 50 .

Обученную модель используем для предсказания на новых данных при помощи метода predict_newdata() :

Добавим кросс-валидацию с разбивкой на 5 фолдов:

Оценим качество полученной модели. Для этого вызовем метод score() у объекта с ресемплами resample_results , передав ему список из двух метрик — accuracy «classif.acc» и classification error «classif.ce» . Метрики также хранятся в списке, элементы которого извлекаются методом get() : mlr_measures$get(«classif.ce») . Но мы вновь воспользуемся синтаксическим сахаром в виде функции msrs() :

4. Настройка гиперпараметров

Осталось самое главное — произвести настройку гиперпараметров модели. Тут все немного сложнее, и вызовом одного метода дело не ограничится.

Прежде всего зададим пространство для перебора значений гиперпараметров. Этим функционалом заведует отдельный пакет paradox:

Мы сконструировали новый объект класса ParamSet , определив в нем диапазон проверяемых значений для числового параметра cp и целочисленного параметра minsplit ; остальные гиперпараметры нашей модели rpart оставим по умолчанию.

Важным моментом является то, что объект searchspace не содержит в себе никаких реальных значений. Эти значения будут сгенерированы при вызове метода tune() объекта класса Tuner . Границы диапазонов всегда включаются в набор значений. Количество проверяемых вариантов задается числом resolution , если нужно равное количество для всех гиперпараметров, или именованным вектором param_resolutions , если нужно разное количество для разных гиперпараметров. Кроме того, фактическое число проверяемых комбинаций ограничивается бюджетом на вычисления, но об этом чуть позже.

Функция generate_design_grid() позволяет получить таблицу значений гиперпараметров, по которой будет проводиться перебор:

Также реализованы другие способы генерации сетки значений: generate_design_random() для случайной выборки из диапазона и generate_design_lhs() для создания дизайна эксперимента методом латинского гиперкуба.

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

Объединим все ингредиенты в один объект класса TuningInstance :

Создадим тюнер — объект класса Tuner , реализующий ту или иную стратегию перебора значений гиперпараметров:

Мы указали resolution = 5 , что для двух гиперпараметров означает проверку 25 комбинаций. Но фактически будет проверено лишь 20 случайным образом выбранных комбинаций, поскольку мы задали terminator = term(«evals», n_evals = 20) . batch_size — неудачно выбранное название параметра, определяющего количество параллельно обучаемых моделей. Параллелизация в mlr3 — отдельная большая тема, выходящая за пределы данной статьи.

Заслуживает внимания тюнер tnr(«design_points») : он позволяет передать созданную заранее таблицу со значениями гиперпараметров, что зачастую удобнее генерации из диапазонов (особенно если нужно перебрать значений на логарифмической шкале — без готовой таблицы придется использовать достаточно громоздкий механизм преобразования параметров, который в mlr3 тоже есть).

Наконец, запустим процесс:

Как видим, result не содержит ничего. Это потому, что вызов tuner$tune() приводит к изменению объекта tuning_instance :

Рассмотрим подробнее, что именно происходит после вызова метода tune() :

1. Tuner использует как минимум один набор значений гиперпараметров (он может использовать несколько наборов в параллельном режиме в зависимости от значения параметра batch_size );
2. для каждого набора значений гиперпараметров модель Learner обучается на задаче Task согласно заданной схеме ресемплов. Результаты сохраняются в объекте класса ResampleResult (совокупность таких объектов хранится в объекте BenchmarkResult );
3. Terminator проверяет, не исчерпался ли бюджет на вычисления. Если нет, снова переходим к пункту 1, и так до тех пор, пока бюджет не закончится;
4. определяется набор значений гиперпараметров с наилучшим качеством модели;
5. сохраняются значения гиперпараметров и полученные метрики качества, усредненные по ресемплам (другие варианты агрегирования метрики можно задать при ее создании, например, msr(«classif.ce», aggregator = «median») .

Дополнительную информацию о результатах обучения моделей можно получить из объекта tuning_instance$bmr , имеющего класс BenchmarkResult , при помощи его метода score() или функции as.data.table(tuning_instance$bmr) . Что происходит на уровне отдельных ресемплов, можно понять, используя аналогичный метод для объектов ResampleResult из таблицы tuning_instance$archive() :

Например, можем добавить к таблице значения метрики качества на каждом ресемпле:

5. Обзор экосистемы mlr3

С основными пакетами мы уже знакомы: это mlr3, mlr3tuning и paradox. Вся экосистема представлена на заглавной картинке и в списке, а основные пакеты можно поставить при помощи мета-пакета mlr3verse:

• mlr3db позволяет подключать dbplyr в качестве бекенда вместо data.table.
• mlr3filters содержит алгоритмы отбора признаков, в том числе на основе встроенных в модели метрик важности признаков (пользоваться ими нужно с осторожностью).
• mlr3learners является коллекцией моделей для регрессии ( regr.glmnet , regr.kknn , regr.km , regr.lm , regr.ranger , regr.svm , regr.xgboost ) и классификации ( classif.glmnet , classif.kknn , classif.lda , classif.log_reg , classif.multinom , classif.naive_bayes , classif.qda , classif.ranger , classif.svm , classif.xgboost ). Дополнительные модели можно найти в отдельных пакетах.
• mlr3pipelines содержит пайпы (pipelines), из которых строится вычислительный граф. Кроме того, в версии на гитхабе есть и целые вычислительные графы, которых пока нет в пакете на CRAN, так что лучше поставить именно ее: remotes::install_github(«https://github.com/mlr-org/mlr3pipelines») .
• mlr3tuning был рассмотрен выше.
• mlr3viz служит для визуализации, в том числе отвечает за отрисовку вычислительных графов.
• mlr3measures — пакет с

40 метриками качества. В состав mlr3verse не входит, нужно ставить руками.

Следите за страницами по представленным ссылкам, список пакетов будет пополняться.

6. Пайпы и граф вычислений

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

Все операции — отбор признаков, преобразования, само обучение модели — абстрагируются в виде пайпов. Для моделей есть PipeOpLearner() , для отбора признаков — PipeOpFilter() , для всех остальных преобразований — PipeOp() . Мы используем синтаксический сахар (функция po() ) для всех трех случаев:

Пайпы последовательно соединяются в граф при помощи оператора %>>% :

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

Как сделать пайп из модели, мы уже видели ( po(«learner», learner = lrn(«classif.rpart»)) ). В свою очередь, граф целиком можно сделать моделью:

Получившийся объект относится к классам GraphLearner и Learner . Его можно использовать так же, как и рассмотренные выше простые Learner -ы, например:

Третьего дня была реализована невиданная ранее фича, которая обсуждалась в issue How to deal with different preprocessing steps as hyperparameters:

Рассмотренные в первом разделе caret и tidymodels так не умеют!

Надеюсь, данный пост был полезен и зародил интерес к дальнейшему изучению и использованию фреймворка mlr3. Подробнее можно почитать в книге mlr3 book и в галерее примеров.

Источник

Думаю, вы обнаружили две ошибки.
Во-первых, ваш код даже запускается, а во-вторых, это не работает с вложенной передискретизацией.

Ошибка 1: ваш код не должен запускаться

Прежде всего, mati не имеет никакого эффекта, потому что он будет перезаписан каждым внутренним вызовом bits.to.features. В конце концов, вы только что определили аргумент по умолчанию.

То, что вы определили для bit.names, «Petal» и «Sepal», вы просто сказали mlr использовать два бита.
Таким образом, выбор признаков будет работать с векторами 00, 01, 10, 11.
К сожалению, R теперь автоматически перерабатывает эти векторы до длины 4, поэтому 10 становится 1010:

mlr:::binaryToFeatures(c(1,0), getTaskFeatureNames(iris.task))
# [1] "Sepal.Length" "Petal.Length"

Здесь у нас есть первая ошибка, что mlr должен избегать повторного использования вектора здесь.

Чтобы код работал так, как задумано, вы можете определить функцию bits.to.features следующим образом:

bitnames = c("Sepal", "Petal")
btf = function(x, task) {
  sets = list(
    c("Sepal.Length", "Sepal.Width"), 
    c("Petal.Length", "Petal.Width")
  )
  res = unlist(sets[as.logical(x)])
  if (is.null(res)) {
    return(character(0L))
  } else {
    return(res)  
  }
}

res <- selectFeatures("classif.rpart", iris.task, rdesc, 
  control = ctrl, bits.to.features = btf, bit.names = bitnames)

Объяснение bts

Цитата из справочной страницы selectFeatures:

[function(x, task)]
Function which transforms an integer-0-1 vector into a character vector of selected features.
Per default a value of 1 in the ith bit selects the ith feature to be in the candidate solution.

Итак, x — это вектор, содержащий нули и единицы (например, c(0,0,1,0)).
Если вы не измените эту функцию, она вернет имя третьей функции (например, «Petal.Length» для радужной оболочки глаза). Вектор x всегда будет той же длины, что и определенный bit.names. Однако результирующий вектор символов может иметь любую длину. Он просто должен вернуть допустимые имена функций для задачи.

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

Ошибка 2: bit.names должны быть названиями функций

В результате Feature Selection возвращает битовые имена. Затем mlr пытается выбрать эти битовые имена в наборе данных, но, очевидно, их нет, поскольку они совершенно не связаны (в вашем случае).
Эта ошибка устранена в версии mlr для github.

Этот вопрос был замечен 74 раза и получил только один ответ (по состоянию на полдень (PDT), ср., 14 августа).

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

В качестве резюме мне нужен <сильный> небольшой, но полный пример на наборе данных с двоичным ответом о том, как использовать makeCostsenseSenseSenseDEdpairSeedEdParapper для получения <крепкого> прогноз вероятности на тестовом наборе.

В Учебном пособии MLR в разделе «Чувствительность к конфертированию классификации» https://mlr.mlr-org.com/articles/tuTorial/cost_sensitive_classif. html. Существует абзац на «Затраты на пример неверной передачи», и пример дан на основе набора данных IRIS.

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

library( mlr )
set.seed( 12347 )
n1 = 100; ntrain = 70
df = iris[ 1:n1, ]  # 100 points in df so as to have two classes only (setosa and versicolor)
df$Species = factor( df$Species )  # refactor the response

# partition df into a training set (70 points) and test set (30 points)
# 
ix = sample( 1:n1, ntrain, replace=FALSE )
xtest = df[ setdiff( 1:n1, ix ), ]  ## test set
ntest = nrow( xtest )
xtrain = df[ ix, ]   # this is the training set

# create cost matrix, same as in the MLR example
#
cost = matrix(runif(ntrain * 2, 0, 2000), ntrain) * (1 - diag(2))[xtrain$Species,] + runif(ntrain, 0, 10)
colnames(cost) = levels(xtrain$Species)
rownames(cost) = rownames(xtrain)

xtrain$Species = NULL   # this is done according to the MLR example

# cost-sensitive task
#
costsens.task = makeCostSensTask(id = "xtrain", data = xtrain, cost = cost )
costsens.task

##lrn = makeLearner("classif.multinom", trace = FALSE, predict.type="prob" )
lrn = makeLearner( "classif.gbm", predict.type="prob" )
lrn = makeCostSensWeightedPairsWrapper( lrn ); lrn

mod = train(lrn, costsens.task ); mod

pred = predict( mod, newdata = xtest, pred.type="prob" );

perf = performance( pred, measures = list(auc), task = costsens.task)

# I get the following error:
#   Error in FUN(X[[i]], ...) : 
#   You need to have a 'truth' column in your pred object for measure auc!

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

Цель состоит в том, чтобы сделать прогноз набора данных, получить вероятности и показать производительность (с помощью ROCR, для которых есть функции MLR-сопоставления).

Примечание. Учащиеся, которые я пробовал, — это «Classif.multinom» и (я догадался) «Classif.gbm», как два, которые могут быть совместимы с взвешенными парами.

Мои вопросы:

Q1: где в фрагменте кода и как указать, что я хочу, чтобы вероятно, как вывод чувствительного к затратке классификатора?

Q2: какой ученик можно использовать для создания вероятностей классификации?

Q3: Как избежать ошибки выше и получить вероятности классов?

Еще раз, я бы очень признателен за любую помощь, тем более, если есть кто-то, кто может ответить оперативно.

Хорошо, через несколько дней и почти сто просмотров на этот вопрос (около 20 лет 🙂 Там был только один комментарий и никаких ответов.

Из того, что я мог бы понять, исследуя некоторые доступные MLR-документации, кажется, что вывод данного показателя, чувствительный к затратным методом (MakeCostsenseDedPairswrapper) — только на этикетки, а не вероятностей прогнозирования.

Другими словами, никакие вероятности не доступны по-чувствительной к затратке, даны только новые метки, которые находятся в очереди, вычисленные на основе вероятностей базового классификатора.

Итак, этот ответ, который я приму.

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