Alver

Ну так я и сравнил два поколения 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МГц цифра другая. Но это все имеет чисто теоретическое значение. Мы говорим об аплинке в поселок с несколькими сотнями юзеров в ка

Я сказал, что это важно ... когда картинки html грузятся в один TCP поток. Но на самом деле HTTP может обслуживать несколько потоков TCP.

Я что сказал, что скорость FTP даже в одном TCP потоке не может быть 150МБ/с или 900 Mbps ?

Повторяю, если радиоканал или шейп по оптике достаточной емкости и не ограничивает по скорости юзеров.

От этого не зависит, если радиоканал или шейп по оптике достаточной емкости и не ограничивает по скорости юзеров.