Jump to content
Local
][-RaY

Качество cogent

Recommended Posts

Да, да, да. Стандартное значение окна 64К. Увеличиться можеть до 1ГБ. Специально для вас перепишу её 8 бит * Default TCP Receive Window (RWIN) / пинг = пропускная способность.

 

http://technet.micro...y/cc957546.aspx

 

 

Трагедия, трагедия.... У каждой TCP сессии в зависимости от потерь размер окна будет свой, эти параметры таких обьектов ОС, как сокеты, задаются системными функциями при инициализации сокетов (функцией setsockopt) :) Ваше значение поумолчанию будет справледливо, если автоподстройка окна не включена, но в современном системной программировании - это нонсенс. Ну вот не лезли бы вы в системное программирование, а до конца бы разобрались с администрированием :) Ставь в формулу 1GB, получи зависимость при которой время отклика влияет чуть менее чем никак и канай от сюда редиска :)

Share this post


Link to post
Share on other sites

У вас сплошные потери? :) Про потери я выше писал форумулу. 8 бит умножаем на размер окна и делим на время и получаем, то что нас интересует. Но продолжим переливать из пустого в порожнее.

8 бит * TCP Receive Window / пинг = пропускная способность.

Что дальше? :)

Share this post


Link to post
Share on other sites

У вас сплошные потери? :)

8 бит * TCP Receive Window / пинг = пропускная способность.

Что дальше? :)

 

Ну чтото вы совсем плохой... Потери могут быть на любом участке сети. Я не знаю сколько вам повторить, что TCP Receive Window - это не константа, это функция от группы параметров, которая при отсутствии потерь в канале стремится к GlobalMaxTcpWindowSize=1GB у Microsoft начиная с Win2000 :) А при значении функции подстройки стремящемуся к одному гигабайту и максимальным временем отклика в сети Интернет в районе <1000 мс, последним можете пренебречь в условиях отсутствия потерь :)

Share this post


Link to post
Share on other sites

Ок. Не скорость, а максимальная пропускная способность. Также стоит учитывать процент потерь. С ним формула будет немного другая MSS/(RTT*sqrt(p)) = максимальная пропускная способность.

 

Вот она гениальнейшая формула :) Теперь подставьте в приведеднную вами формулу p=0. И ответте на вопрос, какая будет произовдительность TCP? :)

 

P.S. Не, через 2-3-4-5... на директора не тяните :)

Share this post


Link to post
Share on other sites

Вы не внимательны. Я убрал слово default перед TCP Receive Window специально для вас.

Так же я выше писал формулу где учитываються потери.

 

Вот она гениальнейшая формула :) Теперь подставьте в приведеднную вами формулу p=0. И ответте на вопрос, какая будет произовдительность TCP?

При p=0 формула не действительно.

Но мы в реальном мире живем. В реальном мире потери есть всегда. Или тоже будете спорить?

 

NEP, у меня к вам не стандартный вопрос. Как устроен тролейбус ? )

Share this post


Link to post
Share on other sites

Вы не внимательны. Я убрал слово default перед TCP Receive Window специально для вас.

Так же я выше писал формулу где учитываються потери.

 

Да написали, но вы не понимаете ее смысла. RTT ну скажем 10000000000000000000 часов, а p=0. Что в результате имеем? Ну ведь простейший вопрос :)

Share this post


Link to post
Share on other sites

При p=0 формула не действительно.

Но мы в реальном мире живем. В реальном мире потери есть всегда. Или тоже будете спорить

 

Стоп, как это не действительна, что за бред... ну вот нет у меня потерь между Майями и Гонконгом, я выкупил лямбду. p=0. Чему равна пропускная способность? :) Ну ответите или нет?

 

Хорошо, упрощаю вам задачу, p=0.0000000000000000000000000000000000000000000000000000000001. Чему равна "пропускная пособность" при RTT 1000 мс?

Share this post


Link to post
Share on other sites

А что вы подразумеваете под p? Я вероятность потерь, а вы?

Share this post


Link to post
Share on other sites

А что вы подразумеваете под p? Я вероятность потерь, а вы?

 

Аналогично. Так что там насчитали?

 

Ну ладно, не буду вас мучать, это формула записывается так:

 

W <= MSS/(RTT*sqrt(p))

 

А не стррого равно :) Т.е. эта формула дает околонаучную оценку для канала с потерями и это обязательное условие. Если вероятность потерь стремится к 0 - то эта формула нам даст очень большое значение MSS/(RTT*sqrt(p)) :), которое в Земных условиях RTT < 1с во много раз больше пропускной способности всех линий связи в Интернет вместе взятых :)

Share this post


Link to post
Share on other sites

Это само собой разумееться. Первая формула аналогично <=

От этого механизм роботы tcp не изменяеться )

Share this post


Link to post
Share on other sites

Это само собой разумееться. Первая формула аналогично <=

 

Ну вы раз 5 написали "=", что как бы намекает, что вы не разумеете, что пишите.

 

От этого механизм роботы tcp не изменяеться )

 

От чего от этого? Так зачем вы привели эти формулы?!!! И ответте все таки на извечный вопрос какова же "скорость TCP" при RTT=1с и p=0.000000000000000000000001 :)

Share this post


Link to post
Share on other sites

Проанализируем ваш первый шедевр:

 

"8 бит * TCP Receive Window / пинг = пропускная способность"

 

8*1Гбайт/1c = 8Гбит/с.

 

"Гениальная" формула :)

Share this post


Link to post
Share on other sites

Вы не указали какая пропускная способность канала по которому вы собрались гонять по TCP протоколу (с размером окна 1 Гбайт) данные. Если у вас пропускная способность канала (по которому вы собрались гонять инфу) * на задержку больше чем размер окна TCP, этим скорость передачи данных будет ограничена. Размер окна TCP должен превышать результат (пропускная способность*задержка) для достижения максимальной нагрузки канала. Я спать.

Share this post


Link to post
Share on other sites

Вы не указали какая пропускная способность канала по которому вы собрались гонять по TCP протоколу (с размером окна 1 Гбайт) данные. Если у вас пропускная способность канала (по которому вы собрались гонять инфу) * на задержку больше чем размер окна TCP, этим скорость передачи данных будет ограничена. Размер окна TCP должен превышать результат (пропускная способность*задержка) для достижения максимальной нагрузки канала. Я спать.

 

Бред.

 

Никому он ничего не должен, размер окна в современных реализациях стека TCP/IP будет меняться, и основной фактор влияющий на размер окна и только как результат на производительность стека - % потерь на участке сети до удаленного узла. Если потерь нет, то и заморачиваться размером окна нет необходимости, автоподстройка сработает так, чтобы установить его максимальным и в случае Win2000/XP - это будет 1GB в условиях достаточного размера оперативной памяти. В более современных ОС Win/Linux уже реализован The Next Generation TCP/IP stack :) Где механизмы автоподстройки окна еще более сложные :)

Share this post


Link to post
Share on other sites

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

The TCP Receive Window and TCP Throughput

To optimize TCP throughput (assuming a reasonably error-free transmission path), the sender should send enough packets to fill the logical pipe between the sender and receiver. The capacity of the logical pipe can be calculated by the following formula:

 

 

 

 

Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds

 

The capacity is known as the bandwidth-delay product (BDP). The pipe can be fat (high bandwidth) or thin (low bandwidth) or short (low RTT) or long (high RTT). Pipes that are fat and long have the highest BDP. Examples of high BDP transmission paths are those across satellites or enterprise wide area networks (WANs) that include intercontinental optical fiber links.

 

Increasing Sender-Side Performance for High-BDP Transmission

The new Receive Window Auto-Tuning feature provides enhanced performance for receiving data over high-BDP links, but what about sender performance?

The existing algorithms that prevent a sending TCP peer from overwhelming the network are known as slow start and congestion avoidance. These algorithms increase the send window (the number of segments that the sender can send) when initially sending data on the connection and when recovering from a lost segment.

Slow start increases the send window by one full TCP segment for either each acknowledgment segment received (for TCP in Windows XP and Windows Server 2003) or for each segment acknowledged (for TCP in Windows Vista and Windows Server 2008). Congestion avoidance increases the send window by one full TCP segment for each full window of data that is acknowledged.

These algorithms work well for small BDPs and smaller receive window sizes. However, when you have a TCP connection with a large receive window size and a large BDP, such as replicating data between two servers located across a high-speed WAN link with a 100ms round-trip time, these algorithms do not increase the send window fast enough to fully utilize the bandwidth of the connection.

To better utilize the bandwidth of TCP connections in these situations, the Next Generation TCP/IP stack includes Compound TCP (CTCP). CTCP more aggressively increases the send window for connections with large receive window sizes and BDPs. CTCP attempts to maximize throughput on these types of connections by monitoring delay variations and losses. In addition, CTCP ensures that its behavior does not negatively impact other TCP connections.

In testing performed internally at Microsoft, large file backup times were reduced by almost half for a 1Gbps connection with a 50ms RTT. Connections with a larger BDP can have even better performance. CTCP and Receive Window Auto-Tuning work together for increased link utilization and can result in substantial performance gains for connections with large BDPs.

CTCP is enabled by default in computers running Windows Server 2008 and disabled by default in computers running Windows Vista. You can enable CTCP with the "netsh interface tcp set global congestionprovider=ctcp" command. You can disable CTCP with the "netsh interface tcp set global congestionprovider=none" command.

The size of the Window field in the TCP header is 16 bits, allowing a TCP peer to advertise a maximum receive window size of 65,535 bytes. You can calculate the approximate throughput for a given TCP window size from the following formula:

 

 

 

 

Throughput = TCP maximum receive windowsize / RTT

 

For example, with a 65,535 byte receive window you can only achieve an approximate throughput of 5.24 megabits per second (Mbps) on a path with a 100ms RTT, regardless of the transmission path's actual bandwidth. With today's high-BDP transmission paths, the originally designed TCP window size, even at its maximum value, becomes a throughput bottleneck.

 

^^^^^^ Используеться в стеке TCP/IP в WIn Vista/Win 7

 

По прежнему будете утверждать что

Размер окна TCP должен превышать результат (пропускная способность*задержка) для достижения максимальной нагрузки канала

БРЕД?

Share this post


Link to post
Share on other sites

Размер окна TCP должен превышать результат (пропускная способность*задержка) для достижения максимальной нагрузки канала

БРЕД?

 

БРЕД - потому что вы пишите ДОЛЖЕН, да ничерта никто никому не должен. Если Майами-Франкфурт у вас потери, а Майями-Гонконг потерь нет, то выставив жестко размер окна по приведенной вами формуле вы получите на Франкфурт от мертвого барана уши. Вы бредите.

 

Не, ну точно дебил. Вы же до конца статью дочитайте!

 

Вы утверждаете [http://local.com.ua/...83#entry275583], что:

For example, with a 65,535 byte receive window you can only achieve an approximate throughput of 5.24 megabits per second (Mbps) on a path with a 100ms RTT

 

Да, я это неопровергаю, я просто привожу контр-пример. RTT 600мс Майями-Гонконг, я в одну сессию по фтп качаю 100Mbps. Этож как?!!!

 

То, что вы описали, там рассказано как было раньше и почему так делать нельзя :D А дельше идет раздел:

 

TCP Window Scaling

For larger window sizes to accommodate high-speed transmission paths, RFC 1323 (ietf.org/rfc/rfc1323.txt) defines window scaling that allows a receiver to advertise a window size larger than 65,535 bytes. A TCP Window Scale option includes a window scaling factor that, when combined with the 16-bit Window field in the TCP header, can increase the receive window size to a maximum of approximately 1GB. The Window Scale option is sent only in synchronize (SYN) segments during the connection establishment process. Both TCP peers can indicate different window scaling factors to use for their receive window sizes. By allowing a sender to send more data on a connection, TCP window scaling allows TCP nodes to better utilize some types of transmission paths with high BDPs.

 

Это что касается Win2000/XP

 

А еще дальше о The Next Generation TCP/IP

Receive Window Auto-Tuning in Windows Vista

To optimize TCP throughput, especially for transmission paths with a high BDP, the Next Generation TCP/IP stack in Windows Vista and Windows Server 2008)

 

Это что касается Vista/Win7/2008 Server/последних ядер Linux

 

P.S. Вот такие вот люди у нас занимаются связью...

Share this post


Link to post
Share on other sites

До конца я читал статью.

 

Бред.

 

Никому он ничего не должен, размер окна в современных реализациях стека TCP/IP будет меняться, и основной фактор влияющий на размер окна и только как результат на производительность стека - % потерь на участке сети до удаленного узла. Если потерь нет, то и заморачиваться размером окна нет необходимости, автоподстройка сработает так, чтобы установить его максимальным и в случае Win2000/XP - это будет 1GB в условиях достаточного размера оперативной памяти. В более современных ОС Win/Linux уже реализован The Next Generation TCP/IP stack :D Где механизмы автоподстройки окна еще более сложные :)

Выдыхайте.

 

Receive Window Auto-Tuning in Windows Vista

To optimize TCP throughput, especially for transmission paths with a high BDP, the Next Generation TCP/IP stack in Windows Vista and Windows Server 2008) supports Receive Window Auto-Tuning. This feature determines the optimal receive window size by measuring the BDP and the application retrieve rate and adapting the window size for ongoing transmission path and application conditions.

 

С BDP считаються.

 

Связью я не занимаюсь. Можете спать спокойно.

Share this post


Link to post
Share on other sites

До конца я читал статью.

 

Бред.

 

Никому он ничего не должен, размер окна в современных реализациях стека TCP/IP будет меняться, и основной фактор влияющий на размер окна и только как результат на производительность стека - % потерь на участке сети до удаленного узла. Если потерь нет, то и заморачиваться размером окна нет необходимости, автоподстройка сработает так, чтобы установить его максимальным и в случае Win2000/XP - это будет 1GB в условиях достаточного размера оперативной памяти. В более современных ОС Win/Linux уже реализован The Next Generation TCP/IP stack :D Где механизмы автоподстройки окна еще более сложные :)

Выдыхайте.

 

Receive Window Auto-Tuning in Windows Vista

To optimize TCP throughput, especially for transmission paths with a high BDP, the Next Generation TCP/IP stack in Windows Vista and Windows Server 2008) supports Receive Window Auto-Tuning. This feature determines the optimal receive window size by measuring the BDP and the application retrieve rate and adapting the window size for ongoing transmission path and application conditions.

 

Связью я не занимаюсь. Можете спать спокойно.

 

Да мне не надо это цитировать, я это знал задолго до вашего сообщения в посте #166 о 64к окне :) :)

Share this post


Link to post
Share on other sites

а что то поменялось с финансовой стороны? какая сейчас цена когента

Share this post


Link to post
Share on other sites

я бы и даром не взял когента. Мусор стабильности нету.

Share this post


Link to post
Share on other sites

Да чё там... миксануть гавнеца с нормальным трафом как делает один уважаемый донецкий магистрал и продавать по 12 - 15грн гиг и вроде как ничего. Баранам экономным сойдет, а вот уважающие свой бизнес люди вряд ли поведутся.

Share this post


Link to post
Share on other sites

Да чё там... миксануть гавнеца с нормальным трафом как делает один уважаемый донецкий магистрал и продавать по 12 - 15грн гиг и вроде как ничего. Баранам экономным сойдет, а вот уважающие свой бизнес люди вряд ли поведутся.

В киеве многие делают так же.

Продают типа комстар потом через месячишко глядишь та когент пошел.

Share this post


Link to post
Share on other sites

Продают типа комстар потом через месячишко глядишь та когент пошел.

Доступ из сети МТС в Москве в Украину в сеть ЕТТ - через Когент (стык в DECIX). Обратная трасса из ЕТТ на МТС - через глобакс (AMS-IX). Выходит, Комстар/МТС не брезгует поюзать Когент для слива исхода на Европу :) . Видать, совсем дешево...

Share this post


Link to post
Share on other sites

Продают типа комстар потом через месячишко глядишь та когент пошел.

Доступ из сети МТС в Москве в Украину в сеть ЕТТ - через Когент (стык в DECIX). Обратная трасса из ЕТТ на МТС - через глобакс (AMS-IX). Выходит, Комстар/МТС не брезгует поюзать Когент для слива исхода на Европу :) . Видать, совсем дешево...

 

Извините, но Вы написали глупость :)

 

Вопрос лишь в том что у Комстар-Украина нет паритета с ЕТТ в Киеве.

Вернее Комстар Украинский сети ЕТТ и его клиентов не анонсирует в российскую часть своей сети чтобы не грузит ьшаровым трафиком свой канал Киев-Москва.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×