NiTr0 Posted July 7, 2020 Posted July 7, 2020 10 часов назад, maa1 сказал: как у вас это реализовано? нормальный аплинк. тестировал с линукс бордера. Вставить ник Quote
ayf Posted July 7, 2020 Posted July 7, 2020 13 часов назад, maa1 сказал: @sdy_moscow @ayf А так ТС напомнил мне одного клиента, который запросил доступа в интернет на 50 Мегабит/с Сделал. Претензия - нет скорости. Прихожу, проверяю, показываю на спидтесте, что канал соответствует. Чел орёт, что спидтест можно засунуть в .опу. А ему за его 5000 рублей надо, чтобы с этой скоростью видео загружалось и выгружалось на сервер ютуба в Америке. Был вежливо отослан Ну вы хоть нашли причину то, где скорость резалась? В любом случае не мой случай. Не совсем. Человек, почему-то, не захотел оплачивать даже телефонные разговоры со всеми операторами по трассировке. А так, я ему объяснил, что по нормам, обеспечиваю скорость до своего бордера. На Спидтесте показал, что даже до Москвы из Владивостока доходила скорость 50 Мегабит/с (Вру, чуть меньше. 43-45:)) Вставить ник Quote
maa1 Posted July 7, 2020 Author Posted July 7, 2020 @NiTr0 нормальный аплинк. а вы немногословны. я имею ввиду - 1) вы сам провайдер или клиент провайдера? если второй случай, то какой канал до провайдера? 2) iperf сервер находится в вашей сети или сети второго провайдера? если второй вариант, какой стык? 3) какой канал от вас до iperf сервера? обычный или рекламируемый тут l2? Вставить ник Quote
semop Posted July 7, 2020 Posted July 7, 2020 В технической документации по ламборджинни голлардо написано, что она может валить 309кмч. Но по результатам замера средней скорости на трассе М7 в сторону Казани, примерно до Нижнего скорость почему то падает до сотки где то. Не знаю почему. У всех так? Вставить ник Quote
dmp.user Posted July 7, 2020 Posted July 7, 2020 Заинтересовало - что за задачи такие, что требуют многочасового копирования файлов обязательно в один поток? Если используется windows, даже там, штатные программы для копирования файлов могут выдать заметно отличающиеся скорости, в зависимости от используемых ключей. А многопоточное копирование позволило бы снизить время таких операций. Вставить ник Quote
alibek Posted July 7, 2020 Posted July 7, 2020 22 минуты назад, dmp.user сказал: Заинтересовало - что за задачи такие, что требуют многочасового копирования файлов обязательно в один поток? Видимо копируют, перетаскивая файл мышкой в проводнике. Потому что Windows Network и SMB это по-моему единственные протоколы, сильно чувствительные к RTT и пропускной способности. HTTP/FTP/rsync обычно это проблему позволяют забыть. Вставить ник Quote
sol Posted July 7, 2020 Posted July 7, 2020 https://ru.wikipedia.org/wiki/KillCopy ещё есть. 1 час назад, maa1 сказал: я имею ввиду - 1) вы сам провайдер или клиент провайдера? Это форум провайдеров. Тут ВСЕ, у кого больше 100 постов провайдеры. Вставить ник Quote
dmp.user Posted July 7, 2020 Posted July 7, 2020 Если пользователи и впрямь вручную файлы в проводнике перебрасывают в сетевую папку на удаленном сервере (и обратно) и через множество туннелей, то утилиты врядли подойдут. А так и штатнная robocopy многопоточность поддерживает. Вставить ник Quote
fractal Posted July 7, 2020 Posted July 7, 2020 2 часа назад, maa1 сказал: @NiTr0 нормальный аплинк. а вы немногословны. я имею ввиду - 1) вы сам провайдер или клиент провайдера? если второй случай, то какой канал до провайдера? 2) iperf сервер находится в вашей сети или сети второго провайдера? если второй вариант, какой стык? 3) какой канал от вас до iperf сервера? обычный или рекламируемый тут l2? У меня как физика тоже в один поток выжимает скорость даже до сервера iperf в Цюрихе (публичные) 100 mbit канал интернет, никаких проблем, скорее всего где то на сети провайдера у вас косяк, либо у него пиры такие, причин овер много, но провайдер всегда гарантирует скорость на своей сети, если она соответствует, то как бы все, дальше его не особенно заботит Вставить ник Quote
bqd Posted July 7, 2020 Posted July 7, 2020 Весело тут у вас Собственно неудивительно - обычная реакция на агрессивную некомпетентность Автор, не обижайся, тут все когда такими были в той или иной степени. Это нормально, что чуваки по разные стороны ямы на кривой Данинга-Крюгера кидают друг в друга какашками Теперь попробую ответить на вопрос 1. Вопрос не по адресу. Провайдеры не имеют отношения к реализации TCP, его congestion алгоритмам и тюнингом сетевых настроек клиентской ОС 2. Для TCP потока существует простая такая формула: throuthput = TCPWindowSize / RTT Понятно, что если ты хочешь разогнать поток до 100M при rtt 50ms то тебе нужно окно 100 000 000 * 0.050 / 8 = 625К Я не знаю какое максимальное окно задано по умолчанию в Windows. Там наверное есть ключи реестра для этого. Вот только эти ключи ничего не дадут так как iperf под windows собирается с использованием cygwin C последним iperf3 идет cygwin.dll версии 2.5.1 в котором максимальный TCPWindowSize выставлено в 278,775 Таким образом на потоке с RTT 50мс разогнаться дальше 44M никак не получится. 278,775 / 0.05 * 8 = 44 604 000 b/s В принципе если поставить последний cygwin отдельно от iperf то эта проблема решается. Но винда действительно плохо подходит под задачу. Кстать легко проверить как ключ -m отработал на клиенте. Просто поймай TCP SYN пакет на сервере WireShark-ом 3. Алгоритмы TCP Congestion чуствительны к потерям трафика. В легаси алгоритмах на каждый ретрансмит окно сжималось вдвое. Сейчас лучше, но не радикально. Понятно, что если у тебя единственный поток то он один за всех и будет коллапсировать в ответ на каждый битый бит. А 20 потоков не заметят потери (кратковременной) бойца и канал получится утилизировать максимально. Так же совершенно очевидно, что вероятность потери пакета прямопропорциональна расстоянию (ну и количеству хопов конечно). А то что пинги не показывают потерь не значит, что их нет. Просто пинги, во первых, короче (у меня в Linux 84 байта о умолчанию), а во вторых - их пренебрежимо мало. сравни тест пингами и iperf-ом с точки зрения утилизации полосы: 1 vs 8333 пакет/с 84*8 vs 100000000 бит/с 4. Требовать от провайдеров работы однопоточного приложения в 2020 году ну настолько нелепо, что даже как то дико. Что это за задача такая - передавать файл в один поток несколько дней? Кому вообще нужны файлы? Почему его нужно передавать обязательно в один поток? Выглядит как будто Вы неспособны решить элементарную задачу - задеплоить приложение или сервис по передаче информации из точки А в точку Б по существующим каналам связи и поэтому решили взбодрить весь телеком. Может Вы троль? Вставить ник Quote
fractal Posted July 7, 2020 Posted July 7, 2020 2 часа назад, bqd сказал: Весело тут у вас Собственно неудивительно - обычная реакция на агрессивную некомпетентность Автор, не обижайся, тут все когда такими были в той или иной степени. Это нормально, что чуваки по разные стороны ямы на кривой Данинга-Крюгера кидают друг в друга какашками Теперь попробую ответить на вопрос 1. Вопрос не по адресу. Провайдеры не имеют отношения к реализации TCP, его congestion алгоритмам и тюнингом сетевых настроек клиентской ОС 2. Для TCP потока существует простая такая формула: throuthput = TCPWindowSize / RTT Понятно, что если ты хочешь разогнать поток до 100M при rtt 50ms то тебе нужно окно 100 000 000 * 0.050 / 8 = 625К Я не знаю какое максимальное окно задано по умолчанию в Windows. Там наверное есть ключи реестра для этого. Вот только эти ключи ничего не дадут так как iperf под windows собирается с использованием cygwin C последним iperf3 идет cygwin.dll версии 2.5.1 в котором максимальный TCPWindowSize выставлено в 278,775 Таким образом на потоке с RTT 50мс разогнаться дальше 44M никак не получится. 278,775 / 0.05 * 8 = 44 604 000 b/s В принципе если поставить последний cygwin отдельно от iperf то эта проблема решается. Но винда действительно плохо подходит под задачу. Кстать легко проверить как ключ -m отработал на клиенте. Просто поймай TCP SYN пакет на сервере WireShark-ом 3. Алгоритмы TCP Congestion чуствительны к потерям трафика. В легаси алгоритмах на каждый ретрансмит окно сжималось вдвое. Сейчас лучше, но не радикально. Понятно, что если у тебя единственный поток то он один за всех и будет коллапсировать в ответ на каждый битый бит. А 20 потоков не заметят потери (кратковременной) бойца и канал получится утилизировать максимально. Так же совершенно очевидно, что вероятность потери пакета прямопропорциональна расстоянию (ну и количеству хопов конечно). А то что пинги не показывают потерь не значит, что их нет. Просто пинги, во первых, короче (у меня в Linux 84 байта о умолчанию), а во вторых - их пренебрежимо мало. сравни тест пингами и iperf-ом с точки зрения утилизации полосы: 1 vs 8333 пакет/с 84*8 vs 100000000 бит/с 4. Требовать от провайдеров работы однопоточного приложения в 2020 году ну настолько нелепо, что даже как то дико. Что это за задача такая - передавать файл в один поток несколько дней? Кому вообще нужны файлы? Почему его нужно передавать обязательно в один поток? Выглядит как будто Вы неспособны решить элементарную задачу - задеплоить приложение или сервис по передаче информации из точки А в точку Б по существующим каналам связи и поэтому решили взбодрить весь телеком. Может Вы троль? Попробуйте сделать тест на вашем провайдере сюда bouygues.iperf.fr порт 9200 это через wifi [ ID] Interval Transfer Bandwidth [ 4] 0.00-100.01 sec 1.07 GBytes 91.6 Mbits/sec sender [ 4] 0.00-100.01 sec 1.04 GBytes 89.6 Mbits/sec receiver Вставить ник Quote
maa1 Posted July 7, 2020 Author Posted July 7, 2020 @semop про автомобили это оффтопик. катайтесь по немецким автобанам. или ждите, когда в россии дороги отремонтируют. @dmp.user @alibek вы такие наивные. разумеется перепробовано FTP/SCP/SFTP. проблему это не решает от слова никак. т.к. это всё тот же tcp и всё тот же один поток. Вставить ник Quote
maa1 Posted July 7, 2020 Author Posted July 7, 2020 (edited) @bqd Вопрос не по адресу. Провайдеры не имеют отношения к реализации TCP, его congestion алгоритмам и тюнингом сетевых настроек клиентской ОС тем не менее они могут влиять (ограничивать прямо или косвенно, с умыслом или по незнанию) скорость tcp соединения Требовать от провайдеров работы однопоточного приложения в 2020 году ну настолько нелепо, что даже как то дико. ноу комментс. вы сказали какую-то дичь. C последним iperf3 идет cygwin.dll версии 2.5.1 в котором максимальный TCPWindowSize выставлено в 278,775.Таким образом на потоке с RTT 50мс разогнаться дальше 44M никак не получится. да ладно? вот условно "хороший провайдер 100Мбит" rtt 38ms: >iperf3.exe -w 4096K -c x.x.x.x Connecting to host x.x.x.x, port 5201 [ 4] local z.z.z.z port 49610 connected to x.x.x.x port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 12.2 MBytes 103 Mbits/sec [ 4] 1.00-2.00 sec 13.5 MBytes 113 Mbits/sec [ 4] 2.00-3.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 3.00-4.00 sec 10.9 MBytes 91.3 Mbits/sec [ 4] 4.00-5.00 sec 11.5 MBytes 96.5 Mbits/sec [ 4] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec [ 4] 6.00-7.00 sec 12.4 MBytes 104 Mbits/sec 22:43[ 4] 7.00-8.00 sec 12.5 MBytes 105 Mbits/sec [ 4] 8.00-9.00 sec 12.5 MBytes 105 Mbits/sec [ 4] 9.00-10.00 sec 12.9 MBytes 108 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 122 MBytes 102 Mbits/sec sender [ 4] 0.00-10.00 sec 118 MBytes 99.2 Mbits/sec receiver iperf Done. а вот в тех же условиях тот же тест сразу подряд, "плохой провайдер 200Мбит" rtt 45ms: >iperf3.exe -w 4096K -c x.x.x.x Connecting to host x.x.x.x, port 5201 [ 4] local z.z.z.z port 49635 connected to x.x.x.x port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 4.25 MBytes 35.6 Mbits/sec [ 4] 1.00-2.00 sec 640 KBytes 5.24 Mbits/sec [ 4] 2.00-3.00 sec 1.00 MBytes 8.39 Mbits/sec [ 4] 3.00-4.00 sec 1.38 MBytes 11.5 Mbits/sec [ 4] 4.00-5.00 sec 1.75 MBytes 14.7 Mbits/sec [ 4] 5.00-6.00 sec 2.00 MBytes 16.8 Mbits/sec [ 4] 6.00-7.00 sec 2.38 MBytes 19.9 Mbits/sec [ 4] 7.00-8.00 sec 2.62 MBytes 22.1 Mbits/sec [ 4] 8.00-9.00 sec 3.12 MBytes 26.2 Mbits/sec [ 4] 9.00-10.00 sec 3.88 MBytes 32.5 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 23.0 MBytes 19.3 Mbits/sec sender [ 4] 0.00-10.00 sec 19.3 MBytes 16.2 Mbits/sec receiver iperf Done. У нас в офисе заведено три провайдера, и я могу их сравнить в равных условиях. Как видите, результаты теста разбивают ваши выкладки в пух и прах. Вы почему то упорно проигнорировали мой первый пост. Я не говорил, что поголовно у всех провайдеров эта проблема в полный рост. Я сказал "у многих" и в разной степени. Может Вы тролль? Edited July 7, 2020 by maa1 Вставить ник Quote
dmp.user Posted July 7, 2020 Posted July 7, 2020 1 hour ago, maa1 said: @dmp.user @alibek вы такие наивные. разумеется перепробовано FTP/SCP/SFTP. проблему это не решает от слова никак. т.к. это всё тот же tcp и всё тот же один поток. У вас robocopy с ключём /mt не работает - один поток выдает? Про неё писал - идет в составе и серверных и клиентских windows. Или читаете не внимательно. Вставить ник Quote
sdy_moscow Posted July 7, 2020 Posted July 7, 2020 @maa1 НУ ТАК ОТКАЖИТЕСЬ ОТ "ПЛОХИХ" ПРОВАЙДЕРОВ! Тут особо никто не горит желанием разбираться с ВАШИМИ проблемами по паре логов ippref. Выкладывайте тогда уж всю информацию (trace, ip, давайте удаленный доступ) будет что обсуждать, проверять. Причины того, что и почему у Вас сейчас происходит Вам уже указали и не один раз (реализация протокола TCP). Поймите уже! Это не проблема сообщества операторов связи, МЫ ЗНАЕМ И ПОНИМАЕМ В ЧЕМ У ВАС ПРОБЛЕМЫ! НО! Это проблемы ВАШИ (как клиента) и ВАШИХ "плохих" провайдеров, которым достался такой клиент - которому надо 10 раз повторить одно и то же, а до него так и не доходит "куда копать"! ЗАПОМНИТЕ РАЗ И НАВСЕГДА! ЗАДЕРЖКИ И ПОТЕРИ НА IP СЕТЯХ - ЭТО НОРМА, А НЕ НОНСЕНС! Вопрос только в их величине. Рекомендую Вам обратиться с вашей проблемой к изготовителю вашего клиентского и серверного софта, а не к нам. Или по-крайней мере понять, что Вас спасет только "многопоточность" или настройки TCP на ВАШЕМ оборудовании, а как ВЫ это организуете, это уже несколько другая тема. Вставить ник Quote
sdy_moscow Posted July 7, 2020 Posted July 7, 2020 1 час назад, maa1 сказал: тем не менее они могут влиять (ограничивать прямо или косвенно, с умыслом или по незнанию) скорость tcp соединения ДНО НОМЕР 2. А зачем им это? И прикиньте сколько это им будет стоить???!!! З.Ы. Совет. Лучше сходите на политс.ру и обсудите там теорию всемирного заговора и короновирус. Вставить ник Quote
myst Posted July 8, 2020 Posted July 8, 2020 В 06.07.2020 в 06:40, nemo_lynx сказал: "Российская непролазная дорога из грязи по колено" - это просто занюханый штамп, удобно применяемый там, где возникает необходимость признать свою бестолковость. ну я так понимаю вы дальше мкад не бывали? а я вот как российский джипер с ДВ, скажу вам что это нифига не штамп... от слова совсем. Вставить ник Quote
NiTr0 Posted July 8, 2020 Posted July 8, 2020 21 час назад, maa1 сказал: вы сам провайдер или клиент провайдера? провайдер 21 час назад, maa1 сказал: iperf сервер находится в вашей сети или сети второго провайдера? iperf сервер - публичный в США. 21 час назад, maa1 сказал: какой канал от вас до iperf сервера? обычный или рекламируемый тут l2? естественно обычный "интернет". зачем мне л2 канал в США? 18 часов назад, bqd сказал: Что это за задача такая - передавать файл в один поток несколько дней? самый простой пример - тот самый видеостриминг например. и да, когда проблемы у аплинка и скорость в один поток падает - у абонов начинаются массовые жалобы на тормозящий ютуп. а так - да, скорость единичной сессии больше никому не интересна... Вставить ник Quote
pppoetest Posted July 8, 2020 Posted July 8, 2020 1 час назад, NiTr0 сказал: скорость в один поток падает - у абонов начинаются массовые жалобы на тормозящий ютуп. А ютуп сейчас разве не на QUIC работает? Вставить ник Quote
NiTr0 Posted July 8, 2020 Posted July 8, 2020 а где этот quic кроме хромого-то вообще работает? Вставить ник Quote
pppoetest Posted July 8, 2020 Posted July 8, 2020 Почитал, да, оно совсем ещё сырое, но в ночные сборки огнелиса уже заехало. Вставить ник Quote
GrandPr1de Posted July 9, 2020 Posted July 9, 2020 В 08.07.2020 в 21:57, NiTr0 сказал: а где этот quic кроме хромого-то вообще работает? подожди http/3 это QUIC поверх TLS, будет везде работать и не только ютуб Вставить ник Quote
NiTr0 Posted July 9, 2020 Posted July 9, 2020 речь не о том, что когда-то где-то будет, а о том что у абонов уже сейчас проблемы с потоковым видео при затыках в tcp. пушо однопоток. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.