LINUX.ORG.RU
решено ФорумAdmin

Тонкая диагностика и настройка TCP/IP-стека

 , rtt,


0

3

Всех приветствую.

Решил я тут поэкспериментировать с самодельными каналами связи. Слепил из того, что было пару драйверов к оборудованию, которые в юзерспейс торчат как файловые дескрипторы. К ним приладил приложку которая открывает tun и пересылает пакеты между моим файловым дескриптором и дескриптором tun-а. Так же проверил скорость передачи. В идеальных условиях в одну сторону 300МБ/с в другую 90МБ/с (не обращайте внимание на ассиметрию, так получилось). В общем, поднял tun-ы настроил маршрутизацию.

Пинги, как это ни удивительно, пошли. Но вот все, что сложней (ssh, tcp) ни в какую.

ping показывает RTT 70мс (да, много, тем не менее).

tcpdump показывает, что после некоторого успешного обмена начинается ретрансмишены от узла который находится за этим каналом передачи данных.

Как я понял из прочитанной теории, при таких задержках, tcp-стек считает, что он просто теряет пакеты (таймаут), и поэтому начинает повторную передачу.

Нашел совет по увеличению размера буфера (типа пропускная способность увеличится), странно ну ладно. Но не помогло.

Уважаемые админы, что где еще посмотреть для исправления этой напасти? Раньше все на диалапе сидели и все работало, а тут какие-то сраные 70мс и все упало.

★★★★★

Последнее исправление: yax123 (всего исправлений: 1)

Я, когда через звуковую карту пытался сеть наладить, запускал wireshark с обеих сторон и сравнивал что пришло и что ушло (и когда это произошло)

MagicMirror ★★★
()
Ответ на: комментарий от bigbit

пинги ходят всяких видов. и без задержки в 1 сек (отправляет сразу как пришел ответ). 65кб пакеты тоже ходят.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от MagicMirror

Вирешарк на хосте (мой комп) и тспдамп на устройстве показывают одинаковую картинку. Размеры пакетов их коли-во - все совпадает (только порядок вывода на экран разный). Просто в какой-то момент кто-то начинает повторную отправку и она идет бесконечно.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

Размеры пакетов их коли-во - все совпадает

А контрольные суммы? Если идёт повтор одинаковых пакетов, так можно их сдампить и побайтно сравнить. И начинать ковырять, что идёт в одну строну, идёт ли в обратную сторону подтверждение. Тогда будет понятно, признаёт ли принимающая сторона переданые её пакеты.

Нашел совет по увеличению размера буфера

Я бы на время отладки отключил бы и tcp window scaling и sack (если они согласуются), а с помощью iptables окно бы установил поменьше. Тогда, ИМХО, будет проще трафик анализировать. Дампить с записью в файл, потом уже эти файлы читать/сравнивать. Ну и не ssh/scp, а вобще nc, создать файл и отправлять. Файл можно с каким-то хорошо отличимым в даме содержимым содержимым.

То, что, допустим, внезапно, канал стал медленный, сработал тайм-аут и tcp-стек сделал повторную передачу, не удаляет пакеты, подтверждающие получение. Они будут отправлены, приняты, обработаны. То есть, повторные передачи могут быть, но не бесконечно одно и то же.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)

Наверное ACK не доходит до ядра почему-то. Ты в tcpdump видишь их? Я бы советовал написать простую программку на C, которая открывает TCP-соединение и пишет туда раз в секунду один байт. Это должно отправлять один простой TCP пакет раз в секунду и получать ACK на него. И если это не будет работать, то уже глазами проверь все пакеты и их содержимое. Для сравнения запусти то же на работающем сетапе, чтобы было видно, как должны выглядеть ACK пакеты.

Никаких проблем с 70мс, конечно, нет и быть не может.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)

70ms это фигня. tcp работает через спутниковые каналы где задержка значительно больше.

Смотри контрольные суммы. «tcpdump -nvei tunX» в помощь.

А ты пакеты не больше mtu посылаешь? Пришедший пакет больше чем mtu просто отбрасывается. Смотри счетчики ошибок на интерфейсе.

Размер очереди интерфейса tun тоже влияет на высоких задержках.

vel ★★★★★
()
Ответ на: комментарий от vel

мой mtu 1500. все пакеты туда влазят. через транспорт можно гонять до 4КБ пакеты. Ошибки на интерфейсах ноль.

Сейчас сравниваю, эталонный обмен с ошибочным. Выглядит так, что ошибочный обмен теряет пакеты в канале.

Похоже надо сравнивать на двух концах, где пакеты теряются.

yax123 ★★★★★
() автор топика

Всем спасибо, все свободны.

Немного повтыкав в tcpdump и обвыкнув с его манерой выдавать данные. Обнаружил что в пакетах с длиной не кратной 4 хвост в 1-3 байта зануляется. Что и приводит к указанным повторным передачам.

Ну а дальше, нашел ошибку в вычислениях границ пакетов при передачи через физику, которая и портила этот хвост.

yax123 ★★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.