Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
1. «Вероятность сброса пакета» — это вероятность того, что пакет не будет доставлен до получателя. Правильно? Если да, то почему при 1 скорость не равна 0?
2. «Министерские 10^-3 выглядят очень грустно.» Если посмотреть на графики, то утверждение несколько странное. Для 10^-5 у вас результаты не преведены, похоже, что они такие же, как и для 10^-4, да? (Ну и скорее всего у вас на радио было 10 МГц канал с МИМО 2х2. Если так, то значения при 10^-4 уже близки к максимальным) Так вот разница, на глаз, между 10^-3 и 10^-4 максимум 10% в средней скорости. А в большинстве случаев и того меньше. 10% на слово «очень» как-то не тянут. Было бы 50%, или хотя бы 30% — другой разговор.
2. «Министерские 10^-3 выглядят очень грустно.» Если посмотреть на графики, то утверждение несколько странное. Для 10^-5 у вас результаты не преведены, похоже, что они такие же, как и для 10^-4, да? (Ну и скорее всего у вас на радио было 10 МГц канал с МИМО 2х2. Если так, то значения при 10^-4 уже близки к максимальным) Так вот разница, на глаз, между 10^-3 и 10^-4 максимум 10% в средней скорости. А в большинстве случаев и того меньше. 10% на слово «очень» как-то не тянут. Было бы 50%, или хотя бы 30% — другой разговор.
1. Да, правильно. Графики подписаны в процентах, т.е. 1 — это 1%, или 10-2.
2. Приказ 113 требует (переведу на язык своих графиков) 0,1% потерь. Что обеспечит максимальные абонентские скорости 40 Мбит/с. Маловато. А вот следующий шаг в виде 0,01% потерь уже обеспечит почти максимальные скорости для реальных абонентов. Достичь же следующей ступени в 0,001% потерь не всегда возможно в условиях большой территории.
2. Приказ 113 требует (переведу на язык своих графиков) 0,1% потерь. Что обеспечит максимальные абонентские скорости 40 Мбит/с. Маловато. А вот следующий шаг в виде 0,01% потерь уже обеспечит почти максимальные скорости для реальных абонентов. Достичь же следующей ступени в 0,001% потерь не всегда возможно в условиях большой территории.
А можете поделиться технологией эмуляции дропов пакетов?
И проводили какой то анализ собственно радио части — почему такой небольшой процент дропов на транспорте влечет огромный провал скоростей на радио?
И проводили какой то анализ собственно радио части — почему такой небольшой процент дропов на транспорте влечет огромный провал скоростей на радио?
По дропам — есть малозаметная ссылка в тексте на traffic contol. Но чуть более детально всё-таки здесь: Netem.
По второй части вопроса — тут уже сложнее. Конечно очевидно что дело в протоколе транспортного уровня. Для исправления ситуации нужно менять алгоритмы/параметры на оборудовании (EPC, eNodeB), а это уже больше зависит от производителя. Пока никаких изменений в этом направлении не было.
tc qdisc add dev eth0 root netem loss 0.1% delay 100mcобеспечит 0,1% потерь и 100 мс задержки.
По второй части вопроса — тут уже сложнее. Конечно очевидно что дело в протоколе транспортного уровня. Для исправления ситуации нужно менять алгоритмы/параметры на оборудовании (EPC, eNodeB), а это уже больше зависит от производителя. Пока никаких изменений в этом направлении не было.
Я соврал по второй части. Трафик от EPC до eNodeB передается в gtp-u, который использует UDP. Там получается инкапсуляция исходного абонентского пакета (у которого в протоколе транспортного уровня может быть что угодно) в тот самый gtp-u, использующий UDP.
Похоже что крутить настройки EPC/eNodeB бесполезно — нужно менять настройки TCP (или что там используется если у этого есть параметры) сессий между источником и получателем трафика (контактик-абонент например).
Подробности тут.
Похоже что крутить настройки EPC/eNodeB бесполезно — нужно менять настройки TCP (или что там используется если у этого есть параметры) сессий между источником и получателем трафика (контактик-абонент например).
Подробности тут.
Так вроде как радио тут не при чем. Если взять просто S1 (eNB-SGW) часть и повторить эксперимент, то результат должен быть примерно таким же. Или вам кажется по-другому?
Если честно, то не очень понимаю что вы предлагаете. Вернее догадываюсь, но не представляю как это сделать — абонентских устройств, понимающих gtp-u нет, а тестировать просто передачу UDP трафика неинтересно — результат заранее известен. Или я неправильно вас понял?
Тут самый сок как раз в инкапсуляци клиентского трафика с TCP в пакеты с UDP и проблемами как раз на уровне клиент-сервер из-за протокола L4 (TCP например) того самого инкапсулируемого пакета.
Могу ошибаться, прошу поправить если где накосячил…
Тут самый сок как раз в инкапсуляци клиентского трафика с TCP в пакеты с UDP и проблемами как раз на уровне клиент-сервер из-за протокола L4 (TCP например) того самого инкапсулируемого пакета.
Могу ошибаться, прошу поправить если где накосячил…
Мой комментарий относился к «И проводили какой то анализ собственно радио части — почему такой небольшой процент дропов на транспорте влечет огромный провал скоростей на радио?»
Мне кажется, что пробовать что-то на радиоинтерфейсе смысла нет, т.к. ошибки на S1.
Мне кажется, что пробовать что-то на радиоинтерфейсе смысла нет, т.к. ошибки на S1.
Пробовать на радио нужно и обязательно. Поскольку на S1 все уже измерено с помощью сервака включенного в разрыв, он собственно и сэмулировал объем и качество трафика проходящего через S1, и контролировать здесь мы можем L2/L3 уровни.
А абоненту который пользуется LTE с модема или телефона, неважно какие у нас скорости в S1, ему важно какую полезную информацию он получает на экран своего устройства, то есть уровни L4 и выше. Объем же именно этой информации (собственно пользовательских данных) как раз и проваливается при увеличении Drop Rate. Очевидно что копать нужно в алгоритмах пере-отправки данных на радиоинтерфейсе, при потере пакетов.
Когда появится время мы попытаемся соорудить лабу для такого анализа у себя.
А абоненту который пользуется LTE с модема или телефона, неважно какие у нас скорости в S1, ему важно какую полезную информацию он получает на экран своего устройства, то есть уровни L4 и выше. Объем же именно этой информации (собственно пользовательских данных) как раз и проваливается при увеличении Drop Rate. Очевидно что копать нужно в алгоритмах пере-отправки данных на радиоинтерфейсе, при потере пакетов.
Когда появится время мы попытаемся соорудить лабу для такого анализа у себя.
Не понятно чем тут может помочь радиоинтерфейс, если потери на S1.
Если пакет не долетел до радио, то радио ничего не сможет сделать. То есть ему переотправлять нечего (как и просто отправлять).
То, что интересен объем трафика на Л4 — тут сомнений нет (я бы даже сказал, что Л4 в стеке протоколов пользователя, а не на Л4 на S1 интерфейсе. Это несколько разные вещи). Только этот объем определяется каждым участком сети, а не только радио. И если пакеты пропадают на S1 (я так понимаю, что пропадают-то в любом случае Ethernet пакеты на этом интерфейсе. А это как раз Л2), то логично с ним и разбираться (аналогия со смесителем в ванной и входным краном от стояка. Если этот входной кран у вас закрыт, то как вы смеситель ни крутите — толку не будет, так как до него вода не доходит. Так и тут).
Я так понимаю, что в экспериментах выше использовался TCP. Было бы еще интересно посмотреть на UDP. Ожидаю, что у него результаты могут быть получше.
Если пакет не долетел до радио, то радио ничего не сможет сделать. То есть ему переотправлять нечего (как и просто отправлять).
То, что интересен объем трафика на Л4 — тут сомнений нет (я бы даже сказал, что Л4 в стеке протоколов пользователя, а не на Л4 на S1 интерфейсе. Это несколько разные вещи). Только этот объем определяется каждым участком сети, а не только радио. И если пакеты пропадают на S1 (я так понимаю, что пропадают-то в любом случае Ethernet пакеты на этом интерфейсе. А это как раз Л2), то логично с ним и разбираться (аналогия со смесителем в ванной и входным краном от стояка. Если этот входной кран у вас закрыт, то как вы смеситель ни крутите — толку не будет, так как до него вода не доходит. Так и тут).
Я так понимаю, что в экспериментах выше использовался TCP. Было бы еще интересно посмотреть на UDP. Ожидаю, что у него результаты могут быть получше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы тестировали зависимость скорости LTE от параметров S1