Позначка: сисадмінство

Опубліковано Опубліковано в Записки 2 коментарі Tagged with , , ,

Налаштований мною роутер (усе серйозно — VLAN’и, шейпінг etc) на Лінуксі періодично валив мережу через скидання мережевої карти. Типу, зависала вона.

Aug 8 11:38:25 atlantis kernel: [240509.881537] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
Aug 8 11:38:25 atlantis kernel: [240509.881537] TDH <c3>
Aug 8 11:38:25 atlantis kernel: [240509.881537] TDT <d0>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_use <d0>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_clean <c1>
Aug 8 11:38:25 atlantis kernel: [240509.881537] buffer_info[next_to_clean]:
Aug 8 11:38:25 atlantis kernel: [240509.881537] time_stamp <10396ec44>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_watch <c3>
Aug 8 11:38:25 atlantis kernel: [240509.881537] jiffies <10396eed3>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_watch.status <0>
Aug 8 11:38:25 atlantis kernel: [240509.881537] MAC Status <40080083>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PHY Status <796d>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PHY 1000BASE-T Status <7800>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PHY Extended Status <3000>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PCI Status <10>

Драйвер — e1000e. Так от, якщо таке трапляється, то лікується воно (принаймні, на ядрах 3.8) отак:

ethtool -K eth0 tso off

По-хорошому, треба б надіслати багрепорт, але рішення я ж нагуглив з уже надісланого багрепорта, а чого це не виправили — не знаю.

Опубліковано Опубліковано в Записки Немає коментарів Tagged with , ,

Довелося тут підняти критичний до затримок тунель, через який працюватиме купа народу з термінальним сервером. Виявилося, що затримка пакетів у такому тунелі гуляє, як остання дівка, причому, значення дуже сильно відрізняються від пінгів зовнішньої білої адреси. Іноді різниця доходить до 5 разів у гірший бік. Піки спостерігаються, коли хтось працює, а якщо канал не завантажено, то значення перебувають у межах норми. Моніторинг завантаженості каналу показав… 2%. Щось тут не так.

Рішення знайшлося через гугл. У конфіг сервака потрібно додати опцію tcp-nodelay, яка каже, що пакети будуть відправлятися негайно, а не з певною затримкою для агрегації. Після цього пінг нормалізувався. Причому, він став меншим за пінг до білої адреси О_о. Мабуть, це приколи мережевого стека Лінукса й Xen’а, оскільки термінальний сервер сидить за гентушним NAT’ом.

Компресію я також про всяк випадок вимкнув. Кажуть, також впливає на пінг.