Качество cogent

[Sargas 52]

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

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

Что дальше?

[NEP 217]

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

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

Что дальше?

 

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

[NEP 217]

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

 

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

 

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

[Sargas 52]

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

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

 

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

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

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

 

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

[NEP 217]

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

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

 

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

[NEP 217]

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

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

 

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

 

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

[Sargas 52]

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

[NEP 217]

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

 

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

 

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

 

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

 

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

[Sargas 52]

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

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

[NEP 217]

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

 

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

 

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

 

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

[NEP 217]

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

 

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

 

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

 

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

[Sargas 52]

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

[NEP 217]

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

 

Бред.

 

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

[Sargas 52]

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 должен превышать результат (пропускная способность*задержка) для достижения максимальной нагрузки канала

БРЕД?

[NEP 217]

Размер окна 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. Этож как?!!!

 

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

 

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. Вот такие вот люди у нас занимаются связью...

[Sargas 52]

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

 

Бред.

 

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

Выдыхайте.

 

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 считаються.

 

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

[NEP 217]

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

 

Бред.

 

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

Выдыхайте.

 

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к окне :)

[equipez 60]

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

[XRuslen 0]

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

[Sandpiper 28]

1

[interjet 177]

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

[Alex_E 852]

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

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

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

[alex_o 1 194]

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

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

[alex-netcase 13]

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

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

 

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

 

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

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

[equipez 60]

)) так сколько стоит на сегодняшний день когент????