NiTr0 Опубликовано 7 июля, 2020 · Жалоба 10 часов назад, maa1 сказал: как у вас это реализовано? нормальный аплинк. тестировал с линукс бордера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ayf Опубликовано 7 июля, 2020 · Жалоба 13 часов назад, maa1 сказал: @sdy_moscow @ayf А так ТС напомнил мне одного клиента, который запросил доступа в интернет на 50 Мегабит/с Сделал. Претензия - нет скорости. Прихожу, проверяю, показываю на спидтесте, что канал соответствует. Чел орёт, что спидтест можно засунуть в .опу. А ему за его 5000 рублей надо, чтобы с этой скоростью видео загружалось и выгружалось на сервер ютуба в Америке. Был вежливо отослан Ну вы хоть нашли причину то, где скорость резалась? В любом случае не мой случай. Не совсем. Человек, почему-то, не захотел оплачивать даже телефонные разговоры со всеми операторами по трассировке. А так, я ему объяснил, что по нормам, обеспечиваю скорость до своего бордера. На Спидтесте показал, что даже до Москвы из Владивостока доходила скорость 50 Мегабит/с (Вру, чуть меньше. 43-45:)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maa1 Опубликовано 7 июля, 2020 · Жалоба @NiTr0 нормальный аплинк. а вы немногословны. я имею ввиду - 1) вы сам провайдер или клиент провайдера? если второй случай, то какой канал до провайдера? 2) iperf сервер находится в вашей сети или сети второго провайдера? если второй вариант, какой стык? 3) какой канал от вас до iperf сервера? обычный или рекламируемый тут l2? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 7 июля, 2020 · Жалоба В технической документации по ламборджинни голлардо написано, что она может валить 309кмч. Но по результатам замера средней скорости на трассе М7 в сторону Казани, примерно до Нижнего скорость почему то падает до сотки где то. Не знаю почему. У всех так? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmp.user Опубликовано 7 июля, 2020 · Жалоба Заинтересовало - что за задачи такие, что требуют многочасового копирования файлов обязательно в один поток? Если используется windows, даже там, штатные программы для копирования файлов могут выдать заметно отличающиеся скорости, в зависимости от используемых ключей. А многопоточное копирование позволило бы снизить время таких операций. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 июля, 2020 · Жалоба 22 минуты назад, dmp.user сказал: Заинтересовало - что за задачи такие, что требуют многочасового копирования файлов обязательно в один поток? Видимо копируют, перетаскивая файл мышкой в проводнике. Потому что Windows Network и SMB это по-моему единственные протоколы, сильно чувствительные к RTT и пропускной способности. HTTP/FTP/rsync обычно это проблему позволяют забыть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 7 июля, 2020 · Жалоба https://ru.wikipedia.org/wiki/KillCopy ещё есть. 1 час назад, maa1 сказал: я имею ввиду - 1) вы сам провайдер или клиент провайдера? Это форум провайдеров. Тут ВСЕ, у кого больше 100 постов провайдеры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmp.user Опубликовано 7 июля, 2020 · Жалоба Если пользователи и впрямь вручную файлы в проводнике перебрасывают в сетевую папку на удаленном сервере (и обратно) и через множество туннелей, то утилиты врядли подойдут. А так и штатнная robocopy многопоточность поддерживает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 7 июля, 2020 · Жалоба 2 часа назад, maa1 сказал: @NiTr0 нормальный аплинк. а вы немногословны. я имею ввиду - 1) вы сам провайдер или клиент провайдера? если второй случай, то какой канал до провайдера? 2) iperf сервер находится в вашей сети или сети второго провайдера? если второй вариант, какой стык? 3) какой канал от вас до iperf сервера? обычный или рекламируемый тут l2? У меня как физика тоже в один поток выжимает скорость даже до сервера iperf в Цюрихе (публичные) 100 mbit канал интернет, никаких проблем, скорее всего где то на сети провайдера у вас косяк, либо у него пиры такие, причин овер много, но провайдер всегда гарантирует скорость на своей сети, если она соответствует, то как бы все, дальше его не особенно заботит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bqd Опубликовано 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 году ну настолько нелепо, что даже как то дико. Что это за задача такая - передавать файл в один поток несколько дней? Кому вообще нужны файлы? Почему его нужно передавать обязательно в один поток? Выглядит как будто Вы неспособны решить элементарную задачу - задеплоить приложение или сервис по передаче информации из точки А в точку Б по существующим каналам связи и поэтому решили взбодрить весь телеком. Может Вы троль? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maa1 Опубликовано 7 июля, 2020 · Жалоба @semop про автомобили это оффтопик. катайтесь по немецким автобанам. или ждите, когда в россии дороги отремонтируют. @dmp.user @alibek вы такие наивные. разумеется перепробовано FTP/SCP/SFTP. проблему это не решает от слова никак. т.к. это всё тот же tcp и всё тот же один поток. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maa1 Опубликовано 7 июля, 2020 (изменено) · Жалоба @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. У нас в офисе заведено три провайдера, и я могу их сравнить в равных условиях. Как видите, результаты теста разбивают ваши выкладки в пух и прах. Вы почему то упорно проигнорировали мой первый пост. Я не говорил, что поголовно у всех провайдеров эта проблема в полный рост. Я сказал "у многих" и в разной степени. Может Вы тролль? Изменено 7 июля, 2020 пользователем maa1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmp.user Опубликовано 7 июля, 2020 · Жалоба 1 hour ago, maa1 said: @dmp.user @alibek вы такие наивные. разумеется перепробовано FTP/SCP/SFTP. проблему это не решает от слова никак. т.к. это всё тот же tcp и всё тот же один поток. У вас robocopy с ключём /mt не работает - один поток выдает? Про неё писал - идет в составе и серверных и клиентских windows. Или читаете не внимательно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 7 июля, 2020 · Жалоба @maa1 НУ ТАК ОТКАЖИТЕСЬ ОТ "ПЛОХИХ" ПРОВАЙДЕРОВ! Тут особо никто не горит желанием разбираться с ВАШИМИ проблемами по паре логов ippref. Выкладывайте тогда уж всю информацию (trace, ip, давайте удаленный доступ) будет что обсуждать, проверять. Причины того, что и почему у Вас сейчас происходит Вам уже указали и не один раз (реализация протокола TCP). Поймите уже! Это не проблема сообщества операторов связи, МЫ ЗНАЕМ И ПОНИМАЕМ В ЧЕМ У ВАС ПРОБЛЕМЫ! НО! Это проблемы ВАШИ (как клиента) и ВАШИХ "плохих" провайдеров, которым достался такой клиент - которому надо 10 раз повторить одно и то же, а до него так и не доходит "куда копать"! ЗАПОМНИТЕ РАЗ И НАВСЕГДА! ЗАДЕРЖКИ И ПОТЕРИ НА IP СЕТЯХ - ЭТО НОРМА, А НЕ НОНСЕНС! Вопрос только в их величине. Рекомендую Вам обратиться с вашей проблемой к изготовителю вашего клиентского и серверного софта, а не к нам. Или по-крайней мере понять, что Вас спасет только "многопоточность" или настройки TCP на ВАШЕМ оборудовании, а как ВЫ это организуете, это уже несколько другая тема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 7 июля, 2020 · Жалоба 1 час назад, maa1 сказал: тем не менее они могут влиять (ограничивать прямо или косвенно, с умыслом или по незнанию) скорость tcp соединения ДНО НОМЕР 2. А зачем им это? И прикиньте сколько это им будет стоить???!!! З.Ы. Совет. Лучше сходите на политс.ру и обсудите там теорию всемирного заговора и короновирус. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 8 июля, 2020 · Жалоба В 06.07.2020 в 06:40, nemo_lynx сказал: "Российская непролазная дорога из грязи по колено" - это просто занюханый штамп, удобно применяемый там, где возникает необходимость признать свою бестолковость. ну я так понимаю вы дальше мкад не бывали? а я вот как российский джипер с ДВ, скажу вам что это нифига не штамп... от слова совсем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 8 июля, 2020 · Жалоба 21 час назад, maa1 сказал: вы сам провайдер или клиент провайдера? провайдер 21 час назад, maa1 сказал: iperf сервер находится в вашей сети или сети второго провайдера? iperf сервер - публичный в США. 21 час назад, maa1 сказал: какой канал от вас до iperf сервера? обычный или рекламируемый тут l2? естественно обычный "интернет". зачем мне л2 канал в США? 18 часов назад, bqd сказал: Что это за задача такая - передавать файл в один поток несколько дней? самый простой пример - тот самый видеостриминг например. и да, когда проблемы у аплинка и скорость в один поток падает - у абонов начинаются массовые жалобы на тормозящий ютуп. а так - да, скорость единичной сессии больше никому не интересна... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 8 июля, 2020 · Жалоба 1 час назад, NiTr0 сказал: скорость в один поток падает - у абонов начинаются массовые жалобы на тормозящий ютуп. А ютуп сейчас разве не на QUIC работает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 8 июля, 2020 · Жалоба а где этот quic кроме хромого-то вообще работает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 8 июля, 2020 · Жалоба Почитал, да, оно совсем ещё сырое, но в ночные сборки огнелиса уже заехало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 9 июля, 2020 · Жалоба В 08.07.2020 в 21:57, NiTr0 сказал: а где этот quic кроме хромого-то вообще работает? подожди http/3 это QUIC поверх TLS, будет везде работать и не только ютуб Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 июля, 2020 · Жалоба речь не о том, что когда-то где-то будет, а о том что у абонов уже сейчас проблемы с потоковым видео при затыках в tcp. пушо однопоток. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
