[avelosan]

st_re, про джиттер в договоре ни слова, только максимальный процент потерь оговорён. Попробуем задрать окно..

kostich, изначально был как раз auto.

[Savaoff]

2 года назад была точно такая же ситуация, которая своим существованием трахала мозг куче людей в течении более чем ГОДА.

Описание: (офис клиента в лондоне) - (сеть телиисонеры) - (предпоследняя миля в москве через нашу сеть) - (последняя миля в москве через свичи) - (офис клиента в москве).

Последняя миля в лондоне тоже была через телию.

Услуга - аренда L2 500мбит.

Симптомы: между офисом в лондоне и офисом в москве udp разгонялось кое-как до 200-400мбит. tcp - строго по 20мбит на сессию. Сессий можно было открыть дофига и таким образом получить заказанные 500мбит, но, понятное дело, обычный софт под это не приспособлен.

Клиент вынес мозг ВСЕМ, и его можно понять. iperf, duplex, медиаконверторы, патчи, etc...Телия притаскивала какой-то мега-прибор тестор ethernet frame'ов, показывающий бредовые результаты. И так в течении неск. месяцев по кругу... Лично мы (предпоследняя миля) в конце концов вместо влана через набор каталистов тупо дали на тест "черное" ОВ по москве (даже не лямбду, а именно волокно), и вопросы к нам пропали, а проблема осталась.

Выделялись linux сервера в лондоне и москве, для теста, пытались на них оттюнить tcp-стек, все напрасно.

По истечении длительного времени проблема решилась сама собой. Я думаю, что проблема была в mpls-сети Телии, но она не признается. Просто все остальное было перепробовано 1000 раз в разных точках разными ноутами/патчами/конверторами/etc.

Изменено 4 августа, 2011 пользователем Savaoff

[rus-p]

Автор, что с большим окном получилось ?

Не терпится узнать подробности.

[avelosan]

Пока ничего нового, сейчас у меня сидит специалист провайдера - тестируют канал, чешут репу. Рабочая версия - несогласованность настроек оборудования. Вопрос только где именно.

[avelosan]

Savaoff, вот как-то так, да)) Только у меня 260-320 кбит/с на сессию по последним данным.

[Savaoff]

Savaoff, вот как-то так, да)) Только у меня 260-320 кбит/с на сессию по последним данным.

 

ну, в описаной мной выше ситуации на самом деле все было еще сложнее. А именно, в датацентре телии в москве стоял сервер клиента, включенный в тот L2 между офисами в лондоне и москве. Предпоследняя миля в москве включалась в тот же свич телии в датацентре, куда и сервер клиента (разумеется, L2 между офисами никак не зависел от сервера в датацентре телии).Так вот скорость (лондонский офис) - (сервер в московском датацентре телии) была нормальная. Скорость (сервер в московском датацентре телии) - (офис в москве) - тоже нормальная. Между офисами в лондоне и москве - описаная ранее проблема. Порты в телийском свиче, разумеется, тоже меняли. Ужастики,короче.

Изменено 5 августа, 2011 пользователем Savaoff

[Borya]

Лучше тогда уж openvpn over udp

[netime]

Если большие задержки по пинг(ICMP) то какая связь с TCP окном?

Ну станет большие сегменты TCP посылать и уменшит число подверждений и что? это не увеличит скороть передачи TCP в данном случае.

 

Размер пакета при пинге был стандартным?

[nuclearcat]

На Линуксе в поиске помогает

ping -c1000 -i0.000001 -s1472 dstip

[st_re]

netime

прямая

при размере окна = 1 пакету мы получим время передачи пакета = 600 мс (пакет доезжает туда и подтверждение возвращается), 2 пакета 1200 мс (пакет доезжает туда, подтверждение возвращается и только потом пошел второй пакет итд), 3 пакета 1800 мс.

пр размере окна = 2 пакетам, мы получим скорость передачи 2 пакета за 600 мс (+ чуть чуть на генерацию второго пакета). на 1800 мс мы почти успеем полностью передать 6 пакетов.

при размере окна равного, количеству пакетов, которые мы успеем нагенерить за 900 мс и более, мы будем передавать не останавливаясь.... т.е. в окно долен влезать трафик больше чем 130 килобайт... (не, не обсчитался ?) при бОльшем окне уже ничего не поменяется, мало того может стать снова хуже. большие окна имеют свои проблемы, особенно при наличии потерь

 

Возможноть принять Большее окно должны быть правльно понята обоими сторонами.

[st_re]

http://www.faqs.org/rfcs/rfc2488.html

 

4.2 Large TCP Windows

  The standard maximum TCP window size (65,535 bytes) is not adequate
  to allow a single TCP connection to utilize the entire bandwidth
  available on some satellite channels.  TCP throughput is limited by
  the following formula [Pos81]:

                     throughput = window size / RTT

  Therefore, using the maximum window size of 65,535 bytes and a
  geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum
  throughput is limited to:

        throughput = 65,535 bytes / 560 ms = 117,027 bytes/second

 

в данном сдучае у нас не спутник, но это не важно, у нас спутниковая задержка.