New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
haukened opened this issue
Dec 9, 2014
· 15 comments
Closed
server hangs on abrupt disconnect
#225
haukened opened this issue
Dec 9, 2014
· 15 comments
Assignees
Comments
when the client abruptly disconnects during a test the server hangs as busy and will not time out to accept a new connection. Currently requires manual resetting of the server instance.
What version of iperf are you running? What command line arguments are needed to make this happen?
Hello,
We have noticed this same issue. In our case we use iperf3 for doing throughput surveys of WiFi networks. This is often done on unreliable networks with lots of roaming and connection drops.
I have analyzed the issue further. I think the problem is that when a clients network connection drops suddenly then TCP connections can be left hanging in a ESTABLISHED state on server side. Those connections are never closed by the OS (or at least not for a very long time). This is what happens with the server side TCP control channel connection of iperf3. This causes the test to keep going on indefinitely, which in turn means that the server refuses any further connections until it’s restarted.
The simplest fix i could think of is to simply have a timeout on the server side that closes a any test that have been running for longer than the «duration» that was requested by client. I have a patch for iperf_server_api.c revision 8d3ed69 that fixes this issue for me by closing tests that linger for longer than «duration» + 5 seconds. I can send it to you if you like. Where shall i send it to?
For the future perhaps a more robust method would be to have a periodic keep-alive message on the control channel that checks the connection state. That might very slightly affect the test results though.
Let me know if you need any more information.
Best Regards, Mikael
Hi again,
I forked the source and put the change here:
mkall@aaeeaf6
I forgot to post steps to reproduce the issue. Just run any UDP test, and while the test is ongoing disconnect the client’s network abruptly. For me 100% of the time the server will keep running the test forever and must be restarted.
We hope that this fix (or some other fix that resolves the issue) can be included in master branch asap. Until then we will have to use a custom binary built from this source.
Best regards, Mikael
Mikael,
That is exactly the same use scenario where I got it to hang as well.
Thank you so much for the patch, I will get that applied to our testing
server and see if I can confirm a fix for you on my side as well.
I really appreciate your help on this. I’ll send you my email address
when I get to the office!
David
On Monday, January 12, 2015, mkall notifications@github.com wrote:
Hi again,
I forked the source and put the change here:
mkall/iperf@aaeeaf6
mkall@aaeeaf6I forgot to post steps to reproduce the issue. Just run any UDP test, and
while the test is ongoing disconnect the client’s network abruptly. For me
100% of the time the server will keep running the test forever and must be
restarted.We hope that this fix (or some other fix that resolves the issue) can be
included in master branch asap. Until then we will have to use a custom
binary built from this source.Best regards, Mikael
—
Reply to this email directly or view it on GitHub
#225 (comment).
Hi David.
Did you ever get a chance to try out my patch? I’m curious to know if your issue was resolved. Especially since that might increase the chance of eventually getting the fix to the main branch.
- Mikael
Mikael,
I tested this yesterday on both TCP and UDP. the change seems to have
solved the problem completely! I did notice one strange thing: The patch
causes the process to terminate with a «bad file descriptor» error, I don’t
know if there is a way to change the verbosity of this to «test timed out»
or something similar, but functionally it works wonderfully!!
David
On Sunday, January 18, 2015, mkall notifications@github.com wrote:
Hi David.
Did you ever get a chance to try out my patch? I’m curious to know if your
issue was resolved. Especially since that might increase the chance of
eventually getting the fix to the main branch.
- Mikael
—
Reply to this email directly or view it on GitHub
#225 (comment).
Ok, thanks for that! However, what do you mean by «causes process to terminate»? Does the whole iperf server process actually terminate? I’m guessing you don’t mean that or else you would probably not be very happy with the fix. 
It should be just the ongoing test that terminates.
Bruce, I’m not sure if you are following this discussion. If I were to clean up the fix a little would you consider merging it to the main branch? Or do you prefer some other type of fix? By clean up code i mean adding comments, adding better error message, and perhaps make the number of seconds at which to timeout a #DEFINE value.
- Mikael
Bruce,
You are correct, the entire iperf process does not terminate, only the
currently running test! I’m actually very happy with the fix, and glad for
both of your involvement! Thanks to each of you for being part of what
makes Linux great!
David
On Tuesday, January 20, 2015, mkall notifications@github.com wrote:
Ok, thanks for that! However, what do you mean by «causes process to
terminate»? Does the whole iperf server process actually terminate? I’m
guessing you don’t mean that or else you would probably not be very happy
with the fix.It should be just the ongoing test that terminates.
Bruce, I’m not sure if you are following this discussion. If I were to
clean up the fix a little would you consider merging it to the main branch?
Or do you prefer some other type of fix? By clean up code i mean adding
comments, adding better error message, and perhaps make the number of
seconds at which to timeout a #DEFINE value.
- Mikael
—
Reply to this email directly or view it on GitHub
#225 (comment).
@mkall: I’ve been peripherally following this…I’m working on several almost completely unrelated projects. I hope to find time to look at your patch soon.
@haukened: Linux isn’t the only open-source project, or indeed the only open-source operating system. From a former release engineer for FreeBSD.
Hello, I have to admit that this problem is haunting my server instance as well. (Built from latest git.)
Bruce, could you please take a look into this?
I am running iperf 3.0.11 using TCP under CentOS 6.5 and I am seeing a few issues.
If I disconnect the ethernet cable from the client, the server remains busy until I kill and restart the iperf3 server process.
I am also seeing cases where iperf3 doesn’t respond at all to a client. The server indicates that it is listening, but client connections hangs, then returns «iperf3: error — unable to receive control message: Connection reset by peer». Here is the lsof output for a iperf3 server port being used in this case (I know that it SAYS that its listening):
lsof | grep 55503
iperf3 28785 root 3u IPv6 2703599 0t0 TCP *:55503 (LISTEN)
iperf3 28785 root 4u IPv6 2705589 0t0 TCP xxxx:55503->xxxx:48790 (ESTABLISHED)
iperf3 28785 root 5u IPv6 2707433 0t0 TCP xxxx:55503->xxxx:48795 (CLOSE_WAIT)
iperf3 28785 root 7u IPv6 2755607 0t0 TCP xxxx:55503->xxxx:48962 (ESTABLISHED)
I have multiple 10G servers that are having this issue. I would be more than happy to assist with troubleshooting this issue.
I noticed also the stream sockets could be left hanging as well, so I added code to this fine patch from mkall to do that and submitted pull request.
dmdailey@f7fd67d
This was solved by pull request #446. Keeping this issue open to note that that code change needs to be merged.
#446 merged to 3.1-STABLE. Closing.
I have installed version 3.7 on both client and server machines and the problem persists, both with TCP and UDP connections. The server just won’t stop and/or restart when the client disconnects… I’m breaking the connection before the test duration ends and I’m using a Alpine machine (client) and a OpenWrt machine (server). I have not found any information about a possible server timeout in the iperf documentation. Am I missing something, or do other people have the same problem?
- Вся активность
В 28.06.2018 в 13:59, vvertexx сказал:
при чем тут стэк tcp/ip? Если подключен гиговым линком и у прова есть QoS — гигабита не будет.
Притом, что tcp может быть настроен так, что даже в одной локалке с 10г ты не увидишь и 10 мегабит.
QoS тоже сам по себе не отъедает ничего, это миф 15-и летней давности, когда вышла ХР где этот QoS впервые появился и якобы резервировал 20% скорости.
В 28.06.2018 в 16:56, rm_ сказал:
Вы городите какую-то дичь. Из поста в пост усердно «повторяясь». В гигабитной сети iperf реально получить
Это ты не въехал.
Гигабитный линк — это гигабит на л2, а клиент хочет гигабит на л3, который собственно и есть интернет, из за эзернет заголовков он свой гигабит на л3 никогда не получит пока у него линк л2 всего 1 гигабит.
23 часа назад, disappointed сказал:
Если до@бистый абонент сгенерирует поток ipv4 пакетов с пэйлоадом в 1 байт
Минимальный размер эзернет кадра по более будет, даже за вычетом заголовков.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
Мы в таких случаях клиенту в разрыв кабеля ставим микротик, настраиваем как роутер и подключаем к компу клиента. Он запускает свои там закачки и тесты и получает некую скорость. Часто видят, что скорость не полная. Тогда на втором компьютере, подключенному к этому же роутеру, начинаем делать параллельные закачки или одновременный тест на спидтест, и тут уже легко можно получить на каждом компе в районе 500М и всех все устраивает.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
В 28.06.2018 в 14:42, rm_ сказал:
Сами-то проверяли? Не работает, и не трейсится не пингуется даже.
все работает, версию смотрите.
у retn много публичных iperf на разных площадках.
может только для своих клиентов хз
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
Короче вывод — нужно писать — предоставляется порт доступа к сети интернет с такими-то характеристиками. Если даёте на всю пропускную порта.
А не доступ в интернет, c такими-то характеристиками.
Дьявол в деталях.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
9 часов назад, Artom_12 сказал:
з.ы. iperf3: error — unable to receive control message: Connection reset by peer
Версию ниже нужно взять.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
11 hours ago, Saab95 said:
Мы в таких случаях клиенту в разрыв кабеля ставим микротик, настраиваем как роутер и подключаем к компу клиента. Он запускает свои там закачки и тесты и получает некую скорость. Часто видят, что скорость не полная. Тогда на втором компьютере, подключенному к этому же роутеру, начинаем делать параллельные закачки или одновременный тест на спидтест, и тут уже легко можно получить на каждом компе в районе 500М и всех все устраивает.
Не получится. Нужно 2 микротика.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
10 hours ago, LostSoul said:
все работает, версию смотрите.
Что работает-то? Уже и домен убрали.
$ host speedtest.retn.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
Host speedtest.retn.net not found: 3(NXDOMAIN)
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, rm_ сказал:
Что работает-то? Уже и домен убрали.
проверил историю переписки , да IP адреса серверов iperf в разных точках RETN мне скидывали в виде IP.
Поэтому наверное публиковать их на форуме будет некорректно.
Но такие сервера есть.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
В 29.06.2018 в 18:22, StSphinx сказал:
А уж если клиент залупится, то достаточно просто доказать, что 20 мегбит это накладные расходы на передачу полезной информации.
Тогда иск за недостоверную рекламу. Судьи обычно сразу провайдера нахлобучивают, чтобы не умничал своими терминами ) 980 это не 1000 и все)
Изменено 2 июля, 2018 пользователем grfmaniak
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
5 часов назад, grfmaniak сказал:
Тогда иск за недостоверную рекламу. Судьи обычно сразу провайдера нахлобучивают, чтобы не умничал своими терминами ) 980 это не 1000 и все)
И пруфы есть на подобные судебные решения?
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
25 минут назад, StSphinx сказал:
И пруфы есть на подобные судебные решения?
Не знаю, есть ли это решение в инете. Подали в суд на клиента, который не хотел оплачивать долг. Судья долго слушал доводы про биллинг, тарифы, мегабайты-мегабиты, о том, как фиксируется факт подключения к инету (pppoe) и вынес решение «в иске отказать, так как оператор связи не имел права оказывать услуги связи без лицензии». Такой странный вывод он сделал на том основании, что приложенная к заявлению лицензия действовала на момент оказания услуги, но уже закончилась на момент рассмотрения дела. А то, что оператор давно получил новую лицензию, это вообще его не интересовало. Как и все речи про биллинг и прочие «непонятные вещи».
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, grfmaniak сказал:
Не знаю, есть ли это решение в инете. Подали в суд на клиента, который не хотел оплачивать долг. Судья долго слушал доводы про биллинг, тарифы, мегабайты-мегабиты, о том, как фиксируется факт подключения к инету (pppoe) и вынес решение «в иске отказать, так как оператор связи не имел права оказывать услуги связи без лицензии». Такой странный вывод он сделал на том основании, что приложенная к заявлению лицензия действовала на момент оказания услуги, но уже закончилась на момент рассмотрения дела. А то, что оператор давно получил новую лицензию, это вообще его не интересовало. Как и все речи про биллинг и прочие «непонятные вещи».
Это из другой оперы, хотя конечно интересно. Более чем уверен, что такое решение можно и нужно было обжаловать.
Но, думаю, обсуждение российских судов уже выходит за рамки топика.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
А что если в ядре поставить микротик и к клиенту ходить с другим микротиком, и приходить запускать bandwidth test?
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
20 минут назад, vvertexx сказал:
aab95, перелогинься
Да я понимаю, просто iperf это отдельные требования к серверу, ноуту с интеловой картой и т.п. Вот и думаю что быстрее и менее затратно.
Так то стоит железный iperf сервер на сети, хз что за железо, но выдает максимум 500-600мбит/с. Может кто поделится своими ключами запуска сервер/клиент iperf.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, iValera сказал:
А что если в ядре поставить микротик и к клиенту ходить с другим микротиком, и приходить запускать bandwidth test?
А ты думаешь дерьмовый тик за 1-3к руб прокачает гиг?
Любой комп с рылотеком и процом по более атомов-амд 4х летней давности способен гиг прокачать, особенно если там десктопный камень а не ноутбучный.
И для клиента это всё не понятно, я бы послал таких колхозников с тиками, это ваще не измерительное средство и не диагностический прибор.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
15 минут назад, Ivan_83 сказал:
А ты думаешь дерьмовый тик за 1-3к руб прокачает гиг?
А кто говорил дерьмовый? Попробуем для начала rb2011iL-IN.
Еще раз поясню, этот тик выписывается со склада и на след день на стенде. А искать сервер, неттоп и т.п. занимает куда больше времени с последующей возьней настройки.
Клиенту может быть не понятен и iperf, он предложит запустить его у себя на vds хостинге и тютю, далее уже пошла юридичная возня и т.п.
Вобщем никто не спорит что железный iperf лучше чем тик, но если тик покажет состоятельность, то практичнее использовать будет его. т.к. не нужны будут поголовные обновления ноутов у ремонтников
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
Укажите, какая задержка у абонента. Может быть проблема упирается в законы физики и при высокой задержке нельзя преодолеть определенную скорость загрузки в один поток.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
@iValera микротик > speedtest
Да он вам покажит красивые попугай. Недавно мерил канал точка точка stx канальная скорость 144 mb/s местный тестер даёт 140+ туда обратно, speedtest показал 120, на iperf выдало, чуть больше 120-130
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
19 часов назад, iValera сказал:
Еще раз поясню, этот тик выписывается со склада и на след день на стенде. А искать сервер, неттоп и т.п. занимает куда больше времени с последующей возьней настройки.
Если у вас нет сервера (хотя бы из системника с помойки) то вы какие то пионеры-нищеброды.
Неттоп не нужен, хватить вменяемого ноута, вероятно USB3 сетевуха на гиг тоже сойдёт, если ноут дешманский.
19 часов назад, iValera сказал:
Клиенту может быть не понятен и iperf, он предложит запустить его у себя на vds хостинге и тютю, далее уже пошла юридичная возня и т.п.
Такому клиенту вы нафик не упали он сам протестит и за порог ваших спецов не пустит — меряйте от своего свича.
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
В 30.06.2018 в 00:34, witch сказал:
iperf.exe -c ground.corbina.net -p 50000 -w64k -t 60 -P 5
Хихис, ттк тестит многопотоково и по udp Со своим буком Скорость при этом рисуется обуенная. Боролись давно — пинг с кошки до их гейта пропадал, а по винде — нет траблем. Дохляк их медиаконвертора…
-
Вставить ник
- Цитата
- Ответить с цитированием
Поделиться сообщением
Ссылка на сообщение
Поделиться на других сайтах
- Назад
- 1
- 2
- 3
- Вперёд
- Страница 2 из 3
Join the conversation
You can post now and register later.
If you have an account, sign in now to post with your account.
-
Войти
- ВОПРОСЫ
- Форум техподдержки
-
Техническая поддержка / Support
- По работе туннелей и маршрутизации / VPN tuns & routing
- Вопиюще низкая скорость соединения через VPN-мост.
2 года 1 нед. назад — 2 года 1 нед. назад #6425
от Mast
Проблема:
Очень низкая скорость траффика по VPN-туннелям.
Система:
1. Туннели user11801 и user11854.
2. РРtP без шифрования.
3. C обоих концов роутеры на OpenWRT:
— на хазе OpenWRT-роутер LAN-портом подключен в LAN-порт основного роутера, в который приходит оптика.
— на даче OpenWRT-роутер LAN-портом подключен в LAN-порт основного роутера, в который через USB-порт подключен 3G-модем (именно RAS подключение «как модем», а не NDIS-сетевая-карта, т.е. там NAT’а нет)
4. Тарифный план был сперва тестовый, потом за 40руб-PLAN-MYDEV, потом перешел на 100руб-PLAN-VIDEO
5. IP-адреса с обоих концов, ествественно, серые.
Все работает довольно устойчиво.
Написаны скрипты:
— перегрузки рртр-интерфейсов по отвалу пинга фейс на фейс, т.е. друг на друга
— перегрузки самого роутера по отсутствию пинга в интернет
— перегрузки самого роутера по шедулеру раз в сутки
Тунели падают раза 3-4 в сутки, о чем получаю письмена от сервера VPNKI, но восстанавливаются сами. Эти падения не критичны.
Но вот пришло время использовать систему для её основного назначения:
Система построена для прослушивания музыки на даче в формате flac, с использованием на даче программы foobar2000, с файлового сервера, который установлен дома.
Тарифные планы:
На тарифном плане PLAN-MYDEV, завяленная Cкорость до 0,5 МБит/с на туннель, — музло заикалось. В реале скорость не мерял, т.к. 0.5мбитс внатуре мало для прокачки foobar’ом несжатых flac-файлов. Битрейт моего мулза от 800кбпс до 1800кбпс. (Всего лишь 1.8мегабит, +служебка, +паразитный от иных устройств, ну пусть будет 2мегабита, но 2 же должно пролазить в заявленные 2.5!
Проблема, что и 800кбпс за-за-заикается!
(об отмороженных битрейтах типа 192Khz/24 bit stereo PCM audio FLAC, bitrate 9216kbps — речь ваще не ведём)
Поэтому перешел на PLAN-VIDEO, заявленная скорость до 2,5 Мбит/с на туннель. Музло продолжило точно так же за-за-икаться.
Померял скорость на даче через ВПН-туннель.
~0.35 мегабита/сек
КАК МЕРЯЛ:
поставил на дачном компе (OS win7, комп в роутер подключен LAN-кабелем, проблем скорости через LAN по дачной сети нет ваще,) большой файл на закачку.
— Хотел дать разогнаться закачке, но скорость не менялась, с самого начала до конца теста была одинаковой.
— Таймером засек загрузку на комп фрагмента файла в 10мб.
Получилось время: 4минуты 3 секунды. Повторные тесты подтвердили это время +/- пару секунд туда-сюда на реакцию нажатия на таймер.
10мбайт х 8 = 80мбит : (4мин х 60сек = 240сек + 3секи =243 секи ) = 0.329мегабитсек
У себя все просмотрел. В домашней сети с файлохранилища скорость, как положено, высокая. Качнуло на комп 250мб за 15сек.
ИНЕТы
Скорость инета на хазе всегда не менее 20мегабитсек.
Скорость инета на даче (ЗG-модем воткнут в роутер, внешняя антенна) всегда не менее 8мегабитсек.
Скорость проверялась через спидтест.нет , вручную выбирался сервер за пределами страны.
Wi-Fi, Bluetooth, Zig-Bee и прочие иные беспроводные технологии вс ети НЕ используются ваще. Только чистый Ethernet-LAN UTP 5-я категория.
Прошу суппорт помочь и указать, что у меня не так. Сам найти ошибку в настройках не могу.
На такой скорости ситема полностью теряет смысл.
Дачные камеры на домашнем компе могу смотреть тока в Low-Res SD-качетсво. (Использую VLC по протоколу RTSP). Hi-Res (HD-качество) не загружается.
После изменения тарифного плана с 40руб-PLAN-MYDEV на 100руб-PLAN-VIDEO в скорости ничего не поменялось.
Последнее редактирование: 2 года 1 нед. назад пользователем Mast.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
2 года 1 нед. назад — 2 года 1 нед. назад #6428
от admin
Так быть не должно. Давайте разбираться.
Пришлите вывод:
— ping msk.vpnki.ru с обоих рутеров
— ping 172.16.0.1 с обоих рутеров
Я запустил вам на сервере VPNKI сервер iperf3 для измерения скорости. Он слушает на порту 43000 TCP и 43000 UDP. Чтобы воспользоваться этим сервером вам нужно поставить утилиту iperf3 на компьютеры c Windows с обоих сторон (или думаю что есть утилита для OpenWRT).
для Windows команды будут такие:
Для измерения по TCP: iperf3.exe -c 172.16.0.1 -p 43000
Для измерения по UDP: iperf3.exe -c 172.16.0.1 -p 43000 -u -f m -b 10M
Выполните тест скорости по протоколам TCP и UDP с обоих сторон и пришлите вывод.
Последнее редактирование: 2 года 1 нед. назад пользователем admin.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
2 года 1 нед. назад — 2 года 1 нед. назад #6432
от Mast
Большое спасибо за отклик!
Погнали!
===========
1.
Пинги с Хазы:
PING msk.vpnki.ru (84.201.157.25): 56 data bytes
64 bytes from 84.201.157.25: seq=0 ttl=54 time=18.748 ms
64 bytes from 84.201.157.25: seq=1 ttl=54 time=17.745 ms
64 bytes from 84.201.157.25: seq=2 ttl=54 time=19.293 ms
64 bytes from 84.201.157.25: seq=3 ttl=54 time=17.617 ms
64 bytes from 84.201.157.25: seq=4 ttl=54 time=17.668 ms
— msk.vpnki.ru ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 17.617/18.214/19.293 ms
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=64 time=25.981 ms
64 bytes from 172.16.0.1: seq=1 ttl=64 time=18.278 ms
64 bytes from 172.16.0.1: seq=2 ttl=64 time=15.883 ms
64 bytes from 172.16.0.1: seq=3 ttl=64 time=15.109 ms
64 bytes from 172.16.0.1: seq=4 ttl=64 time=17.638 ms
— 172.16.0.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 15.109/18.577/25.981 ms
2.
Пинги с Дачи:
PING msk.vpnki.ru (84.201.157.25): 56 data bytes
64 bytes from 84.201.157.25: seq=0 ttl=53 time=59.417 ms
64 bytes from 84.201.157.25: seq=1 ttl=53 time=50.955 ms
64 bytes from 84.201.157.25: seq=2 ttl=53 time=50.881 ms
64 bytes from 84.201.157.25: seq=3 ttl=53 time=58.428 ms
64 bytes from 84.201.157.25: seq=4 ttl=53 time=50.162 ms
— msk.vpnki.ru ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 50.162/53.968/59.417 ms
_____
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=64 time=77.121 ms
64 bytes from 172.16.0.1: seq=1 ttl=64 time=684.742 ms
64 bytes from 172.16.0.1: seq=2 ttl=64 time=76.402 ms
64 bytes from 172.16.0.1: seq=3 ttl=64 time=184.006 ms
64 bytes from 172.16.0.1: seq=4 ttl=64 time=74.880 ms
— 172.16.0.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 74.880/219.430/684.742 ms
3.
iperf3 3.5-1
(Iperf is a modern alternative for measuring TCP and UDP bandwidth performance, allowing the tuning of various parameters and characteristics)
root@Haza:~# iperf3
iperf3: parameter error — must either be a client (-c) or server (-s)
Usage: iperf3 [-s|-c host] [options]
iperf3 [-h|—help] [-v|—version]
4.
ИПРЕФ3 с Хазы по ТСР
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.26 port 48392 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 650 KBytes 5.32 Mbits/sec 92 9.58 KBytes
[ 5] 1.00-2.00 sec 408 KBytes 3.34 Mbits/sec 1 12.3 KBytes
[ 5] 2.00-3.00 sec 341 KBytes 2.79 Mbits/sec 0 13.7 KBytes
[ 5] 3.00-4.00 sec 529 KBytes 4.34 Mbits/sec 8 13.7 KBytes
[ 5] 4.00-5.00 sec 408 KBytes 3.34 Mbits/sec 9 10.9 KBytes
[ 5] 5.00-6.00 sec 495 KBytes 4.06 Mbits/sec 7 9.58 KBytes
[ 5] 6.00-7.00 sec 259 KBytes 2.12 Mbits/sec 0 13.7 KBytes
[ 5] 7.00-8.00 sec 565 KBytes 4.63 Mbits/sec 5 6.84 KBytes
[ 5] 8.00-9.00 sec 300 KBytes 2.45 Mbits/sec 7 8.21 KBytes
[ 5] 9.00-10.00 sec 528 KBytes 4.32 Mbits/sec 0 15.0 KBytes
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 4.38 MBytes 3.67 Mbits/sec 129 sender
[ 5] 0.00-10.00 sec 4.28 MBytes 3.59 Mbits/sec receiver
iperf Done.
ИПРЕФ3 с Хазы по ЮДП
iperf Done.
root@Haza:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 10M
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.26 port 53855 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 1.00-2.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 3.00-4.00 sec 1.19 MBytes 10.0 Mbits/sec 893
[ 5] 4.00-5.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 5.00-6.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 6.00-7.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 7.00-8.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 893
[ 5] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 892
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.000 ms 0/8922 (0%) sender
[ 5] 0.00-10.00 sec 4.77 MBytes 4.00 Mbits/sec 0.462 ms 5352/8922 (60%) receiver
iperf Done.
5.
ИПРЕФ3 ТСР с дачи!
root@GAR:~# iperf3 -c 172.16.0.1 -p 43000
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.73 port 40898 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 39.7 KBytes 325 Kbits/sec 8 10.9 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 10.9 KBytes
[ 5] 2.00-3.00 sec 21.9 KBytes 179 Kbits/sec 1 12.3 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 5.47 KBytes
[ 5] 4.00-5.00 sec 17.8 KBytes 146 Kbits/sec 1 8.21 KBytes
[ 5] 5.00-6.00 sec 49.3 KBytes 404 Kbits/sec 2 9.58 KBytes
[ 5] 6.00-7.00 sec 43.8 KBytes 359 Kbits/sec 2 5.47 KBytes
[ 5] 7.00-8.00 sec 53.4 KBytes 437 Kbits/sec 1 5.47 KBytes
[ 5] 8.00-9.00 sec 41.0 KBytes 336 Kbits/sec 1 8.21 KBytes
[ 5] 9.00-10.00 sec 67.0 KBytes 549 Kbits/sec 2 9.58 KBytes
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 334 KBytes 273 Kbits/sec 19 sender
[ 5] 0.00-10.00 sec 311 KBytes 254 Kbits/sec receiver
iperf Done.
6.
ИПРЕФ3 ТСР с дачи!
при проведении ЮДП теста походу повесился сперва рутер основного инета (или свет руанули на даче, что маловероятно)…
перегузил ГСМ-розеткой.
потом какая-то муть на стороне ВПН-рутера.
перегрузил полностью ви-фи розеткой
но
root@GAR:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 10M
iperf3: error — the server is busy running a test. try again later
и это после ХАРД-Ребута впн-роутера.
7.
перегружаю и основной и впн роутеры еще раз.
Походу на стороне Хазы проблем нет.
Муть на даче. Имею еще 1 ВПН-роутер, еще один основной роутер и 3G-модем другой.
Разберемся щас.
…
8.
на Даче хардово перегрузил И оснРоутер и впнРоутер
root@GAR:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 10M
iperf3: error — the server is busy running a test. try again later
странно как-то..
поеду посмотрю как там дела. попробую с ТОЙ стороны..
до связи!
Последнее редактирование: 2 года 1 нед. назад пользователем Mast.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
2 года 1 нед. назад — 2 года 1 нед. назад #6433
от admin
Да, есть проблема на стороне Дачи.
Предполагаю, что проблем там две — PPTP через сотового провайдера может работать очень странно. Низкая скорость возможно связана с рассинхронизацией передачи трафика и управляющим трафиком туннеля. Может быть имеет смысл поменять протокол. Например на OpenVPN.
Вторая проблема — при тесте UDP я специально поставил ограничение в команде в 10Мбит/c. И после этого произошла перезагрузка рутера. Видимо рутер полностью забивает канал и перезагружается из-за нехватки CPU или памяти при упаковке датаграмм UDP в PPTP. Так что возможно, что проблема и с ним. Попробуйте в команде снизить максимальную скорость теста до 5Мбит/c или меньше
PS: на сервере VPNKI перегрузил процесс iperf, на всякий случай. Хотя он вроде нормально работал.
Последнее редактирование: 2 года 1 нед. назад пользователем admin.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
2 года 1 нед. назад — 2 года 1 нед. назад #6436
от Mast
приехал на дачу.
привез второй опенвпн-роутер настроенный на ВПНКИ.
пробую со старого пока.
для начала исключим Хазу.
С Хазы изнутри рутера пингуем.
1.
PING msk.vpnki.ru (84.201.157.25): 56 data bytes
64 bytes from 84.201.157.25: seq=0 ttl=54 time=19.071 ms
64 bytes from 84.201.157.25: seq=1 ttl=54 time=21.356 ms
64 bytes from 84.201.157.25: seq=2 ttl=54 time=17.745 ms
64 bytes from 84.201.157.25: seq=3 ttl=54 time=17.960 ms
64 bytes from 84.201.157.25: seq=4 ttl=54 time=18.634 ms
— msk.vpnki.ru ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 17.745/18.953/21.356 ms
2.
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=64 time=14.762 ms
64 bytes from 172.16.0.1: seq=1 ttl=64 time=19.185 ms
64 bytes from 172.16.0.1: seq=2 ttl=64 time=14.430 ms
64 bytes from 172.16.0.1: seq=3 ttl=64 time=14.499 ms
64 bytes from 172.16.0.1: seq=4 ttl=64 time=19.753 ms
— 172.16.0.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.430/16.525/19.753 ms
3.
Скорость с хазы ТСР
root@Haza:~# iperf3 -c 172.16.0.1 -p 43000
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.26 port 48398 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 733 KBytes 6.01 Mbits/sec 164 10.9 KBytes
[ 5] 1.00-2.00 sec 353 KBytes 2.89 Mbits/sec 0 10.9 KBytes
[ 5] 2.00-3.00 sec 529 KBytes 4.34 Mbits/sec 8 8.21 KBytes
[ 5] 3.00-4.00 sec 435 KBytes 3.56 Mbits/sec 0 12.3 KBytes
[ 5] 4.00-5.00 sec 524 KBytes 4.29 Mbits/sec 6 10.9 KBytes
[ 5] 5.00-6.00 sec 442 KBytes 3.62 Mbits/sec 6 8.21 KBytes
[ 5] 6.00-7.00 sec 445 KBytes 3.64 Mbits/sec 0 12.3 KBytes
[ 5] 7.00-8.00 sec 443 KBytes 3.63 Mbits/sec 0 13.7 KBytes
[ 5] 8.00-9.00 sec 352 KBytes 2.88 Mbits/sec 0 13.7 KBytes
[ 5] 9.00-10.00 sec 263 KBytes 2.15 Mbits/sec 0 13.7 KBytes
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 4.41 MBytes 3.70 Mbits/sec 184 sender
[ 5] 0.00-10.00 sec 4.24 MBytes 3.56 Mbits/sec receiver
iperf Done.
4.
Скорость с хазы UDP
root@Haza:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 10M
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.26 port 49375 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 1.00-2.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 3.00-4.00 sec 1.19 MBytes 10.0 Mbits/sec 893
[ 5] 4.00-5.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 5.00-6.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 6.00-7.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 7.00-8.00 sec 1.19 MBytes 10.0 Mbits/sec 893
[ 5] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 892
[ 5] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 892
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.000 ms 0/8922 (0%) sender
[ 5] 0.00-10.00 sec 4.77 MBytes 4.00 Mbits/sec 0.575 ms 5353/8922 (60%) receiver
iperf Done.
Тут разобрались. Походу Хаза НЕ вызывает затыки и за-зайкания моего музла.
Идем дальше.
!! ДАЧА !!
Пинги
root@GAR:~# ping msk.vpnki.ru
PING msk.vpnki.ru (84.201.157.25): 56 data bytes
64 bytes from 84.201.157.25: seq=0 ttl=53 time=99.236 ms
64 bytes from 84.201.157.25: seq=1 ttl=53 time=59.001 ms
64 bytes from 84.201.157.25: seq=2 ttl=53 time=58.672 ms
64 bytes from 84.201.157.25: seq=3 ttl=53 time=62.377 ms
64 bytes from 84.201.157.25: seq=4 ttl=53 time=58.095 ms
64 bytes from 84.201.157.25: seq=5 ttl=53 time=57.836 ms
64 bytes from 84.201.157.25: seq=6 ttl=53 time=57.610 ms
64 bytes from 84.201.157.25: seq=7 ttl=53 time=57.454 ms
64 bytes from 84.201.157.25: seq=8 ttl=53 time=56.985 ms
64 bytes from 84.201.157.25: seq=9 ttl=53 time=68.715 ms
64 bytes from 84.201.157.25: seq=10 ttl=53 time=68.453 ms
64 bytes from 84.201.157.25: seq=11 ttl=53 time=56.177 ms
64 bytes from 84.201.157.25: seq=12 ttl=53 time=67.912 ms
64 bytes from 84.201.157.25: seq=13 ttl=53 time=68.969 ms
64 bytes from 84.201.157.25: seq=14 ttl=53 time=67.367 ms
64 bytes from 84.201.157.25: seq=15 ttl=53 time=67.078 ms
64 bytes from 84.201.157.25: seq=16 ttl=53 time=66.772 ms
64 bytes from 84.201.157.25: seq=17 ttl=53 time=66.495 ms
^C
root@GAR:~# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=64 time=57.142 ms
64 bytes from 172.16.0.1: seq=1 ttl=64 time=56.751 ms
64 bytes from 172.16.0.1: seq=2 ttl=64 time=56.441 ms
64 bytes from 172.16.0.1: seq=3 ttl=64 time=68.072 ms
64 bytes from 172.16.0.1: seq=4 ttl=64 time=67.751 ms
64 bytes from 172.16.0.1: seq=5 ttl=64 time=67.389 ms
64 bytes from 172.16.0.1: seq=6 ttl=64 time=67.030 ms
64 bytes from 172.16.0.1: seq=7 ttl=64 time=66.691 ms
64 bytes from 172.16.0.1: seq=8 ttl=64 time=67.803 ms
64 bytes from 172.16.0.1: seq=9 ttl=64 time=66.011 ms
64 bytes from 172.16.0.1: seq=10 ttl=64 time=73.602 ms
64 bytes from 172.16.0.1: seq=11 ttl=64 time=65.315 ms
^C
ДАЧА ТСР
root@GAR:~# iperf3 -c 172.16.0.1 -p 43000
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.73 port 34592 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 27.4 KBytes 224 Kbits/sec 0 17.8 KBytes
[ 5] 1.00-2.00 sec 9.58 KBytes 78.5 Kbits/sec 7 12.3 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 12.3 KBytes
[ 5] 3.00-4.00 sec 41.0 KBytes 337 Kbits/sec 2 12.3 KBytes
[ 5] 4.00-5.00 sec 83.5 KBytes 683 Kbits/sec 0 16.4 KBytes
[ 5] 5.00-6.00 sec 20.5 KBytes 168 Kbits/sec 2 10.9 KBytes
[ 5] 6.00-7.00 sec 13.7 KBytes 112 Kbits/sec 1 6.84 KBytes
[ 5] 7.00-8.00 sec 61.6 KBytes 504 Kbits/sec 1 9.58 KBytes
[ 5] 8.00-9.00 sec 112 KBytes 920 Kbits/sec 0 15.0 KBytes
[ 5] 9.00-10.00 sec 97.1 KBytes 796 Kbits/sec 1 13.7 KBytes
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 467 KBytes 382 Kbits/sec 14 sender
[ 5] 0.00-10.00 sec 431 KBytes 353 Kbits/sec receiver
iperf Done.
ДАЧА ЮДП на 3М
root@GAR_171:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 3M
Connecting to host 172.16.0.1, port 43000
[ 5] local 172.16.41.73 port 42670 connected to 172.16.0.1 port 43000
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 367 KBytes 3.00 Mbits/sec 268
[ 5] 1.00-2.00 sec 367 KBytes 2.99 Mbits/sec 268
[ 5] 2.00-3.00 sec 365 KBytes 3.00 Mbits/sec 267
[ 5] 3.00-4.00 sec 367 KBytes 3.00 Mbits/sec 268
[ 5] 4.00-5.00 sec 367 KBytes 3.00 Mbits/sec 268
[ 5] 5.00-6.00 sec 365 KBytes 2.99 Mbits/sec 267
[ 5] 6.00-7.00 sec 367 KBytes 3.00 Mbits/sec 268
[ 5] 7.00-8.00 sec 367 KBytes 3.00 Mbits/sec 268
[ 5] 8.00-9.00 sec 365 KBytes 2.99 Mbits/sec 267
[ 5] 9.00-10.00 sec 367 KBytes 3.00 Mbits/sec 268
— — — — — — — — — — — — — — — — — — — — — — — — —
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 3.58 MBytes 3.00 Mbits/sec 0.000 ms 0/2677 (0%) sender
[ 5] 0.00-10.00 sec 2.71 MBytes 2.27 Mbits/sec 2.386 ms 648/2677 (24%) receiver
iperf Done.
Дача ЮДП на 4м
вызывает полный забой канала. связь putty дачного компа с роутером-впн на Хазе обрывается.
Инет пропал.
основной роутер — НЕ висит.
3G-модем — завис! Не виден основным роутером, куда он воткнут в ЮСБ-порт.
Перегружаю ОБА роутера на даче.
ЮДП тест с Дачи
root@GAR:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 3M
iperf3: error — the server is busy running a test. try again later
что-то где-то висит…
делаю сразу ЮДП тест с Хазы
root@Haza_170:~# iperf3 -c 172.16.0.1 -p 43000 -u -f m -b 3M
iperf3: error — the server is busy running a test. try again later
Походу ВИСИТ iperf3 на сервере VPNKI
Ладно. Идем дальше. проверяем 3G-провайдера на вшивость по РРТР
Соединяюсь с дачи со сторонним VPN-провайдером, который дает доступ в интернет по РРТР-протоколу.
Делаю спидтест.нет
PING ms 62
СКАЧАТЬ Mbps 9.84
ЗАГРУЗИТЬ Mbps 2.30
Хм.. как бы 3Г-провадер НЕ при деле.
Ни основной роутер, ни 3Г модем не повесился.
через 3Г + иностранный VPN-сервер пингую с Дачи
root@GAR_171:~# ping msk.vpnki.ru
PING msk.vpnki.ru (84.201.157.25): 56 data bytes
64 bytes from 84.201.157.25: seq=0 ttl=53 time=59.335 ms
64 bytes from 84.201.157.25: seq=1 ttl=53 time=59.081 ms
64 bytes from 84.201.157.25: seq=2 ttl=53 time=46.733 ms
64 bytes from 84.201.157.25: seq=3 ttl=53 time=46.463 ms
64 bytes from 84.201.157.25: seq=4 ttl=53 time=43.396 ms
64 bytes from 84.201.157.25: seq=5 ttl=53 time=55.089 ms
64 bytes from 84.201.157.25: seq=6 ttl=53 time=46.896 ms
64 bytes from 84.201.157.25: seq=7 ttl=53 time=54.520 ms
64 bytes from 84.201.157.25: seq=8 ttl=53 time=54.282 ms
^C
Скорость померять НЕ могу
ИПРЕФ3 висит на сервере ВПНКИ
root@GAR:~# iperf3 -c 172.16.0.1 -p 43000
iperf3: error — unable to receive control message: Connection reset by peer
Мой вывод:
3Г-провайдер НЕ блокирует и не гадит в РРТР
что-то происходит или на роутере или на сервере ВПНКИ
Последнее редактирование: 2 года 1 нед. назад пользователем Mast.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
2 года 1 нед. назад — 2 года 1 нед. назад #6438
от Mast
3Г-модем подключен к первичному провайдеру.
Потом через VPN-сервер, РРтР, от третьей стороны выхожу в интернет.
projectstream.google.com/speedtest
Your connection isn’t ready for Stadia yet.
Your download speed of 4.469 Mbps is below the 10 Mbps we recommend to stream games on Stadia. Improve your internet connection and then check it again.
ВСЁ ГУТ.
зы.
кстати.
сравните IP в моем первом посте и в этом.
зы.
первичный инет без стороннего ВПН-рртр-сервера
Your connection isn’t ready for Stadia yet.
Your download speed of 8.837 Mbps is below the 10 Mbps we recommend to stream games on Stadia. Improve your internet connection and then check it again.
Последнее редактирование: 2 года 1 нед. назад пользователем Mast.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- ВОПРОСЫ
- Форум техподдержки
- Техническая поддержка / Support
- По работе туннелей и маршрутизации / VPN tuns & routing
- Вопиюще низкая скорость соединения через VPN-мост.
Время создания страницы: 0.142 секунд
- 0
-
- Share
Hi. I’m having the problem that I don’t know what your question is.
I think others will have the same. Could you please formulate your question?
And maybe also give the output of armbianmonitor -u
- Quote
Link to comment
Share on other sites
- 0
-
- Share
@Zageron Yeah please formulate a clear question.
To check if tx offloading is on or off
ethtool -k eth1 | grep tx-checksum
Currently TX checksum offload for all network interfaces on rockchip64 family is disable in Armbian by default.
- Quote
Link to comment
Share on other sites
- 0
- Author
-
- Share
19 hours ago, gprovost said:
@Zageron Yeah please formulate a clear question.
To check if tx offloading is on or off
ethtool -k eth1 | grep tx-checksumCurrently TX checksum offload for all network interfaces on rockchip64 family is disable in Armbian by default.
Yay 24 hour delay is over. This is regarding the degraded performance of the 2.5gbe on 5.8. I am unsure if my iperf results are aligning with what others are seeing. Given that tx offload is definitely off, I assume so.
Formulated context and question:
I have just put my helios64 together. I am seeing degraded performance of the 2.5gbe interface as warned.
The notes I saw everywhere were «disable tx checksum offload».
How do I check if tx offloading is on or off?
I tested with ethtool, and yes it is off.
❯ sudo ethtool -k eth1 | grep tx-checksum
tx-checksumming: off
tx-checksum-ipv4: off
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
I assume I have nothing else to do but wait for patches to improve the degraded performance at this point?
Thanks for your patience and your answers!
- Quote
Link to comment
Share on other sites
- 0
-
- Share
You performance is not aligned with what we see on our side.
Instead of getting 2.35 Gbit/s when TX offload works (e.g on LK4.4), with TX checksum offload disable, you should get around 1.8 Gbit/s
You sure TX offload is off on both side ?
- Quote
Link to comment
Share on other sites
- 0
- Author
-
- Share
The other end looks like this:
PS C:UsersZageronExercismrustproverb> NetAdapterChecksumOffload
Name IpIPv4Enabled TcpIPv4Enabled TcpIPv6Enabled UdpIPv4Enabled UdpIPv6Enabled
vEthernet (WSL) RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled
Helios Direct Disabled Disabled Disabled Disabled Disabled
LAN WAN RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled
vEthernet (Default Switch) RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled RxTxEnabled
I managed to get performance up to 2.21 gbps by switching mtu to 9000 on both sides.
PS C:UsersZageronExercismrustproverb> iperf3.exe -c helios64.local
Connecting to host helios64.local, port 5201
[ 4] local 192.167.0.1 port 1504 connected to 192.167.0.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 261 MBytes 2.19 Gbits/sec
[ 4] 1.00-2.00 sec 261 MBytes 2.19 Gbits/sec
[ 4] 2.00-3.00 sec 260 MBytes 2.18 Gbits/sec
[ 4] 3.00-4.00 sec 264 MBytes 2.22 Gbits/sec
[ 4] 4.00-5.00 sec 264 MBytes 2.21 Gbits/sec
[ 4] 5.00-6.00 sec 265 MBytes 2.22 Gbits/sec
[ 4] 6.00-7.00 sec 266 MBytes 2.23 Gbits/sec
[ 4] 7.00-8.00 sec 261 MBytes 2.19 Gbits/sec
[ 4] 8.00-9.00 sec 263 MBytes 2.21 Gbits/sec
[ 4] 9.00-10.00 sec 266 MBytes 2.23 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 2.57 GBytes 2.21 Gbits/sec sender
[ 4] 0.00-10.00 sec 2.57 GBytes 2.21 Gbits/sec receiver
However, resetting tx and rx offloading to default on on both ends results in the exact same performance. (2.21gbps)
fyi mtu was set on linux with
sudo nmcli con modify <interfaceuuid> ethernet.mtu 9000
Edited November 25, 2020 by Zageron
Added instructoins for making mtu changes permenant.
- Quote
Link to comment
Share on other sites
- 0
-
- Share
Ok interesting.
On my side I don’t see any iperf difference increasing MTU beside seeing more retries.
Here my perf with default MTU 1500.
Helios64 Transmitting (TX checksum offload disabled)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.10.10.254, port 59252
[ 5] local 10.10.10.2 port 5201 connected to 10.10.10.254 port 59254
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.01 sec 177 MBytes 1.48 Gbits/sec 0 4.29 MBytes
[ 5] 1.01-2.01 sec 224 MBytes 1.88 Gbits/sec 0 4.29 MBytes
[ 5] 2.01-3.01 sec 224 MBytes 1.88 Gbits/sec 0 4.29 MBytes
[ 5] 3.01-4.01 sec 221 MBytes 1.85 Gbits/sec 0 4.29 MBytes
[ 5] 4.01-5.01 sec 220 MBytes 1.85 Gbits/sec 0 4.29 MBytes
[ 5] 5.01-6.01 sec 218 MBytes 1.82 Gbits/sec 0 4.29 MBytes
[ 5] 6.01-7.01 sec 201 MBytes 1.69 Gbits/sec 0 4.29 MBytes
[ 5] 7.01-8.01 sec 222 MBytes 1.87 Gbits/sec 0 4.29 MBytes
[ 5] 8.01-9.01 sec 216 MBytes 1.81 Gbits/sec 0 4.29 MBytes
[ 5] 9.01-10.00 sec 220 MBytes 1.86 Gbits/sec 0 4.29 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.09 GBytes 1.80 Gbits/sec 0 sender
Helios64 Receiving
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.10.10.254, port 59256
[ 5] local 10.10.10.2 port 5201 connected to 10.10.10.254 port 59258
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 261 MBytes 2.19 Gbits/sec
[ 5] 1.00-2.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 2.00-3.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 3.00-4.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 4.00-5.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 5.00-6.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 6.00-7.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 7.00-8.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 8.00-9.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 10.00-10.00 sec 601 KBytes 2.37 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.72 GBytes 2.34 Gbits/sec receiver
Just for the sake of clarification because iperf can be confusing. By default iperf client test upload speed.
iperf -c <helios64-ip> = test RX speed of Helios64
iperd -c <helios64-ip> -R = test TX speed of Helios64
- Quote
Link to comment
Share on other sites
- 0
- Author
-
- Share
Default Offload Settings with 9000 MTU:
PS L:> iperf3.exe -c helios64.local
Connecting to host helios64.local, port 5201
[ 4] local 192.167.0.1 port 59373 connected to 192.167.0.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 237 MBytes 1.98 Gbits/sec
[ 4] 1.00-2.00 sec 255 MBytes 2.14 Gbits/sec
[ 4] 2.00-3.00 sec 248 MBytes 2.08 Gbits/sec
[ 4] 3.00-4.00 sec 241 MBytes 2.02 Gbits/sec
[ 4] 4.00-5.00 sec 250 MBytes 2.10 Gbits/sec
[ 4] 5.00-6.00 sec 244 MBytes 2.05 Gbits/sec
[ 4] 6.00-7.00 sec 241 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 254 MBytes 2.13 Gbits/sec
[ 4] 8.00-9.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 9.00-10.00 sec 221 MBytes 1.85 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 2.37 GBytes 2.04 Gbits/sec sender
[ 4] 0.00-10.00 sec 2.37 GBytes 2.04 Gbits/sec receiver
iperf Done.
PS L:> iperf3.exe -c helios64.local -R
Connecting to host helios64.local, port 5201
Reverse mode, remote host helios64.local is sending
[ 4] local 192.167.0.1 port 59414 connected to 192.167.0.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 82.8 MBytes 687 Mbits/sec
[ 4] 1.01-2.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.01-3.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.01-4.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.01-5.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.01-6.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.01-7.02 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.02-8.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 8.01-9.01 sec 0.00 Bytes 0.00 bits/sec
iperf3: error - unable to receive control message: Connection reset by peer
Crashed the connection. Unable to use connection until rebooting Helios64 unit.
TX Offloading disabled 1500 MTU:
PS L:> iperf3.exe -c helios64.local
Connecting to host helios64.local, port 5201
[ 4] local 192.167.0.1 port 3691 connected to 192.167.0.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 156 MBytes 1.31 Gbits/sec
[ 4] 1.00-2.00 sec 163 MBytes 1.37 Gbits/sec
[ 4] 2.00-3.00 sec 124 MBytes 1.04 Gbits/sec
[ 4] 3.00-4.00 sec 99.9 MBytes 839 Mbits/sec
[ 4] 4.00-5.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 5.00-6.01 sec 160 MBytes 1.32 Gbits/sec
[ 4] 6.01-7.00 sec 98.4 MBytes 836 Mbits/sec
[ 4] 7.00-8.00 sec 112 MBytes 941 Mbits/sec
[ 4] 8.00-9.00 sec 176 MBytes 1.48 Gbits/sec
[ 4] 9.00-10.00 sec 148 MBytes 1.25 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 1.36 GBytes 1.17 Gbits/sec sender
[ 4] 0.00-10.00 sec 1.36 GBytes 1.17 Gbits/sec receiver
iperf Done.
PS L:> iperf3.exe -c helios64.local -R
Connecting to host helios64.local, port 5201
Reverse mode, remote host helios64.local is sending
[ 4] local 192.167.0.1 port 3720 connected to 192.167.0.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 211 MBytes 1.77 Gbits/sec
[ 4] 1.00-2.00 sec 248 MBytes 2.08 Gbits/sec
[ 4] 2.00-3.00 sec 237 MBytes 1.98 Gbits/sec
[ 4] 3.00-4.00 sec 211 MBytes 1.77 Gbits/sec
[ 4] 4.00-5.00 sec 186 MBytes 1.56 Gbits/sec
[ 4] 5.00-6.00 sec 205 MBytes 1.72 Gbits/sec
[ 4] 6.00-7.00 sec 218 MBytes 1.83 Gbits/sec
[ 4] 7.00-8.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 8.00-9.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 9.00-10.00 sec 220 MBytes 1.85 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 2.07 GBytes 1.78 Gbits/sec 2 sender
[ 4] 0.00-10.00 sec 2.07 GBytes 1.77 Gbits/sec receiver
Okay I understand a little more now. Receiving on helios is very slow, sending is slightly faster.
Note that rx is on.
❯ sudo ethtool -k eth1 | grep rx-checksum
rx-checksumming: on
(same with windows, IP Offloading is set to rx only)
- Quote
Link to comment
Share on other sites
- 0
-
- Share
As you can see on my iperf, actually receiving on Helios64 is fast (2.3Gb/s which is the max for the 2.5GbE)… so my guess is that the low Helios64 receiving performance you see on your side is due to your client machine Ethernet interface. Maybe the windows driver are not performing well.
- Quote
Link to comment
Share on other sites
- 0
- Author
-
- Share
I see! Yes, modifying settings on the windows machine has improved both. However, I am still seeing consistent lock-up / crashing of the interface.
Is there anything I can grab for you for details?
PS L:> iperf3.exe -c helios64.local -R -t 700
Connecting to host helios64.local, port 5201
Reverse mode, remote host helios64.local is sending
[ 4] local 192.167.0.1 port 4362 connected to 192.167.0.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 205 MBytes 1.72 Gbits/sec
[ 4] 1.00-2.00 sec 234 MBytes 1.96 Gbits/sec
[ 4] 2.00-3.00 sec 233 MBytes 1.95 Gbits/sec
[ 4] 3.00-4.00 sec 234 MBytes 1.97 Gbits/sec
[ 4] 4.00-5.00 sec 235 MBytes 1.97 Gbits/sec
[ 4] 5.00-6.00 sec 235 MBytes 1.97 Gbits/sec
[ 4] 6.00-7.00 sec 235 MBytes 1.97 Gbits/sec
[ 4] 7.00-8.00 sec 241 MBytes 2.02 Gbits/sec
[ 4] 8.00-9.00 sec 243 MBytes 2.04 Gbits/sec
[ 4] 9.00-10.00 sec 242 MBytes 2.03 Gbits/sec
[ 4] 10.00-11.00 sec 243 MBytes 2.04 Gbits/sec
[ 4] 11.00-12.00 sec 238 MBytes 2.00 Gbits/sec
[ 4] 12.00-13.00 sec 231 MBytes 1.94 Gbits/sec
[ 4] 13.00-14.00 sec 233 MBytes 1.96 Gbits/sec
[ 4] 14.00-15.00 sec 232 MBytes 1.95 Gbits/sec
[ 4] 15.00-16.00 sec 236 MBytes 1.98 Gbits/sec
[ 4] 16.00-17.00 sec 241 MBytes 2.02 Gbits/sec
[ 4] 17.00-18.00 sec 238 MBytes 2.00 Gbits/sec
[ 4] 18.00-19.00 sec 243 MBytes 2.04 Gbits/sec
[ 4] 19.00-20.00 sec 231 MBytes 1.94 Gbits/sec
[ 4] 20.00-21.00 sec 233 MBytes 1.95 Gbits/sec
[ 4] 21.00-22.00 sec 232 MBytes 1.95 Gbits/sec
[ 4] 22.00-23.00 sec 226 MBytes 1.89 Gbits/sec
[ 4] 23.00-24.00 sec 238 MBytes 2.00 Gbits/sec
[ 4] 24.00-25.00 sec 241 MBytes 2.02 Gbits/sec
[ 4] 25.00-26.00 sec 243 MBytes 2.04 Gbits/sec
[ 4] 26.00-27.00 sec 236 MBytes 1.98 Gbits/sec
[ 4] 27.00-28.00 sec 229 MBytes 1.92 Gbits/sec
[ 4] 28.00-29.00 sec 233 MBytes 1.96 Gbits/sec
[ 4] 29.00-30.00 sec 234 MBytes 1.96 Gbits/sec
[ 4] 30.00-31.00 sec 233 MBytes 1.96 Gbits/sec
[ 4] 31.00-32.00 sec 236 MBytes 1.98 Gbits/sec
[ 4] 32.00-33.00 sec 238 MBytes 2.00 Gbits/sec
[ 4] 33.00-34.00 sec 244 MBytes 2.05 Gbits/sec
[ 4] 34.00-35.01 sec 222 MBytes 1.85 Gbits/sec
[ 4] 35.01-36.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 36.00-37.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 37.00-38.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 38.00-39.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 39.01-40.01 sec 0.00 Bytes 0.00 bits/sec
...
Here’s the Helios:
Accepted connection from 192.167.0.1, port 4358 [ 5] local 192.167.0.2 port 5201 connected to 192.167.0.1 port 4362 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 207 MBytes 1.74 Gbits/sec 0 422 KBytes [ 5] 1.00-2.00 sec 234 MBytes 1.96 Gbits/sec 0 422 KBytes [ 5] 2.00-3.00 sec 232 MBytes 1.95 Gbits/sec 0 422 KBytes [ 5] 3.00-4.00 sec 235 MBytes 1.97 Gbits/sec 0 422 KBytes [ 5] 4.00-5.00 sec 235 MBytes 1.97 Gbits/sec 0 422 KBytes [ 5] 5.00-6.00 sec 234 MBytes 1.96 Gbits/sec 0 422 KBytes [ 5] 6.00-7.00 sec 235 MBytes 1.97 Gbits/sec 0 422 KBytes [ 5] 7.00-8.00 sec 240 MBytes 2.02 Gbits/sec 0 422 KBytes [ 5] 8.00-9.00 sec 243 MBytes 2.03 Gbits/sec 0 422 KBytes [ 5] 9.00-10.00 sec 243 MBytes 2.04 Gbits/sec 0 422 KBytes [ 5] 10.00-11.00 sec 243 MBytes 2.04 Gbits/sec 0 422 KBytes [ 5] 11.00-12.00 sec 238 MBytes 1.99 Gbits/sec 0 422 KBytes [ 5] 12.00-13.00 sec 233 MBytes 1.95 Gbits/sec 0 422 KBytes [ 5] 13.00-14.00 sec 232 MBytes 1.95 Gbits/sec 0 422 KBytes [ 5] 14.00-15.00 sec 233 MBytes 1.95 Gbits/sec 0 422 KBytes [ 5] 15.00-16.00 sec 236 MBytes 1.98 Gbits/sec 0 422 KBytes [ 5] 16.00-17.00 sec 240 MBytes 2.02 Gbits/sec 0 422 KBytes [ 5] 17.00-18.00 sec 239 MBytes 2.00 Gbits/sec 0 422 KBytes [ 5] 18.00-19.00 sec 243 MBytes 2.04 Gbits/sec 0 422 KBytes [ 5] 19.00-20.00 sec 231 MBytes 1.94 Gbits/sec 0 422 KBytes [ 5] 20.00-21.00 sec 233 MBytes 1.95 Gbits/sec 0 422 KBytes [ 5] 21.00-22.00 sec 232 MBytes 1.94 Gbits/sec 0 422 KBytes [ 5] 22.00-23.00 sec 226 MBytes 1.89 Gbits/sec 0 422 KBytes [ 5] 23.00-24.00 sec 239 MBytes 2.00 Gbits/sec 0 422 KBytes [ 5] 24.00-25.00 sec 240 MBytes 2.02 Gbits/sec 0 422 KBytes [ 5] 25.00-26.00 sec 243 MBytes 2.04 Gbits/sec 0 422 KBytes [ 5] 26.00-27.00 sec 237 MBytes 1.99 Gbits/sec 0 422 KBytes [ 5] 27.00-28.00 sec 230 MBytes 1.92 Gbits/sec 0 422 KBytes [ 5] 28.00-29.00 sec 233 MBytes 1.96 Gbits/sec 0 422 KBytes [ 5] 29.00-30.00 sec 234 MBytes 1.96 Gbits/sec 0 422 KBytes [ 5] 30.00-31.00 sec 233 MBytes 1.96 Gbits/sec 0 422 KBytes [ 5] 31.00-32.00 sec 235 MBytes 1.97 Gbits/sec 0 422 KBytes [ 5] 32.00-33.00 sec 238 MBytes 2.00 Gbits/sec 0 422 KBytes [ 5] 33.00-34.00 sec 244 MBytes 2.05 Gbits/sec 0 422 KBytes client_loop: send disconnect: Broken pipe ❯ ssh helios64.local ssh: connect to host helios64.local port 22: Connection refused ❯ ssh 192.168.1.236 _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ | |/ _ / __| '_ | || |_ | _ | __/ | | (_) __ (_) |__ _| |_| |_|___|_|_|___/|___/___/ |_| Welcome to Armbian 20.11 Buster with Linux 5.9.10-rockchip64 No end-user support: work in progress System load: 2% Up time: 10:02 Memory usage: 6% of 3.71G IP: 192.168.1.236 192.167.0.2 CPU temp: 48°C Usage of /: 14% of 15G [ General system configuration (beta): armbian-config ] Last login: Thu Nov 26 08:42:37 2020 from 192.167.0.1 ❯ sudo ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.236 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::31d5:231c:fc4f:efc3 prefixlen 64 scopeid 0x20<link> inet6 2001:569:7e49:4101:7221:5284:6898:f078 prefixlen 64 scopeid 0x0<global> ether 64:62:66:d0:06:18 txqueuelen 1000 (Ethernet) RX packets 47851 bytes 6758700 (6.4 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 26542 bytes 20436445 (19.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 27 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.167.0.2 netmask 255.255.0.0 broadcast 192.167.255.255 inet6 fe80::d8eb:9112:1d81:8ae7 prefixlen 64 scopeid 0x20<link> ether 64:62:66:d0:06:19 txqueuelen 1000 (Ethernet) RX packets 21137514 bytes 29374154279 (27.3 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 11354240 bytes 16174541188 (15.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 1 bytes 145 (145.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1 bytes 145 (145.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ~ ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── zageron@helios64 08:50:24 ❯
From here, if I being the adapter down and then back up it hard locks the Helios. So I generally safely sudo reboot at this point.
- Quote
Link to comment
Share on other sites
- 0
-
- Share
you do armbianmonitor -u and share the link here
- Quote
Link to comment
Share on other sites
- 0
- Author
-
- Share
- Quote
Link to comment
Share on other sites
iperf -c 192.168.3.2 -i 2
connect failed: Connection refused
3.2 is another machine. I think the port might be blocked.
How can I make this work?
asked Jun 16, 2011 at 7:28
4
You also get a «connection refused» error when you use an iperf v3 client to send to an iperf v2 server.
The message is slightly different though:
iperf3: error - unable to connect to server: Connection refused
As the iperf3 doc states, they are not compatible (at least up to version 3.1.2). You can check the version on both server and client with
iperf -v
answered Apr 4, 2016 at 10:46
J.P. TosoniJ.P. Tosoni
5154 silver badges6 bronze badges
2
I doubt that this is a firewall issue. Usually, firewalls employ the DROP rule for packets that are not allowed. A «connection refused» means that there is no application listening on the port it tries to connect to. The destination host indicates this with a corresponding ICMP message to the source.
In order to run iperf you must have a server running on the machine which you iperf to. To do this run iperf -s on the server. After that you can then run iperf -c <server IP or hostname> -i 2
After running this you will get an ouput that looks something like this:
------------------------------------------------------------
Client connecting to <server IP>, TCP port 5000
TCP window size: 256 KByte (default)
------------------------------------------------------------
[ 3] local 123.123.123.123 port 4000 connected with 123.123.123.123 port 5000
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.1 GBytes 1.09 Gbits/sec
answered Jun 16, 2011 at 8:05
DabuDabu
3591 gold badge5 silver badges23 bronze badges
Try turning off any firewall on the machines. On many linux distros, you can do
service firewall off
to disable the firewall.
answered Jun 16, 2011 at 7:30
