Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Оптимальная длина пакета.
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Вопросы системного уровня проектирования
JohnKorsh
Добрый день! Не встречал ли кто статьи или любые материалы по следующей теме.
Пусть есть канал передачи двоичных данных с шумами.
Данные передаются пакетами длиной n бит. В пакет добавляется служебный заголовок длиной s бит.
Общий объём данных l ограничен.
Пакеты передаются с подтверждением. При отсутствии подтверждения передача пакета повторяется.
В зависимости от длины пакета будет изменятья средняя скорость передачи данных. Думаю, для уаждого соотношения
сигнал/шум существует оптимальная длина пакета, по критерию минимума времени передачи общего объёма данных l.
Хотелось бы найти формулу, определяющую эту оптимальную длину пакета n в зависимости от с/ш, и, видимо, размера заголовка пакета s.
soldat_shveyk
Помимо шумов в реальном канале связи длина пакета зависит от других факторов - например от многолучевости в КВ-радиоканале.
Даже если по шумам все хорошо, то нельзя уменьшать длину ниже некоторого значения - смажутся соседние пакеты.
Если у Вас идеальные теоретические условия, то пляшите от Шеннона, все получится из этой формулы.
V_G
Цитата(soldat_shveyk @ Jul 22 2011, 17:24) *
Даже если по шумам все хорошо, то нельзя уменьшать длину ниже некоторого значения - смажутся соседние пакеты.

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

В практическом плане предпочитаю по радиоканалу передавать пакеты по 6 байт + 2 байта контрольной суммы, позволяющей исправлять до 3 битовых ошибок, расположенных в пакете произвольно (КС-условное название). Лично я исправляю табличным способом 2 произвольные ошибки. Все это ведет историю от транкового протокола MPT1327, так и использую. Но у меня канал чаще всего командный, динных посылок не требуется. 128 байт максимум, которые я и разделяю на куски по 6 байт, добавляя в каждый кусок по 2 байта КС.
Lmx2315
Цитата(V_G @ Jul 22 2011, 11:19) *
Не понял утверждения, что значит смажутся соседние пакеты? Это вы какой-то конкретный протокол имеете в виду?
В общетеоретическом смысле при ожидании подтверждения приема пакета никакого смазывания быть не может.


..зависит от типа вашего канала :

Аддитивный канал Гаусса: (Прямая видимость, нет отраженных сигналов).
Канал Райса: (Прямая видимость, есть отраженные сигналы).
Канал Релея: (Нет прямой видимости, прием только отраженных сигналов).

Если у вас канал первого типа то кроме шума проблем нет. Если какой другой - то ваши пакету будут накладываться друг на друга и смазываться.
Dr.NoA
Хочу заметить, что в исходном вопросе речь не шла именно о радиоканале. Но даже в случае с радиоканалом с медленными и быстрыми замираниями все можно свести к вероятности битовой ошибки, поэтому это не меняет постановки задачи.

А теперь по теме. Я таких статей не видел, но не вижу проблемы самому это посчитать. Если передается пакет данных длиной d бит, а в ответ должен быть получен пакет подтверждения a бит, то матожидание числа переданных пакетов данных до тех пор, пока не будет получено подтверждение об успешном приеме, равно
m(d)=1/[(1-btx)^d*(1-brx)^a], где btx - вероятность битовой ошибки при передаче пакета данных, brx - вероятность битовой ошибки при передаче пакета подтверждения.
В этой формуле предполагается, что не используется специальное кодирование двоичных символов, а количество попыток передать пакет данных бесконечно.

Если требуется передать суммарно D бит, то они будут разбиты на D/d пакетов длиной d бит. Тогда общее среднее число переданных пакетов данных равно
M(d)=Dm(d)/d

Ваша задача сводится к поиску минимума функции M(d). Если я не ошибаюсь, то оптимальная длина пакета данных равна
dopt = -1/ln(1-btx)

Если выразить btx через зависимость от отношения сигнал/шум, то вообще получите искомую формулу.
JohnKorsh
Спасибо, Dr NoA. Очень помогло.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.