From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <igo@aeroflot-don.ru>
Message-ID: <3FD9B38F.5010408@aeroflot-don.ru>
Date: Fri, 12 Dec 2003 15:24:47 +0300
From: Igor <igo@aeroflot-don.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU;
	rv:1.3) Gecko/20030309
X-Accept-Language: ru-ru, ru
MIME-Version: 1.0
To: community@altlinux.ru
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [Comm] ip link show & =?koi8-r?b?0M/OydbFINPLz9LP09TYPw==?=
X-BeenThere: community@altlinux.ru
X-Mailman-Version: 2.1.3
Precedence: list
Reply-To: community@altlinux.ru
List-Id: <community.altlinux.ru>
List-Unsubscribe: <listinfo/community>,
	<mailto:community-request@altlinux.ru?subject=unsubscribe>
List-Archive: </pipermail/community>
List-Post: <mailto:community@altlinux.ru>
List-Help: <mailto:community-request@altlinux.ru?subject=help>
List-Subscribe: <listinfo/community>,
	<mailto:community-request@altlinux.ru?subject=subscribe>
X-List-Received-Date: Fri, 12 Dec 2003 12:24:48 -0000
Archived-At: <http://lore.altlinux.org/community/3FD9B38F.5010408@aeroflot-don.ru/>
List-Archive: <http://lore.altlinux.org/community/>
List-Post: <mailto:mandrake-russian@linuxteam.iplabs.ru>

Есть
[root@xxx root]# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 
100 *из ADSL модема*
    link/ether 00:10:48:5e:0a:2a brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:01:02:16:82:43 brd ff:ff:ff:ff:ff:ff
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 
3 *ADSL подключение*
    link/ppp

Вопрос
Почему mtu разные у eth0 и ppp0?
Что будет если eth0 по максимуму отправит  (т.е. пекет в 1500)  на ppp0?
Полез в эти дебри  по проблеме описанной ниже(с ответом из fido).

ПЕ> Есть довольно загадочная проблема. Обычное ADSL-подключение (параметры
ПЕ> ниже, чего не хватает - скажите), но если один процесс начинает
ПЕ> использовать подключение, то делает это на полную катушку, не оставляя
ПЕ> другим ничего. Например, отправляет MTA наружу почту - и time в пинге
ПЕ> увеличивается как минимум в 100 раз, а большая часть пингов просто
ПЕ> теряются, HTTP-запросы не проходят и т.д.
  Проблема стандартная: eth0 льет в модем больше, чем тот успевает передать.
  Искать "решение" по ключевым словам tc, tbf, cbq, htb, egress, bandwidth,
  lartc.org. :) С одним каналом - только шейпить и снижать mtu до

Скорее всего это правильный ответ т.к. если кто-то что-то качает то со 
связью вроде все нормально.
Может можно проще решить проблему чем tc, tbf, cbq, htb, egress, 
bandwidth а просто указать скорость сетевой карте например не 10Мб а 
1Мб. Вот только как ?