Исходное сообщение
"Исследователи нашли фундаментальную уязвимость во всех TCP/I..." Отправлено Dyr, 06-Окт-08 14:25
>>[оверквотинг удален] >За информацию спасибо, не нужно все вопрринимать агресивно, вас же никто не >обидел или оскорбил. Где ж я агрессивно воспринял? На пустое "не верю" я ответил вполне конкретными цифрами, мы с вами так и вообще вроде вполне нормально общаемся. >этот "тюнинг" (к стати я не понимаю почему этим словом называют), по >факту оптимизирует только TCP, но не убирает прерывания сетевых интерфейсов с >CPU Не убирает, да. Но вот в чём дело - сокращение передачи обработки прерываний с процессора путём увеличения очереди пакетов неизбежно ведёт к увеличению временнЫх задержек на интерфейсе, пусть и путём уменьшения загрузки на CPU. Смысла в этом я не вижу - сетевуха гигабит с текущей загрузкой проца нормально пропускает. > >единственное, что немного может улучшить так это увелечение входящей очереди интерфейса, увеличение таблицы arp, Неактуально - до этого шлюза маршрутизируется (и шейпится) на Cisco 6504, так что у него всего две arp-записи. >я не совсем понимаю зачем оптимизировать tcp на по сути L3 устройстве, если до заголовка транспортного ровня он вовсе не доходит. "Смысл ваших слов от меня ускользает" =) Какую именно ненужную оптимизацию tcp транспортного уровня вы видите?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>>[оверквотинг удален] >>За информацию спасибо, не нужно все вопрринимать агресивно, вас же никто не >>обидел или оскорбил. > Где ж я агрессивно воспринял? На пустое "не верю" я ответил вполне > конкретными цифрами, мы с вами так и вообще вроде вполне нормально > общаемся. >>этот "тюнинг" (к стати я не понимаю почему этим словом называют), по >>факту оптимизирует только TCP, но не убирает прерывания сетевых интерфейсов с >>CPU > Не убирает, да. > Но вот в чём дело - сокращение передачи обработки прерываний с процессора > путём увеличения очереди пакетов неизбежно ведёт к увеличению временнЫх задержек на > интерфейсе, пусть и путём уменьшения загрузки на CPU. Смысла в этом > я не вижу - сетевуха гигабит с текущей загрузкой проца нормально > пропускает. >> >>единственное, что немного может улучшить так это увелечение входящей очереди интерфейса, увеличение таблицы arp, > Неактуально - до этого шлюза маршрутизируется (и шейпится) на Cisco 6504, так > что у него всего две arp-записи. >>я не совсем понимаю зачем оптимизировать tcp на по сути L3 устройстве, если до заголовка транспортного ровня он вовсе не доходит. > "Смысл ваших слов от меня ускользает" =) Какую именно ненужную оптимизацию tcp > транспортного уровня вы видите?
	Введите код, изображенный на картинке: