slv700 Опубликовано 2 апреля, 2019 · Жалоба 6 часов назад, SSD сказал: в обоих тестах. Причина? Во втором тесте TCP dupleх 80+80 МГц провалов тоже нет. Какой то визуальный эффект. Сделайте крупней картинку скрина и увидите что ничего такого нет. Смотрите сами Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 2 апреля, 2019 · Жалоба 4 часа назад, xabarov сказал: В моем понимании "полная загрузка" - это когда нет никаких ограничений, а в вашем случае трафик был ограничен до уровня приемлемой задержки Ну я не согласен с вашим трактованием понятия полная загрузка. На мой взгляд полная 100% загрузка канала наступает в момент, когда еще резко не взлетает джиттер, ну и понятно средняя задержка находится в приемлемых пределах, примерно до 10-15 мс для 5 мс фрейма. Далее при увеличении трафика нельзя сказать, что загрузка канала увеличивается, она же не может быть больше 100%. Можно говорить о перегрузе интерфейса, который приводит к резкому росту джитера и средней задержки. Например, если UDP не ограничивать ( как советует xаbarov ) то всегда получается перегруз интерфейса с ростом задержки и джиттера. На iperf UDP есть другой индикатор перегруза интерфейса . Iperf может показывать потери пакетов UDP на приемной стороне. Обычно UDP iperf ограничивается величиной трафика, на котором потери не превышают 5 % . В случае TCP потери не видны на канальном уровне ,их можно оценить не столько по деградации задержки , а сколько по деградации TCP трафика. TCP ограничивается величиной, на которой достигается 1)максимальная 2) стабильная скорость TCP. Без ограничения скорость TCP всегда плавает, что говорит о потерях TCP пакетов ( не пингов ICMP) и перегрузе интерфейса. Или о наличии сильных скачущих по мощности помехах при неправильной работе Link Adaptation. Тем самым не ограничивать TCP в тестах также нельзя. Может кому то это покажется манипуляцией, но это не так. Тестирование пропускной способности канала, как оценка параметров случайной величины ( случайного процесса во времени при наличии помех) - это достаточно сложная наука, которую вообще то изучают в профильных вузах. Возможно не во всех, но есть вузы, где изучается РЭБ, и это там есть. В общем правило простое. Ограничение скорости в тестах UDP и TCP нужно всегда задавать, если это возможно в используемом генераторе трафика. Ограничение должно быть такое, чтобы получить максимальную и главное стабильную скорость ( график скорости не должен плавать и прыгать) и приемлемую задержку и джиттер. Это позволяет получить почти 100% загрузку канала без перегруза радиоинтерфейса на приемной стороне и соответственно правильную оценку параметров канала. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 2 апреля, 2019 · Жалоба 4 часа назад, xabarov сказал: болтанка модуляций, а реальная ситуация с ТСР еще хуже. Предполагаю, что Вячеслав столкнулся с аналогичным глюком iperf и пытается нам выдать UDP за ТСР. Болтанка модуляций видна по рваному графику скорости, которой на скринах нет. И о каком глюке iperf идет речь? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xabarov Опубликовано 3 апреля, 2019 · Жалоба 9 часов назад, slv700 сказал: Например, если UDP не ограничивать ( как советует xаbarov ) то всегда получается перегруз интерфейса с ростом задержки и джиттера. Я такого не советовал, зачем врете опять? У меня претензия только к формулировке о "полной загрузке", когда фактически загрузка неполная. Если трафик ограничен, то так и надо говорить - он был ограничен до уровня оптимальной задержки. 9 часов назад, slv700 сказал: Тем самым не ограничивать TCP в тестах также нельзя. Посмотрите мои тесты - я всегда и везде указываю, например: TCP Simplex (без ограничения скорости) TCP Duplex (с ограничением 30М/90М) Сразу все понятно без лишних слов о "полной загрузке", под которой вы что-то там свое подразумеваете, вводя в заблуждение. 9 часов назад, slv700 сказал: Болтанка модуляций видна по рваному графику скорости, которой на скринах нет. Начнем с того, что нам вообще не было представлено никаких скринов с веб-интерфейса устройства, где можно было бы увидеть изменение модуляции и хоть какое-то подтверждение, что такое устройство было включено для тестов :) Просто какие-то скрины с микротика и iperf. Судить можно только по графикам микротика, на которых видны провалы. Вот как выглядит график UDP теста, когда все хорошо: 9 часов назад, slv700 сказал: И о каком глюке iperf идет речь? Тот самый, о которым мы тут говорим уже несколько страниц. 10 часов назад, slv700 сказал: Какой то визуальный эффект. Возьму на вооружение - если на скрин вдруг попала какая-то проблема, то можно смело называть "каким-то визуальным эффектом" :) Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 3 апреля, 2019 · Жалоба 15 минут назад, xabarov сказал: икаких скринов с веб-интерфейса устройства, где можно было бы увидеть изменение модуляции и хоть какое-то подтверждение, что такое устройство было включено для тестов :) Просто какие-то скрины с микротика и iperf. Судить можно только по графикам микротика, на которых видны провалы. Вот как выглядит график UDP теста, когда все хорошо: На самом деле на скринах выше не для всех тестов , но все же есть графики загрузки канала с web интерфейса устройства. Представлены и графики загрузки и интерфейса Микротика и генератора тестов Микротик. Просто они дублируют друг друга, один- два раза показаны все вместе , потом показываются только скрины, где виден результат. Смотрите внимательно. Что касается выдуманного вами глюка iperf TCP, что типа у него нет обратного трафика ( подтверждения доставки пакетов), поэтому это якобы нечестный TCP. Я правильно вас понял? На самом деле если вы запустите iperf TCP через свич, тот же микротик например, то четко увидите помимо трафика теста также загрузку обратного канала. Для 800 М она составляет несколько мегабит. Это и есть ACKи в обратном канале. Так что нет в iperf никакого глюка. Это правильный инструмент для измерения пропускной способности канала и в UDP и TCP. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 3 апреля, 2019 · Жалоба Хотелось бы немного рассказать о том, зачем этому провайдеру на этом линке нужен именно PTP550 и почему он хочет тестировать возможности девайса именно в канале 80+80МГц. Мастер PTP550 стоит на элеваторе в селе. К нему походит 1 Гб оптики ( около 90 км от точки входа в магистральный 10 Гб канал). На элеваторе стоит старый NB M5 , канал 40Мгц, по которому в небольшое село на 7 км уходит 60-80М до 100М трафика. Максимум что NB дает -до 140М, но этого для того села достаточно, там клиентов немного. А вот на дальности 12 км от элеватора находится большое село. На него стоял линк тоже на PB M5, который упирался в полку 80 Mbps ( из за помех). Спрашивается зачем на элеватор за 90 км подан по оптике 1 гиг ( и платятся немалые деньги за подвес на опорах и местами за проход по грунту) , когда этот канал невозможно утилизировать на старинных нанобимах? Поэтому решили на большое село поставить линк PTP550, задача которого была утилизировать оставшиеся 800-900М оптического канала. И как мы видим в сухом остатке PTP 550 выдал 800+200Мbps в 80+80 мгц и подал этот канал с точки окончания ( входа) оптики в большое село. Теперь в этом селе доступен 1 Гиг и можно уже разворачивать нормальную сеть либо на ПОН, либо на ШБД , в зависимости от того что рентабельней в данном конкретном месте. Скорее всего будет комбинированный вариант , так как по любому в селе есть хутора, куда ПОН тянуть нерентабельно. И с технической точки зрения 1 Гиг в большом селе скажем на несколько сотен дворов ,можно раздать и на ПОН и на современном ШБД например Cambium ePMP 3000 - сайт из четырех БС в каналах 20+20МГц ( с синхронизацией) может раздать до 800+МBps (скоро будут результаты тестов). Тем самым PTP550 эффективен и полезен и ПОНоводам и радистам. ЗЫ Может кто скажет что лучше было бы на эти 12 км бросить оптику. Может быть когда нибудь люди это сделают, но канал нужен сейчас, и таких линков по 10-30+ км у провайдера сотни и всех сразу на оптику не переведешь. К тому же это недешево и в инсталляции и есть вопросы к рентабельности ( нужно платить за аренду столбов) канала 1 гиг на оптике vs на PTP550. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 3 апреля, 2019 · Жалоба И вот еще интересные данные по задержке для игры Word Of Tanks в канале PTP550. У танкистов есть свой WOT ping, который показывает задержку с игровыми серверами в каких то своих попугаях. Нормальным считается до 100 попугаев. 150 -еще терпимо, если 200-то танкисты начинают ругаться. Ниже скрин WOT ping на этом самом линке PTP550 на 12 км, где 60% серверов доступна местным танкистам с задержкой в пределах 35-45, 90% -до 100, и 100% до 150 без потерь 0%. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DenX3 Опубликовано 3 апреля, 2019 · Жалоба Нормальный провайдер на 500 клиентов поставит релейку. Чтобы его не сожрали, когда PTP550 потухнет от пионера. А если зайдет конкурент с оптикой, то сразу труба))))) Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 3 апреля, 2019 · Жалоба 31 минуту назад, DenX3 сказал: Нормальный провайдер на 500 клиентов поставит релейку. Чтобы его не сожрали, когда PTP550 потухнет от пионера. А если зайдет конкурент с оптикой, то сразу труба))))) 500 - но потенциальных клиентов. Если они есть и платят, то не вопрос. А если канала нет, то нет и клиентов. Ставить релейку за больше чем десяток тыс USD или тянуть оптику , да еще вкладываться скажем в PON в селе на несколько десятков тыс USD на эти 500, но потенциальных абонентов, когда неизвестно сколько из этих 500 клиентов подключится в ближайшей и средней перспективе - все это большие бизнес риски. За 12 км по прямой, это может быть 20 км оптики по дорожным столбам. В Украине, например, придется платить аренду за каждый столб по законодательству $0.45 в месяц. Всего за 20км ( 660 опор ЛЭП) придется платить в Облэнерго $300 в месяц , $3500 в год. И это еще в селе может быть еще не построена сеть раздачи, или построена, но еще не набрали клиентов. Одни убытки. А так за $1500 за два дня поставили линк на PTP550, дали в село 500М- 1 Гиг и дальше можно думать как и на чем строить сеть в селе. Лучше начать с ШБД . Не на убнт и микротик естественно, на них нельзя раздать такой трафик на 500 потенциальных абонентов. Наберется достаточное количество клиентов, можно посмотреть рентабельно ли их перевести на ПОН. Не факт, что в переходе на ПОН будет в данном конкретном месте смысл, современные технологии ШБД такие же скоростные, но существенно дешевле в строительстве и эксплуатационных расходах. Если же есть смысл в ПОН, то построить эту ПОН, оборудование ШБД снять и перенести в другое место. Потом можно подумать перевести ли линк на PTP550 на релейку или оптику. Если да, то PTP 550 снять и поставить в другое место. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DenX3 Опубликовано 3 апреля, 2019 (изменено) · Жалоба , Изменено 3 апреля, 2019 пользователем DenX3 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Constantin Опубликовано 3 апреля, 2019 · Жалоба 1 час назад, slv700 сказал: Не на убнт и микротик естественно, на них нельзя раздать такой трафик на 500 потенциальных абонентов ну да ну да покупайте только наших слонов. остальное комментировать себя не уважать, сущий бред Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 3 апреля, 2019 · Жалоба 1 час назад, Constantin сказал: ну да ну да покупайте только наших слонов. остальное комментировать себя не уважать, сущий бред Но ты не и способен ничего комментировать, нет ни профильных знаний по теме, ни нормального опыта. Есть кое какой опыт, но искривленный говносетями, на которых ты всю свою жизнь работал, до полного абсурда и невменяемости. Как можно раздать сервис 500 клиентам - домохозяйствам в большом селе по радио? Для этого понадобится минимум 15 базовых станций микротик/ubnt c сервисом 2 до 5 Mbps. Займет минимум 15x20Мгц ( ширина канала) + защитный интервал 14x10Мгц - всего 450 Мгц. Где взять столько частот? Легально не получить. Камбиум даже на ePMP 2000 понадобится 6 БС по 80 клиентов на сектор с сервисом 10/20М и 20+20 Мгц ( один сайт из 4 х БС) и 20 Мгц ( второй сайт из 2 -х баз), всего 60 МГц. А ePMP 3000 - 4 базы по 120 клиентов ,всего потребуется 40 Мгц частотного спектра, до 800М суммарная емкость по пропускной способности и сервисом 50/100М на клиентах 802.11ac и 10/20М на клиентах 802.11n. И у кого на самом деле воз остался и ныне там в 5-10 летней давности? SSD, я все правильно посчитал цифры, или по твоему представлению о работе ШБД и о мне лично опять типа соврал :)? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
haverlinkfor Опубликовано 3 апреля, 2019 (изменено) · Жалоба Скорость 1 TCP потока на линке какая? Изменено 3 апреля, 2019 пользователем haverlinkfor Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 3 апреля, 2019 · Жалоба Хороший вопрос :). Где то 140-160М. Но тут есть одна специфическая вещь. У PTP550 два канала и Камбиум рекомендует тестировать устройство в 80 +80 МГц ( рекомендации изложены на форуме оф. сайта) для правильного разделения каналов минимум 16 потоками по 8 потоков в каждом канале, включая UDP , не говоря даже про TCP. Как известно тесты TCP должны иметь в общем случае минимум 4-5 потоков. Один канал PTP550 по опыту тестирования полностью утилизируется 4 потоками TCP. Для двух каналов достаточно 16 потоков. Но мы часто задавали 20, 50 и даже 100 ( разницы не было ) потоков TCP так, чтобы было с запасом и не было вопросов к правильности балансировки каналов и адекватности тестов. Алгоритм разделения трафика по каналам такой: потоки разделяются по IP адресам, портам, а также начиная с прошивки 4.3.1 , если я правильно понял, каналы также ДОПОЛНИТЕЛЬНО балансируются по степени загрузки каналов трафиком. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
haverlinkfor Опубликовано 3 апреля, 2019 · Жалоба 160M * 4 = 640M Значит полностью не утилизируется? На сети я не увлекаюсь много-поточностью, всегда измеряю 1 потоком и он не сильно отстает, скажем так, от 5-10 сессий. И это если в сети все оK с радио, все ок с flow-control и буферами коммутаторов на транспортной сети. В противном случае, скорость одного потока низкая, забить кучей потоков (как на вашем скрине 100шт) мы можем, все будет хорошо, только вот смысл в этом если большинство приложений используют один поток (торренты не в счет). Если, действительно, используется балансировка, тогда ок, 160М норм для одного и его вполне хватит, главное без проседаний... Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xabarov Опубликовано 3 апреля, 2019 · Жалоба 14 часов назад, slv700 сказал: Что касается выдуманного вами глюка iperf TCP Этот глюк "выдуман" не только мной, вы также видели пример от другого человека, который использовал его независимо от меня. 14 часов назад, slv700 сказал: На самом деле если вы запустите iperf TCP через свич, тот же микротик например, то четко увидите помимо трафика теста также загрузку обратного канала. Для 800 М она составляет несколько мегабит. Это и есть ACKи в обратном канале. Так что нет в iperf никакого глюка. Все верно, несколько мегабит я всегда вижу во время симплексного ТСР теста на Бэндвичтесте (при 200-300 Мбит/с ТСР трафика). Во время TCP теста iperf обратного трафика почти не было, даже мегабита. Он был похож 1 в 1 на UDP тест iperf. Можете повторить свой тест iperf TCP simplex и показать интерфейс микротика? 7 часов назад, slv700 сказал: Ставить релейку за больше чем десяток тыс USD Уже давно есть релейки от UBNT за вполне сопоставимые деньги. AF24 до 6-8 км, AF11FX если надо дальше. Можно поставить и забыть что такое помехи. Для коротких линков точно нет смысла покупать дорогущее оборудование на 5-ку. Вот если нужно 30-50-80 км, тогда есть смысл рассматривать такое оборудование. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Constantin Опубликовано 3 апреля, 2019 · Жалоба 6 часов назад, slv700 сказал: Но ты не и способен ничего комментировать, да да, конечно, ни один вменяемый даже не будет рассматривать 500 потенциальных клиентов для подключения по радио, только невменяемый КаКадемик и отец ШПД может об этом мечтать, ты на своем камбиуме уже кукушкой двинулся одним ты поешь что нет там столько клиентов и нужно типа малой кровь сунуться и захватить рынок, тогда накой там 550??? когда af11 там дешевле, по параметрам лучше и более защищен в помехоустойчивости то есть там клиенты и тогда вообще радио там противопоказано... и тд и тп а сотню клиентов для начала там окучит и микротик с 3 секторами, который даст сервис не хуже твоего хваленого камбиума и дешевле обойдется раза в 3 хотя продолжайте заниматься клоунадой без вас тут было бы скучно. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 4 апреля, 2019 · Жалоба 4 часа назад, xabarov сказал: Можете повторить свой тест iperf TCP simplex и показать интерфейс микротика? Это нужно отключать живой трафик.Уже сложно. Но Вы это можете сделать сами у себя. Да и любой специалист вам скажет что iperf TCP - это точно такой же TCP как Bandwidth Test Mikrtotik. Глупо спорить. 4 часа назад, xabarov сказал: 19 часов назад, slv700 сказал: Что касается выдуманного вами глюка iperf TCP Этот глюк "выдуман" не только мной, вы также видели пример от другого человека, который использовал его независимо от меня. Сам по себе Iperf там показывал все точно. Но фокус был в чем то другом, что установить тогда не удалось. Человек пропал. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 4 апреля, 2019 · Жалоба 2 часа назад, Constantin сказал: когда af11 там дешевле, Полукомплект AF11x c двумя дуплексерами ( для конфигурации 2+0) и родной антенной обойдется на локальном рынке не менее $1500. То есть в два раза дороже чем PTP550. И не забываем что релейке нужен LOS. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 4 апреля, 2019 · Жалоба 2 часа назад, Constantin сказал: и микротик с 3 секторами, который даст сервис не хуже твоего хваленого камбиума и дешевле обойдется раза в 3 На самосборе 10 летней давности типа RB411 + карта R52n? Или 5 летней RB 912 ? C сервисом 2-5 Mbps при 30 клиентах на сектор. Такой сервис уже неконкурентен. 5 часов назад, haverlinkfor сказал: 160M * 4 = 640M Значит полностью не утилизируется? Iperf задавали 20 потоков TCP и он утилизировал 800M. Микротик больше 300М TCP не тянет. Набирал свой потолок в 4+потоках ( по дефолту у него в BT их 20). Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 4 апреля, 2019 · Жалоба 6 часов назад, haverlinkfor сказал: всегда измеряю 1 потоком и он не сильно отстает, скажем так, от 5-10 сессий. И это если в сети все оK с радио, все ок с flow-control и буферами коммутаторов на транспортной сети. В кабельной сети это возможно так и есть. И вы видимо используете TCP тесты не для измерения скорости, а для диагностики ошибок в сети ( в частности потерь на свичах). В этом случае один поток TCP -самое то, что надо. В TCP тестах для измерения скорости всегда рекомендуется (по науке) запускать не менее 5 потоков. В случае Камбиум запускали больше потоков, потому что там два канала. Для 2x80 МГц нужно 8+8=16 потоков ( запускали Iperf в 20 потоков TCP). На микротик запускали 20 ( по дефолту) и 50 и 100, разницы не было и это не имело значения , все равно он упирался в 300М TCP. И вообще в одном радиоканале ( для любого оборудования) TCP тест даже при большом количестве ошибок в канале ( высокий BER) достигает свой потолок при 5-10 потоках. Дальнейшее увеличение количества сессий для измерения скорости не имеет смысла. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 4 апреля, 2019 · Жалоба 5 часов назад, haverlinkfor сказал: большинство приложений используют один поток (торренты не в счет) Это не совсем так. Торренты многопоточны на уровне Application . А например загрузчик файлов браузера Chrome использует для загрузки файлов по TCP многопоточный http2 протокол. Другие браузеры скорее всего тоже. Один поток TCP использует видимо только обычный http. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
haverlinkfor Опубликовано 4 апреля, 2019 · Жалоба Для http2 обе стороны должны включать поддержку протокола. Вы можете дать примеры сервисов популярных, которые используют http2 ? Что скажете об ott телевидении? Если один поток никакой, пользователь FULL-HD с нормальным битрейтом (не говоря уже про 4K для которого нужен 1 поток в 35-40 Мбит/сек) работать не будет. Пофиг что у него в 5-10 потоков мегабит достаточно. Все же можно попросить провести тесты с 1) 1 поток TCP 2) 4 потока TCP Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xabarov Опубликовано 4 апреля, 2019 · Жалоба 5 часов назад, slv700 сказал: Это нужно отключать живой трафик.Уже сложно. Но Вы это можете сделать сами у себя. У себя я уже проверил много раз, результат один. 5 часов назад, slv700 сказал: Да и любой специалист вам скажет что iperf TCP - это точно такой же TCP как Bandwidth Test Mikrtotik. Глупо спорить. Пока что я не встречал специалистов, которые имели опыт работы одновременно с iperf TCP и TCP Bandwidth Mikrtotik. Если тут таковые имеются - буду признателен за любой опыт. 5 часов назад, slv700 сказал: Сам по себе Iperf там показывал все точно. Но фокус был в чем то другом, что установить тогда не удалось. Человек пропал. Судя по той теме человек никуда не пропал, а обсуждение завершилось тем, что вы предположили глюки iperf. 4 часа назад, slv700 сказал: Полукомплект AF11x c двумя дуплексерами ( для конфигурации 2+0) и родной антенной обойдется на локальном рынке не менее $1500. То есть в два раза дороже чем PTP550. Не знаю как на локальном рынке, а в России полный комплект с дуплексерами и тарелками 80 см обойдется в ~$2500. Если посмотреть общедоступные цены на PTP 550, то можно найти варианты в пределах $700-800, т.е. грубо комплект без антенн около $1500. Комплект антенн с высоким КУ обойдется минимум в $600-700, итого получаем $2100-2200 за потенциально геморройный (в плане помех) линк на 5-ке. Есть ли смысл в экономии нескольких сотен? Точно нет. Сочувствую вашему клиенту-провайдеру. 4 часа назад, slv700 сказал: И не забываем что релейке нужен LOS. Да, но LOS по-хорошему нужен везде, только 5-ка будет работать с какой-то относительно небольшой емкостью, а релейка не будет совсем. Но такие линки строят, когда совсем все плохо и нет других вариантов. Если есть LOS, то на коротком расстоянии до 15-20 км релейка однозначно вне конкуренции. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 4 апреля, 2019 · Жалоба 53 минуты назад, haverlinkfor сказал: Все же можно попросить провести тесты с 1) 1 поток TCP 2) 4 потока TCP Мы проводили тесты. 1 поток TCP Микротик давал 160+М, на 4 потоках Микротик на 300М упирался в свою полку. Iperf не пробовали с 1 потоком, сразу делали как надо от 20 потоков. 56 минут назад, haverlinkfor сказал: Для http2 обе стороны должны включать поддержку протокола. Вы можете дать примеры сервисов популярных, которые используют http2 ? Как то не изучали что поддерживает , а что нет многопоточную TCP загрузку. Просто пробовали браузером на разных сайтах кликнуть на файл для закачки и смотреть по какому протоколу идет закачка, всегда был http2. Закачка утилитой Download Master давала значительно более высокий результат. Но у нее 8 потоков, точно не знаю на TCP или еще и на Application. В принципе закачка в один поток TCP 160Мbps - нормальный результат, обычному юзеру хватит. Нужно больше, пусть использует Download Master или нечто подобное. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...