> Вайфай в зоне покрытия работает нормально, ад начинается только когда вы на
> границу выходите, и всё разваливается. Но вайфай и не для того вообще...А эти речи выдают дилетанта. Который про интерференцию, поляризацию, отраженку, и прочие глупости типа SNR не слышал, и даже просто врубить нормальный показометр, хотя бы уровня "iw dev wlan0 station dump" в цикле - явно не допер. В атерос дебаге есть и поинтереснее если знать на что смотреть, но для начальной оценки хватит и вон того.
Про то чтобы попытаться закартировать как поле выглядит, и тем более что случается если еще и вертеть гаджет или двигаться с ним - речь, видимо, совсем не шла. Иначе вы бы побоялись выдавать такие заявления. Потому что уровень сигнала может измениться в десятки раз от перемещения на считанные сантиметры, длина волны у вафли такая. С соответствующим улучшением или ухучшением линка. А учитывая что руки юзера не особо прозрачные и параметры антенны гаджета сбивают, даже просто перехватить гаджет в руках может радикально изменить всю картину. Представляете, руки могут например резонансную частоту антенны увести хзкуда - ну а как работает антенна резонирующая на частоте отличной от рабочей? Правильно - крайне голимо.
Это довольно странно для человека знающего про статистику атероса. Видимо, прочли ридмишку от такого же эксперта в интернете, уперлись рогом в 1 параметр и айда в интернете бред форсить. А почитать теорию коммуникаций, азы RF и проч - да, блин, это не ридмишка на 10 минут...
А зона покрытия - это такое весьма эфемерное и абстрактное. Ну то-есть можно задать максимум таймаута соответствующий энному расстоянию от AP, и все что сильно дальше будет отпадать по таймаутам. Но выбор между хреновым линком и никаким - такое себе, так что это редко вклчают. А в типовой хате можно найти мемало мертвых зон и неудачных локаций, где когда я сижу на диване вот так, путь от меня до роутера для сигнала - метр бетона. И никакая магия через метр бетона 2.4 и тем более 5 гигагерц не протолкнет. В лучшем случае немного пересесть, или может отраженка какая поймается другой антенной, если она есть, что для мелкого гаджета совсем не факт, но... всегда есть риск что вот тут линк просто возьмет и просто просядет в хлам. А потом отплющится.
> Тут кажется был раньше человек которые эти вайфаи для пром применения настраивал,
> от стадионов до совсем извращённой ерундой в промышленности.
У вас дома этого человека явно не было - и его оборудования тоже. И инфраструктуры под вот это все, с именно эн грамотно размещенных в правильных местах точек - у вас тоже нет. И в планирование радиоканалов вы точно не вхожи. Иначе зассали бы вон то выдавать, понимая что стадион и дом это 2 довольно больише разницы. Вон то подразумевает и правда сервировку ограниченного сегмента, бэкбон, а также нехилое изучение того что получилось оперируя -dBm и числом клиентов которые туда или сюда цепляются. В вафле так то даже есть технологии для роуминга клиентов на соседнюю точку доступа с тем же SSID. Но вы врядли этим всем пользуетесь, это специфичного сетапа требует. И не все клиенты и точки это умеют и тем более на 100% интероперабельны.
> Мобильные сети да, в них всякая жесть бывает. Но я бы больше
> с ней работал через разработку приложений устойчивых к дисконекту,
Как вы это себе представляете для допустим видео с ютуба? Поток либо идет, либо нет. И если канал используется на единицы процентов по причине "TCP тупит" вот у гугла и возникает желание улучшить это состояние дел. А пропатчить TCP в винде они совсем отчаялись. В результате море претензий к их хостингу на ровном месте, им это не надо - так что вот вам UDP, где гугл сделает так как сочтет нужным для себя. На спрашивая вас и майкрософт вообще.
> чем пытаясь изобрести особый стриминговый протокол устойчивый к такой жести.
Народ едущий в транспорте совсем не прочь посмотреть вон тот клип. Предлагается им рассказать что это работать не должно, пусть TCP тупит во имя луны? Это не путь гугла, там могут и нанять нормальных инженеров. Оттуда же и респин дизайна bbr когда он пытается детектировать подобные вещи и не считать это за вот именно перегруз. Остуствие соты - это не перегруз сети. Это мертвая зона покрытия, временная потеря линка и проч.
> Переключение между сотами у вас всерано не каждую секунду происходит.
В быстро едущем транспорте может быть нечто довольно близкое к этому. Если попалась мертвая зона где сигнала нет - то чего? Хоть тресни но ничего не пошлешь и не примешь. И если TCP начинает брыкаться на это таймаутами по минуте - возникает спрос на то чтобы его уйти, раз это фиксу не подлежит.
>> Гугол тоже может в нормальных инженеров
> Последнее время не очень.
И все же остатки былой роскоши - есть. И они выдают более разумные спичи чем вот тут попалось.
> Стабильность обеспечивают протоколы ниже сетевого.
Если демодуляция при энном соотношении синал-шум лажается, никакие протоколы с этим таки ничего сделать не могут. А вон там в низине - сигнала можно считать что совсем нет. Потому что радиоволны на тех частотах летают более-менее по прямой, как свет, через некоторые препятствия они проходят - но ослабляясь, и вот именно земля, особенно мокрая, к таким препятствиям не относится. И на этот эффект даже дома можно нарваться, там все "планирование" сводится к относительно удачному размещению роутера в не очень глупом месте. А уж на улице с рельефом "уж какой есть" - даже профессионалам много головной боли с дырами в покрытии. А если еще и ехать, там еще вопрос как алгоритмы БС и конкретной мобилы дружить будут. Что угодно может быть.
> Потеря пакета на сетевом уровне это ситуация, в идеальном мире, всегда нештатная,
> независимо от среды. Хотя конечно бывают нюансы.
Если некто вон там на авто в тоннель заскочил - ну и где он сигнал возьмет? Не пробивают радиоволны почтенные слои земли. А ставить соты и излучающие кабели под каждую плевую трубу и мост - никаких денег не хватит.
> А как вообще управление пропускной способностью происходит? По хорошему роутер
> должен сообщать источникам пакетов о том что у него затык, да и свитч
> должен, хотя к нему спроса меньше, ну не может такого быть
> чтобы не было такого механизма?
А вот этим всем как раз congestion control и занимается, и там с этим тот еще разброд и шатания. В TCP есть ECN но это как я понимаю не решает проблему полностью. Роутер не знает что через секунду линк станет ЗБС например. А если TCP уже ушел в таймауты по 60 секунд - ну и кто б его знает что там через 60 секунд случится. Ютуб с горя отращивает ломовой буфер, пытаясь в некий адаптив на уровне вообще - плеера. Каналам похуже - поток потоньще, дроп буфера - уйдем ан 360p тощий, вероятнее что пролезет. Встряло? Откроем новый конект чтоб не ждать минуту. У них очень крутой, комплексный антилаг и адаптив + оптимизация потока по жирноте VP9/AV1. И никто ничего сравнимого не смог. Поэтому и икают в разы больше - и не могут всерьез конкурировать.
