Alver

Первый вопрос заключается в том, каковая вероятность этого если , то есть вероятность одновременного использования всего своего ресурса 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 ?

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

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

Такие пики соотношений имеют место быть. Но если усреднить эти цифры например 1000 значений в ежедневный прайм-тайм, скажем за каждый день за месяц , то получим 10/1 и даже меньше 15/1, в частности , в локациях где доступно через Интернет онлайн видео OTT. В поселках, где слабый доступ в Интернет, преобладает цифровое ТВ T2, спутник и люди видео до сих пор не смотрят онлайн, а закачивают фильмы торрентами, там другой расклад. Я не наставаю на точной цифре 10/1. Соотношение может несколько различаться в разных поселках в зависимости от качества местных каналов связи

Это математическая статистика, которую ты по всей видимости в ВУЗе не изучал, если ты вообще в техническом или вообще любом ВУЗе учился Обьясняю на пальцах. Трафик ( скорости каждого пакета ) усредняются за время передачи 2-3 секунды, как например , делается в посекундном трафике Throughput chart Cambium. Также есть параметры усреднения у MRTG, Zabbix. В часовом- суточном трафике - усреднение происходит за несколько минут. А например , у Dude Mikrotik усреднения нет, показываются мгновенные значения , полученные в момент измерения, и поэтому этот инструмент для статистич

Наверное тут нужно говорить о загрузке канала юзерами. Если канал 500М, и он загружен в прайм тайм на 450М, то юзер с тарифом 100М измерив тестом, скажем OOLA Speedtest , свою скорость , не увидит свой тариф и будет возмущаться. Также он не сможет прокачать скажем торрентом 100М, и будет возмущаться еще больше. Также следует обратить внимание на cуществование ограничений скорости TCP в одном потоке. Это важно при простом html browsing , когда картинки загружаются браузером в один TCP поток. Также это ограничивает скорость загрузки FTP. В радио она отличается у ра

Тариф определяет только максимальную скорость в канале, но никак не загрузку канала трафиком. То есть статистически среднее потребление трафика юзером в прайм -тайм не зависит от размера его сервис-тарифа , например 100М или 1 Гиг. Такая зависимость есть, если у юзера шейп от провайдера скажем в 5 Mbps ( при этом для HD TV нужно 8 Mbps) или если у юзера есть технологические ограничения, скажем он работает на беспроводном ШБД типа Микротик или Ubuitity 802.11n по технологии 10 летней давности, и ограниченными возможностями по скорости 2-3 Mbps, до 5 Mbps в burst . В таких сл

Трафик видеонаблюдения замыкается на видеорегистаторах и не идет в аплинк канал в Интернет. Если конечно этот трафик не пишется в облако, что стоит денег. Но таких сетей немного и они сильно не искривляют профиль трафика в алинке.

Если цель - показать что на интерфейсе возможен случай когда всегда in=out, то такой скрин сгодится Если же цель - подобрать по скорости для аплинка в поселок оборудование, работающее по протоколу TDD, то следует смотреть на типовой профиль трафика доступа в Интернет сотен юзеров типа хомячок. Нужен трафик не корпорейтов , не систем видеонаблюдения, не серверов OTT/IPTV, не с хранилищ облачных и других сервисов, не 3G/4G, а именно трафик хомячков при доступе в Интернет. Такой типовой профиль трафика существует, он получен статистически по анализу сотен аплинков

Ваши скрины трафика, которые хотя и реальные, но не имеют отношения к теме и конкретному вопросу. Но у меня больше претензий к скрину 100% симметричного трафика другого человека , где вообще какой то невразумительный луп, что не объясняется даже корпоративной принадлежностью линка и профилем трафика видеонаблюдения. С этим другим человеком я вас и перепутал. Поэтому адресованное вам - ты **** , отзываю :). Сорри.

Не знаем мы цен, это сам Камбиум не знает еще. Но мы исходим из цен платформы Force 400C ( под внешнюю антенну) на Qualcomm -Atheros WiFi 6. Поэтому цена Force 600 Qualcomm -Atheros WiFi 6 в Украине будет ниже $500 . А вот стоимость внешних антенн 6 Ггц может быть завышена. Однако будет Force 600-25 с интегрированной антенной 6ГГц 25 диш примерно в ту же цену, что и Force 425 -также ниже $500

Это я написал хрень про вайфай и его применение ? Ты ***** . Ну не мы же узаканиваем, а НКРЗ. Работаем над вопросом, все решат правильно. Но сроки - х.з..