Alver

Опять кто сказал что 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

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

Это наш местный отечественный производитель, обещает лучше качество и дешевле Jirous 6 ГГц. но если в ближайшее время антенн от него не будет, возьмем Jirous, как минимум для испытаний. Цена Force 600 под внешнюю антенну будет менее $500. Над открытием 6 Ггц для вайфай на УЗЗ работа идет. Но для начала как минимум разрешение на применение точка-точка в 6 Ггц типа релейки , но TDD, получим, соответственно все сертифицируем .

Я не спорю, что 3G/4G и 5G имеют технологические ограничения в UL и поэтому на отдачу дают меньше скорости. Но мы говорим совсем о другом. Вы не поняли задачу и ТС и мою, подменили ее какой то своей, приписали мне, что я не прав при решении вашей другой задачи и с этим боретесь. И поэтому действительно с вами спорить не о чем, вы не понимате в радио ничего, и пытаетесь что то кому то объяснить. Вам в этой теме и в вопросе ТС делать нечего. Максимум что вы можете посоветовать -закапывать оптику в грунт ( на что много ума не надо, а нужны только деньги) , в том числе делать проколы чер

Мы спорим с tkapluk о разных вещах. У меня другая, отличная от tkapluk задача. Моя задача (по целевой функции и критерию эффективности совпадает с ТС) дать 500Мbps-2Gbps канал от точки выхода магистральной оптики в поселок с населением до 5 тыс человек, с потенциалом подключения в Интернет 300-1000 дворов ЧС ( так называемых хомячков), которые в прайм тайм будут потреблять до 400Мbps -2 Gbps DL c профилем трафика DL/UL =10/1. Я эту задачу решаю по радио применением оборудования Сambium Force 300-25/300 CSM ( до 500 Mbps UL+DL), Force 400C, 425 ( 1Gbps DL+UL) ,

Для точки обмена трафиком в Киеве , если там снять с порта маршрутизатора скажем провайдера из Броваров статистику трафика, то DL ( для точки обмена) из Броваров будет меньше UL в сторону Броваров. На порту маршутизатора провайдера этих самых Броваров будет обратная картина. То есть все относительно, но можно предьявить картинку, где UL больше DL. Возьмем другой пример. Воля ( ныне Датагруп) . У них 1.8 млн домашних юзеров по всей Украине. Все их домашние юзеры смотрят TV с серверов в Киеве. Ясно дело, что исходящий UL трафик сети Воля в Киеве, где стоит IPTV/OTT

Какой еще диалап ? Крыша поехала? У радио ( современного) точка-точка нет технологического перекоса Uplink/Donwlink. У раздач ШБД и 3G/4G/5G - есть. Но эта технологическая особенность не вносит перекоса и не ограничивает Upload трафик в магистральном канале например поселка. А вот если это крупный город, то играют роль другие факторы . Если это например, Киев, то для него Upload от точек обмена трафиком превышает Download, скажем в БЦ или Бровары или областные центры и имеет место быть обратное соотношения UL/DL - где наоборот UL выше.

.На самом деле профиль трафика магистрального канала не зависит от того на чем канал, на оптике или радио. Не зависит он и от раздачи -доступа по радио , ПОН или в городской квартал на витой паре по многоквартирным домам, главное, это трафик к конечным юзерам- хомячкам. И мы говорим о каналах до 1-2 Гиг в частный сектор ( для хомячков ) населенных пунктов до 1 тыс дворов, без замеса телефонии и корпоративных клиентов , а не междугородних оптических каналов операторов типа Уарнет или Атраком, где трафик во Львов и далее на Запад из Киева не меньше , чем со Львова в точки обмена трафико

Кому и зачем нужно DL/UL 50/50? У Камбиум есть деление TDD 50/50 и коню ясно, что если канал 1 Gbps в полосе 80МГц , а в TDD это означает UL+DL=1 Gbps и при делении 50/50 это будет 500М дуплекса в полосе 80МГц. Но это деление 50/50 практически никто не использует. Если нужно TDD ( обычно для синхронизации и frequency reuse), то в 99% случаев люди ставят DL/UL =75/25 или 85/15. Но в большинстве случаев ставят динамическое ( адаптивное) деление DL/UL и при соотношении трафика DL/UL =90/10 система сама подстраивается под TDD деление 90/10, то есть пропускает 900М Downl