Проблема в Линуксе

Mishka> А у тебя и карта и модем — оба full duplex поддерживают?
Mishka> А FTP нормально работает? [»]

Ммм.... сетвая точно. нормальная D-link карточка, проблем с такими не было. FTP на закачку работает нормально, а вот на отправление не проверяли. конторе нечего отправлять вовне кроме почты

Mishka>> А у тебя и карта и модем — оба full duplex поддерживают?
Mishka>> А FTP нормально работает? [»]
BrAB> Ммм.... сетвая точно. нормальная D-link карточка, проблем с такими не было. FTP на закачку работает нормально, а вот на отправление не проверяли. конторе нечего отправлять вовне кроме почты [»]

Попробуйте. Может быть увидите шаблон. Я бы сказал, если и FTP будет идти рывками, то проблема у провайдера. Еще хорошо бы было найти клиента внутреннего для вашего ISP и с ним договорится погонять трафик.

Mishka>>> А у тебя и карта и модем — оба full duplex поддерживают?
Mishka> Mishka>> А FTP нормально работает? [»]
BrAB>> Ммм.... сетвая точно. нормальная D-link карточка, проблем с такими не было. FTP на закачку работает нормально, а вот на отправление не проверяли. конторе нечего отправлять вовне кроме почты [»]
Mishka> Попробуйте. Может быть увидите шаблон. Я бы сказал, если и FTP будет идти рывками, то проблема у провайдера. Еще хорошо бы было найти клиента внутреннего для вашего ISP и с ним договорится погонять трафик. [»]

Хм... ну вообще-то зависание было и когда я пытался прикрепить вложение к письму на mail.ru, т. е. через веб форму.

Только при чём тут провайдер? проблема ведь не пропадает со временем, она исчезает после перезагрузки сетевого интерфейса.

BrAB> Хм... ну вообще-то зависание было и когда я пытался прикрепить вложение к письму на mail.ru, т. е. через веб форму.
BrAB> Только при чём тут провайдер? проблема ведь не пропадает со временем, она исчезает после перезагрузки сетевого интерфейса. [»]

Если зависание или пересылка рывками идет для любых протоколов и при этом на соседей такого нет — то это провайдер.

Если и на соседей ходит рывками, то надо смотреть модем и твою карточку. Но в начальном письме ты сказал, что теряется связь с инетом. Значит ли это, что с локалкой связь не теряется?


Возможен другой вариант — ты перегружаешь upload, тогда все это дело буферизуется локально и пока не переслано, все остальное идет не очень. Поэтому я спрашивал — наверх другими протоколами как?

Сделай такую вещь — начни пинговать какой-нибудь сайт. Я использую обычно яху. Не прерывая пинга, пошли мыло на 2 метра (чтобы превысить 1.4 метра). Следи за пингом — он должен начать терять пакеты. После этого, если ничего наверх не посылается, то пинг должен восстановить свое нормальное поведение минут через 5-10 десять. На самом деле, время будет разным — в зависимости от скорости upload — кстати, какой он у вас?

Напиши, если будет все как я описал.

Mishka> Если зависание или пересылка рывками идет для любых протоколов и при этом на соседей такого нет — то это провайдер.

Вот сейчас ftp пробую. вроде уходит, но не рывками. причём пробую не через NAT, а сразу с сервера.

карточку. Но в начальном письме ты сказал, что теряется связь с инетом. Mishka> Если и на соседей ходит рывками, то надо смотреть модем и твою Значит ли это, что с локалкой связь не теряется?

Да. с локалкой всё ок, даже самба прекрасно работает. причём проблема не зависит от карточки - я менять пробовал.

Mishka> Возможен другой вариант — ты перегружаешь upload, тогда все это дело буферизуется локально и пока не переслано, все остальное идет не очень. Поэтому я спрашивал — наверх другими протоколами как?

ммм... вот лил 3 метровый файл по ftp метр ущёл влёт - килобайт 70 в секунду. потом затык. потом потихоньку пошло. итоговая скорость составила 3,6 килобайта/с.
Сейчас 11 метров перекинуть по ftp пробую. метр влёт ушёл. и с тех пор ничего... опять таки - это не через NAT, это напрямую

Короче 11 я так и не залил. на метре ждать надоело.

Mishka> Сделай такую вещь — начни пинговать какой-нибудь сайт. Я использую обычно яху. Не прерывая пинга, пошли мыло на 2 метра (чтобы превысить 1.4 метра). Следи за пингом — он должен начать терять пакеты. После этого, если ничего наверх не посылается, то пинг должен восстановить свое нормальное поведение минут через 5-10 десять. На самом деле, время будет разным — в зависимости от скорости upload — кстати, какой он у вас?
Mishka> Напиши, если будет все как я описал. [»]

Почта мне недступна, я ftp мучаю. после подвисания сервер из инета пинговался с потерей 80% пакетов. минут через 5 всё восстановилось. К сожалению проверить передачу в пределах сети не получается. трафик дорогой и пока не удалось найти открытого ftp.

НО! как бы не висел инет пинг до гейта не теряет ничего! т. е. до гейта связь отличная

Mishka> Сделай такую вещь — начни пинговать какой-нибудь сайт. Я использую обычно яху. Не прерывая пинга, пошли мыло на 2 метра (чтобы превысить 1.4 метра). Следи за пингом — он должен начать терять пакеты. После этого, если ничего наверх не посылается, то пинг должен восстановить свое нормальное поведение минут через 5-10 десять. На самом деле, время будет разным — в зависимости от скорости upload — кстати, какой он у вас?
Mishka> Напиши, если будет все как я описал. [»]

Колдун однако. Я и не знал что такие водятся

Воощем всё так и есть. пока уходит быстро - пакеты пинга не теряются. как зависание - пинг теряет до 80%-99% пакетов. после отрубания - вроде отвисает.

Mishka> Нарисуйте, пожалуйста диаграмку того случая, когда с компа на комп по FTP — в смысле IP адреса и куда и как каждый воткнут. А то есть вопросы по эксперименту, а без диаграмки не понять. [»]

ох... буду надеяться я вас правилно понял.....
система такая

Сервер ASP 9.0 (проблемный) -> сетевая (ip 213.135...) модем ADSL (скрнфигурирован как мост) -> провайдер Волгателеком -> провайдер мой (Кейтелеком) -> радио-модем -> сетевая -> Сервер ASP 9.0 (не проблемный)

А вот что вы понимаете под диаграмой - я не понимаю......... может поясните как её получить? что касается условий провайдера - то постараюсь узнать - обязательно напишу.

Mishka> Это буферизация у провайдера похоже. Одно из условий — не перегружать upload, который провайдер вам (как конторе) дал. Если выходит 3.6 КБ, то это 24-32 Килобита наверх. Как модем. А вниз наверное будет около 128 Килобит?. Вообщем, ставь на Лине traffic shapping — так, чтобы с Линя уходило не быстрее провайдерского upload-а. Тогда, хоть и будет почта медленно ходить, но и в Инет можно будет лазить одновременно.
Mishka> А вообще-то, это надо с провайдером перетирать — какое там у Вас соглашение? Какие SLA (Service Level Agreement)? Может быть и провайдела пнуть надо. [»]

Ух ты.............. теперь начинает проясняться. Пойду курочить настройки модема и попробую узнать условия. Другое дело что дело это трудное в шаших диких условиях

Mishka>> Нарисуйте, пожалуйста диаграмку того случая, когда с компа на комп по FTP — в смысле IP адреса и куда и как каждый воткнут. А то есть вопросы по эксперименту, а без диаграмки не понять. [»]
BrAB> ох... буду надеяться я вас правилно понял.....
BrAB> система такая
BrAB> Сервер ASP 9.0 (проблемный) -> сетевая (ip 213.135...) модем ADSL (скрнфигурирован как мост) -> провайдер Волгателеком -> провайдер мой (Кейтелеком) -> радио-модем -> сетевая -> Сервер ASP 9.0 (не проблемный)
BrAB> А вот что вы понимаете под диаграмой - я не понимаю......... может поясните как её получить? что касается условий провайдера - то постараюсь узнать - обязательно напишу. [»]

Вообще, как человек имеющий сам домашнюю сетку на сто с небольшим квартир, могу сказать что это довольно распространенная политика: ставить на аплоад "берст моуд", когда первые н килобайт уходят со всей возможной скоростью, а затем канал резко урезается.

Связано это с тем, что на ассиметричных каналах (если где-то провайдер пользует АДСЛ, например) аплоад трафик нужно экономить, так как забивание его "под завязку" делает использование канала практически невозможным... все тормозит очень сильно из-за потерь запросов и подтверждений. С другой стороны, если канал свободен и человеку прокачать надо немного, то дать ему быстро прокинуть свои 200-300 кил будет хорошо для всех. Но если он взялся качать серьезно... приходится обрезать до договорной.
И предел в 1.4 метра - это еще очень по-божески...

Если АДСЛ вы используете единолично (ну, это линк только до вашей конторы, и контора его ни с кем не делит), то можно попросить убрать это ограничение...
Но если ассиметричный канал есть еще где-то выше и затык там, то, ИМХО, бороться бесполезно. :\ Я бы не дал. :\

Татарин> Но если ассиметричный канал есть еще где-то выше и затык там, то, ИМХО, бороться бесполезно. :\ Я бы не дал. :\ [»]

ВО! А давайте вы меня спасёте? Я далёк от того, чтоб воевать с провайдером. если честно, то меня интересует как зарезать на сервере канал вверх. чтоб всегда вверх шло допустим максимум 10 кб/с и чтоб не жужжало.

У вас в сети есть какие-то ограничения на это дело?

P. S. Огромное всем уже спасибо. Просто огромное. Вы будете смеяться, но из многих форумов мне ответили только тут. Несмотря на то, что он неспециализированный

P. S. S. Но я так и не понял - почему при перегрузке интерфейса связь поднимается мнгновенно?

Татарин>> Но если ассиметричный канал есть еще где-то выше и затык там, то, ИМХО, бороться бесполезно. :\ Я бы не дал. :\ [»]
BrAB> ВО! А давайте вы меня спасёте? Я далёк от того, чтоб воевать с провайдером. если честно, то меня интересует как зарезать на сервере канал вверх. чтоб всегда вверх шло допустим максимум 10 кб/с и чтоб не жужжало.
BrAB> У вас в сети есть какие-то ограничения на это дело?
BrAB> P. S. Огромное всем уже спасибо. Просто огромное. Вы будете смеяться, но из многих форумов мне ответили только тут. Несмотря на то, что он неспециализированный
BrAB> P. S. S. Но я так и не понял - почему при перегрузке интерфейса связь поднимается мнгновенно? [»]

Хорошая документация имеется на Linux advanced Routing & Traffic Control HOWTO, посмотри в сторону утилит ip и tc, кроме того может окажется легче ограничить через шейпер в ядре линукс: drivers/net/shaper.c, Documentation/networking/shaper.txt. Второй вариант намного статичнее первого, но иногда может пригодится

успех

BrAB>> ВО! А давайте вы меня спасёте? Я далёк от того, чтоб воевать с провайдером. если честно, то меня интересует как зарезать на сервере канал вверх. чтоб всегда вверх шло допустим максимум 10 кб/с и чтоб не жужжало.

Это надо танцевать от провайдера. Узнайте, какой у Вас по договору upload, download, какое превышение и наказание. ADSL-то он по жизни несеммитричный. Как Татарин правильно указал, какой размер корзины для burst режима. Сейчас практически все используют leakink busket для модели ограничения трафика. Вот размер этой корзины и есть предел burst-а.

BrAB>> У вас в сети есть какие-то ограничения на это дело?

Они у всех есть, только не так легко их иногда достигнуть. Раутеры теоритически построены все одинаково — и Линуксы в этом отношении не исключение. На входящем интрефейсе есть очередь — входящая, на каждом выходящем есть очереди — выходящие (случай очередей с приоритетами сейчас не рассматриваем). Задача раутера — пакеты их входящей очереди перекинуть (с возможноей переделкой) в выходящую на соответствующем интерфейсе. Грубо говоря есть несколько правил как это делается — основное — это таблица маршрутизации — в ней ищется куда перекинуть (опять-таки локальные полиси и тэги не учитываем). Далее, что происходит, если пакеты прибывают с скоростью большей, чем они могут быть отправлены? Правильно, они копятся в выходной очереди. Когда размер очереди превышает или установленное ограничение, или памяти нет, то пакеты начинают выбрасываться (опять, в зависимости от полиси — могут по разному, но в простейшем случае те, которые не помещаются). Вот похоже размер очереди у Вас - 1.4 метра.

BrAB>> P. S. S. Но я так и не понял - почему при перегрузке интерфейса связь поднимается мнгновенно? [»]

Это похоже на то, что где-то кто-то учитывает трафик с анализом (staeful analysis). Тут возможны варианты:

1. Сам модем держит очереди (если он QoS enabled) — понятно — интрефейс сбросили — модем все скинул. Пакеты из очереди не дойдут до адресата.
2. Я не удивлюсь, если это сервер обслуги ADSL — как только вы интерфейс сбрасываете, так он сразу Вашу очередь и херит. Можете проверить на другом конце — пакеты опять не дойдут.
3. Очередь связывается с некоторым ID вашего модема — пересброска интерфейса почти наверняка сбрасывает модем. Значит новая очередь. Но, думаю, в этом случае старые пакеты должны дойти до пользователя.


ceci_> Хорошая документация имеется на Linux advanced Routing & Traffic Control HOWTO, посмотри в сторону утилит ip и tc, кроме того может окажется легче ограничить через шейпер в ядре линукс: drivers/net/shaper.c,
Documentation/networking/shaper.txt. Второй вариант намного статичнее первого, но иногда может пригодится
ceci_> успех [»]

Это как раз то, что надо. Сделайте дырку поменьше и буферизация будет на вашем сервере. Модем затыкаться не будет.

Татарину
Похоже у них выход наружу через ADSL сразу, а внутренняя сетка только для себя. Т.е. траблы начинаются сразу с ADSL модема или чуть позже.

Mishka> Татарину
Mishka> Похоже у них выход наружу через ADSL сразу, а внутренняя сетка только для себя. Т.е. траблы начинаются сразу с ADSL модема или чуть позже. [»]

Да, именно так. На выходных пойду смотреть - отсюда у меня нет доступа ни к модему ни к условиям провайдера. Ещё раз всем спасибо.

P. S. Mishka, а вы не расскажете хоть чуть-чуть чем вы занимаетесь? Просто интересно как вы смогли определить проблему по моим довольно невнятным объяснениям.

easy_ok> Возможно, пробдема заключается в размере MTU.
easy_ok> Можно попробовать сделать так:
easy_ok> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
easy_ok> и
easy_ok> ifconfig eth(Наружу) mtu 1400
easy_ok> Вот значение mtu там точно меньше 1500, и желательно узнать его у провайдера. [»]

Не, тогда бы не возвращалось все назад. Да и современные TCP/IP стеки могут давно договариваться насчет максимального MTU на пути. Плюс, если MTU становиться меньше, то TCP пакет просто фрагментируется по другому. Ведь одна из целей раутеров пересобрать пакет, а потом перслать его заново — FR имеет длину пакета порядка 128 байт. Так что MTU важно до первого раутера или умного свитча (которые еще называют level 3 switch).

Хотя, чем черт не шутит — можно спросить — за спрос денег не берут.

BrAB> P. S. Mishka, а вы не расскажете хоть чуть-чуть чем вы занимаетесь? Просто интересно как вы смогли определить проблему по моим довольно невнятным объяснениям. [»]

На данный момент сетевик-девелопер.

easy_ok>> Возможно, пробдема заключается в размере MTU.
easy_ok>> Можно попробовать сделать так:
easy_ok>> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
easy_ok>> и
easy_ok>> ifconfig eth(Наружу) mtu 1400
easy_ok>> Вот значение mtu там точно меньше 1500, и желательно узнать его у провайдера. [»]
Mishka> Не, тогда бы не возвращалось все назад. Да и современные TCP/IP стеки могут давно договариваться насчет максимального MTU на пути. Плюс, если MTU становиться меньше, то TCP пакет просто фрагментируется по другому. Ведь одна из целей раутеров пересобрать пакет, а потом перслать его заново — FR имеет длину пакета порядка 128 байт. Так что MTU важно до первого раутера или умного свитча (которые еще называют level 3 switch).
Mishka> Хотя, чем черт не шутит — можно спросить — за спрос денег не берут. [»]
У ADSL и PPPOE провайдеров MTU где-то 1452. А проблема может быть как раз в определении размера MTU (PMTU discaveri)

easy_ok> У ADSL и PPPOE провайдеров MTU где-то 1452. А проблема может быть как раз в определении размера MTU (PMTU discaveri) [»]

Понимаете, здесь кое-что не ложиться в эту картинку. Ping посылает стандартные пакеты по 64 байт — ну там заговоловок еще на IP пакет, но все равно оне не выходит за пределы 128. Так что, если MTU был определен не правильно, то все большие пакеты (скажем FTP или SMTP) должны либо не проходить или проходить битыми (если стэк реализован неправильно), а пинговые — без проблем в обе стороны. Причем и delay не должно быть никакого. А здесь явно наблюдается одно из двух: а) пакеты дропаются и пинговые в том числе; б) пакеты копятся в очереди. Последний вариант можно проверить, если задать соответствующий параметр у пинга. Но я в него не верю, т.е. верю, но при посылки "нужного" количества информации мы все равно достигнем случая а). Другими словами б) это промежуточный случай — или мы попадем назад в нормальную ситуацию или же в а).