Alver

За 20 минутное выступление -$ 5 тыс ?

Насчет LTE Микротик. То что Микротик сам сделал- есть клиенткое устройство CPE. Много технологического ума и денег на его производство не нужно. Микротик даже не покупал Reference Design 4G LTE ( это очень дорого), дождался когда появились open source LTE клиентские драйверы и слепил LTE CPE девайсы из платы ( Router Board), что у них есть ( делают ODM китайцы ) , софта (Router OS)- тоже есть, и радиомодулей LTE , что у Микротик также есть - китайский OEM. Есть у Микротик и базовая станция LTE, но она есть OEM , то есть Микротик дал только свою лейблу, упаковку и до

В точка-точка для аплинк в поселок до1 Gbps на радио WiFi6 и 2.5 Gbps на Wi-Fi6E уже предпочтительней оптики в грунте по лесам, полям и рекам или по дорожным столбам. Что касается доступа, то вот спецификации новейшего Fixed Wireless Access ePMP 4000 на базе wifi 6E, презентация которого прошла несколько дней назад на конференции WISPAPALOOZA 2021.

У реелек есть только одно преимущество -чистый , свободный от помех, диапазон частот выше 6 ГГц. Все остальное -FDD и др.- этого ничего для доступа в Интернет конечных юзеров типа хомячок не надо , что в теме, собственно, и обсуждается. WiFi6E работает в в релеечном дипазоне 6Ггц, вплоть до 7125 МГц. Там нет помех и поэтому например , Cambium Force 600 по цене ниже $500 дает 2.5 Гиг, по качеству и надежности ( больше поднесущих и не обязательно наличие LOS ), по количеству ошибок в BER канала сопоставим с релейкой 2+0 XPIC по цене более $10k. Так что раскл

Ну так я и сравнил два поколения 802.11n WiFi 4 и 802.11ax WiFI 6E при одинаковой пропускной способности канала. Ответ в 10 раз вырастит скорость загрузки одной страницы. Что непонятного ?

А я что говорил, что сетевому оборудованию нужно определять трафик от одного юзера или нескольких? У меня есть аргументы. А у тебя их нет, вообще нет. Твои высованные из пальца заключения не соответствуют практике работы сетей. Это не имеет значения. Это все равно что спросить а сколько в НС провайдеров?

Конечно только на TCP, потому только у него есть ACK. У UDP их нет, поэтому у него именно этих ограничений нет, но есть другие. Других протоколов на траспортном уровне cети нетю Ну так запас 500М больше максимального 100М, что есть у большнства юзеров. У меня тариф 1000М, но я попросил его мне дать без претензий с моей стороны. Но с каналом 1 гиг давать тариф 1 Гиг конечно нельзя. Нет никакого противоречия. У тебя с логикой туго?

HTTP работает по TСP, OTT сервис -TCP, большинство приложений в Интернет работает по TCP. Раньше много лет назад видео было преимущественно в UDP, сейчас - большинснтво на TCP. В HTTP запросе каждый фрагмент HTML - текста, jpeg фото, png графики, webm или H.264 видео закачиваетя в один поток TCP. Однако эти фрагменты одной HTML страницы могут браузером ( зависит от него) загружаться паралельно, то есть в несколько потоков TCP. Также в OTT видеофайл разбивается на фрагменты, которые закачиваются паралельно каждый фрагмент одним TCP потоком, но в сумме получается многопоточная зак

Провайдер имеет 500М запаса при тарифах в большинстве 100М. 1 Гиг конечно он не может давать, потому что у него нет запаса 1 Гиг, и поэтому этот тариф я в прайм-тайм от него не получаю. Но он дает этот тариф, и я без претензий, что я его не получаю в прайм-тайм. Такой канал у меня для других целей. А для тарифа 100М у моего провайдера нормальный ( хороший) запас , и 1 гиг может у меня единственный из 300 его клиентов. И поэтому у всех все работает нормально. А вот ЕСЛИ нет запаса ( а такой провайдер у нас есть в доме, его канал загружен в прайм-тайм в полку ), то домовой т

Так я и так в прайм-тайм не получаю свой 1 гиг. И не получу его при загрузке канала торрентами. Торренты ( если TCP) 1 ) не вытеснят трафик других клиентов и с ними ничего не случится, а займут этот самый запас потенциально в обьеме доступных в прайм-тайм 500М. 2) Сам по себе торрент даже в несколько закачек не сможет занять даже эти доступные 500М, потому что скорость торрента ограничивается самым узким горлом на трассе от источника до получателя, а емкость этого узкогог горла далеко не 500М. Даже у меня до UA-IX несколько км по оптике максимальная утилизация канала торрентом не превыша

То что торрент работает в том числе на отдачу, это известно. Насчет утилизации трафика качком. Вот у меня многоквартирный дом. У моего провайдера по оптике в дом заходит 1 Gbps и раздается по витой паре 100/1000M Ethernet на 300+ квартир. У меня канал 1 Gbps за 200 грн. У большинства других юзеров -100М за 150 гривен. Я свои 1 гиг получаю только глубокой ночью. В прайм-тайм до 500М, поскольку остальные 500М из 1 Гигового канала заняты другими юзерами моего провайдера. Спрашивается, сколько я утилизирую свой 1Гиг канал и 1 гиг аплинк провайдера в наш дом, если з

Вопрос разделения доступа к среде передачи данных в малтипойнт вайфай давно решен. На BWA WiFi 4/5 с помощью TDMA, на чистом WiFi 6- OFDMA.

Мы расматриваем только прайм-тайм с 19.00-до 22.00

Первый вопрос заключается в том, каковая вероятность этого если , то есть вероятность одновременного использования всего своего ресурса 100М двумя, тремя, .... 50, 100 юзерами. Второй вопрос, а какова вероятность использования этими юзерами не всего 100М своего ресурса, а 90М, 80 М, 70 М и тд. Если известны эти вероятности, то параметры закона распределения случайного процесса - загрузки канала трафиком можно посчитать, а сам график закона распредения точно нарисовать. Но мы не знаем вероятностные цифры по каждому юзеру, поэтому пойдем от обратного. Мы знаем, что исходя

А я вот не понимаю твоей логики. Расчеты простые как угол дома. 300 хомяков, на вход DL потребляют до 450-600М, на UL выход 10% от DL - примерно в среднем 50М. Потребная труба 600+50=650 М. Запас 100М на OOKLA speedtest, он симплескный , поочередно на вход и выход , поэтому запас 100М добавляется и на вход и на выход -к сумме UL+DL .Итого, требование к пропускной способности TDD канала с адаптивным делением UL/DL = 650+100= 750Mbps UL+UL. Что тут можеь быть непонятного ? И неправильно к UL 50M добавлять 100 М запаса в виде максимального тарифа 100М, получая какую

Хочешь пообщаться оффлайн-приезжай. Кто я и где я ты, если в теме, должен знать. Встретим гостеприимно :).

Ну так сами видите, что чем больше юзеров и больше трафик, тем адекватней статистическая оценка параметров трафика и ближе статистика к цифре DL/UL =10/1. Причем average DL/UL без шейпа 47.34/3.64=13/1 примерно соответствует average DL/UL =13.58/1 с шейпом, то есть , как я и говорил не зависит от тарифа. Но максимальные значения трафика без шейпа конечно выше, но на усреденную статистику они не влияют. ЗЫ Эти скрины сразу бы и показали. Не было бы дебильных вопросов , высосанных из пальца претензий от всяких разных чудил.

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

Реальный трафик то не превысит, но запас нужен для других целей- для возможных тестов юзера. Это запас +50-100М- его давать не обязательно . Но лучше запас так не помещает это дать. Но не в три раза больше max загрузки канала.

Так я говорю об Upload трафике, они это потребляют и им не ограничивают это потребление трубой 55М. Я совершенно четко и однозначно выше это описал. И Upload / Download я не распределяю и не ограничиваю . Я имею статистическую оценку такого распределения на практике и исходя из этого расчитываю потребную емкость трубы.

Опять кто сказал что 300 юзеров генерят стабильно 50 Mbps ? Они генерят до 450 Mbps - max 600 Mbps DL в течении 3 часов в прайм-тайм. При этом у всех юзеров тариф может быть 50-100 Mbps . Для этих 300 юзеров нужна труба max 650 Mbps DL+UL плюс запас в размере максимального тарифа 100М, на случай, если кто из юзеров в прайм -тайм измерит свою скрость, то увидит эти свободные и доступные ему 100М. Всего требуется труба ( аплинк канал ) емкостью 700 Mbps. Это называется канал достаточной для 300 юзеров емкости. При этом не исключено , что несколько из этих 300 юзеро

Так я привел негативный пример как не надо делать. Ты с чего то приписал его мне и с этим борешься.

Если для юзера нет шейпа, то он независимо от того достаточно емкости аплинка или недостаточно, имеет возможность загрузить аплинк и свой канал до провайдера по полной. Если найдется такой юзер, который будет пользоваться такой возможностью постоянно и продолжительное время, тот он конечно может сильно загрузить канал в ущерб другим юзерам , что видно будет по превышению среднестатических показателей загрузки канала и профиля трафика. В этом случае такому юзеру нужно 1) поставить шейп скорости 2) ограничить количество его TCP/UDP сессий 3) проверить не использ

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

Такой цифры одной на все случаи -нет. Есть цифра максимально 500Мbps в один TCP поток на радио 802.11ax на 1024QAM в 80МГц. В 5 TCP потоках - max 950Mbps. Это значит , что при HTTP браузинге при использовании браузером протокола загрузки файлов в один TCP поток , а также FTP c одним TCP потоком ( но FTP не всегда однопоточные ) скорости больше 500М на одного юзера на радио 802.11ax в канале 80 МГц получить нельзя. В канале 160МГц цифра другая. Но это все имеет чисто теоретическое значение. Мы говорим об аплинке в поселок с несколькими сотнями юзеров в ка