Alver

Первый вопрос заключается в том, каковая вероятность этого если , то есть вероятность одновременного использования всего своего ресурса 100М двумя, тремя, .... 50, 100 юзерами. Второй вопрос, а какова вероятность использования этими юзерами не всего 100М своего ресурса, а 90М, 80 М, 70 М и тд. Если известны эти вероятности, то параметры закона распределения случайного процесса - загрузки канала трафиком можно посчитать, а сам график закона распредения точно нарисовать. Но мы не знаем вероятностные цифры по каждому юзеру, поэтому пойдем от обратного. Мы знаем, что исходя из природы возникновения и поведения случайного процесса скорости загрузки канала от сотен независимых юзеров cам закон распределения этой скорости как случайной величины подчиняется Релевскому закону. Поэтому мы, сняв статитистику поведения загрузки канала в течении скажем нескольких недель или месяцев и полагая, что это закон распределения Релея, мы методами математической статистики можем дать статистическую оценку его параметрам и в частности дать ответ Бульбе , что вероятность того, что 1-2 человека решат одновременно в течении какого продолжительного времени ( от которого все остальные юзеры станут плакать, а это время еще надо тоже оценить) решатся использовать все свои 100М - составляет, например, 1%. Поэтому вероятность ответа на первый вопрос - этого если , напаример, 1 % , а вероятность что остальным юзерам придется при этом плакать , то есть канал просто упал, например 0.1%. Удовлетворяет такая вероятность юзеров и провайдера при подаче канала - трубы емкостью 750Мbps для 300 юзеров с тарифами 100М? Думаю , что да. Если же для кого то ответ нет, и есть требование чтобы верятность эта была 0,01%, то тогда расчеты покажут, что для 300 юзеров нужна труба, например, 5 Gbps . Стоит ли эта низкая вероятность падения канала потребного для 300 хомячков 5 гигового канала и соответствующих денег? Если стоит и эти деньги у вас есть, то вперед и с песней !:) ЗЫ Вообще задача посчитать потребную емкость канала X для определенного количества Y юзеров с тарифами Z cуществует с момента появления Интернет. Никто же не будет полагать, что должно быть X=У*Z !!!. Есть теоретическая методика расчета с учетом коэффициента переподписки К , например, К = 5 или 10. То есть X=У*Z/K. Где К определяется эмпирически из практики. Есть полностью более точная эмпирическая методика, про которую я расказал выше.

А я вот не понимаю твоей логики. Расчеты простые как угол дома. 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М, получая какую то непонятную херню , что в три раза типа больше непонятно какой именно моей статистики? 100М добавляется к сумме UL+DL 650 M = 750М, а не по отдельности к UL или DL.

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

Ну так сами видите, что чем больше юзеров и больше трафик, тем адекватней статистическая оценка параметров трафика и ближе статистика к цифре 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 юзеров будут использовать кратковременно ( скажем несколько минут) в случайные моменты времени свой канал на максимум с загрузкой 100М. При этом это не изменит статистическую картину загрузки аплинк канала 450-600 Mbps. Потому что статистически вероятность совпадения моментов времени такой полной загрузки 100М от одновременно нескольких кратковременно работающих юзеров из всех в количестве 300 - мала. Если же найдется хомяк-чудик, который на все 3 часа прайм-тайма загрузит СВОЙ канал на 100М ( что вообще сделать непросто ) и таки изменит статистическую картину загрузки аплинка трафика в прайм- тайм в поселок, то на него обратят внимание, и на следующий раз примут меры, чтобы такого больше не делал. И какой такой частный случай когда я , по твоим словам на всех юзеров выделил трубу 55 Mbps ? С чего ты это взял ? Я такого не делал. Ты в своем уме?

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

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

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

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

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

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

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

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

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

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

Наверное тут нужно говорить о загрузке канала юзерами. Если канал 500М, и он загружен в прайм тайм на 450М, то юзер с тарифом 100М измерив тестом, скажем OOLA Speedtest , свою скорость , не увидит свой тариф и будет возмущаться. Также он не сможет прокачать скажем торрентом 100М, и будет возмущаться еще больше. Также следует обратить внимание на cуществование ограничений скорости TCP в одном потоке. Это важно при простом html browsing , когда картинки загружаются браузером в один TCP поток. Также это ограничивает скорость загрузки FTP. В радио она отличается у разного вайфай. У 802.11n скорость в одном потоке менее 100Мbps, у 802.11ac -300+ Mbps , 802.11ax - больше 500 Mbps. У кабельных каналов такие ограничения также есть, и они определяются сетевыми устройствами. Именно поэтому при тестировании каналов трафиком TCP рекомендуется использовать не менее 5 TCP потоков.

Тариф определяет только максимальную скорость в канале, но никак не загрузку канала трафиком. То есть статистически среднее потребление трафика юзером в прайм -тайм не зависит от размера его сервис-тарифа , например 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, а именно трафик хомячков при доступе в Интернет. Такой типовой профиль трафика существует, он получен статистически по анализу сотен аплинков в небольшие поселки ( каналов связи на оптике или радио , что именно для профиля трафика не значения ) от точки выхода магистральной оптики и имеет следующией параметры; - максимальная Download скорость в прайм-тайм ( 19.00 -22.00 ) не превышает 1.5-2 *K Mbps, где К- количество юзеров ( домохозяйств )- этих самых хомячков. Причем эта скорость не мгновенное значение в пиках, а статистически усреденное за 2-3 секунды скорость трафика в Download. Скажем если в поселке имеется 300 юзеров, подключенных в Интернет по ПОН или радио ( как именно также неважно), то они потребляют в прайм тайм до 450-600 Mbps Download. - максимальная Upload скорость в прайм-тайм статистически не превышает 10% от Download. Тем самым для 300 юзеров типа хомяч oк Upload трафик не превысит 45- 60 Mbps. - максимальная усредненная за несколько секунд пакетная нагрузка in+out трафика составляет 1.3-1.5* S pps. Где S -cкорость реального трафика ( от сетен юзеров типа хомячок) в Download. Тем самым, для поселка с 300 дворами, подключенными в Интернет, если строить канал на радио 5 Ггц, то понадобится оборудование с максимальной пропускной способностью 500-650 Mbps, которое для систем TDD измеряется Upload+Download. Это например, Сambium Force 400c/425 или PTP 550E. А вот Force 300 или Мимоза С5x/C5c не потянут этот трафик, так как несмотря на их максимальную пропускную способность в тестах -600 Mbps в 80 МГц, реальный трафик более 450 Мbps Download они не пропусят из -за ограничений по пакетной производительноси (ппс). То же самое касается Ubiquiti AF5X HD в канале 80-100 МГц, у которого ограничение из-за ппс - 550 Mbps Download реального трафика. Если строить канал на FDD релейке скажем в 11 Ггц, то понадобиться оборудование со скоростью 600 Mbps full duplex . Для канала на оптике профиль трафика не имеет значения и для такого поселка потребуется зарыть в землю кабель ( или пойти по дорожным столбам ) от поселка до 1 Gbps порта свича/ роутера в PoP - точке выхода магистральной оптики.

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

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

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