NEP

Ну так произведите на нас впечатление фотографиями своих линий. На фото которые я выложил в основном действительно один оператор. Это Verizon. Есть второй мощный игрок - это Comcast ну и еще держатель кабельной канализации AT&T, кое где он тоже есть на фото. Что делать двум операторам в чс я честно говоря не понимаю, это идиотизм высшего пошива. В США культура конкуренции несколько выше, зачем палить деньги, чтобы дважды покрыть один и тот же район Этого в США нет. Весь рынок разделен. Скажем четные номера улицы подключены к Comcast, а нечетные к Verizon и в этой концепции ни та ни другая сторона не наровит нарушать договоренности ибо это приведет только к растратам. А у нас в лучшем случае получается как, улица, заходит два оператора покрывают 100% домов, а абонбазу делят 50%/50% ну каков в этом смысл, если можно покрыть 50% домов и при этом поиметь 100% абонентов с них. А в худшем так: заходят 5 операторов покрывают 100% домов, а абонбазы получают по 20%. В результате срок окупаеомсти таких прожектов свыше 20 лет

Выдыхайте. Связью я не занимаюсь. Можете спать спокойно. Да мне не надо это цитировать, я это знал задолго до вашего сообщения в посте #166 о 64к окне :)

БРЕД - потому что вы пишите ДОЛЖЕН, да ничерта никто никому не должен. Если Майами-Франкфурт у вас потери, а Майями-Гонконг потерь нет, то выставив жестко размер окна по приведенной вами формуле вы получите на Франкфурт от мертвого барана уши. Вы бредите. Не, ну точно дебил. Вы же до конца статью дочитайте! Вы утверждаете [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. Вот такие вот люди у нас занимаются связью...

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

Проанализируем ваш первый шедевр: "8 бит * TCP Receive Window / пинг = пропускная способность" 8*1Гбайт/1c = 8Гбит/с. "Гениальная" формула

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

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

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

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

Вот она гениальнейшая формула Теперь подставьте в приведеднную вами формулу p=0. И ответте на вопрос, какая будет произовдительность TCP? P.S. Не, через 2-3-4-5... на директора не тяните

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

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

Да не нравится, что формула ваша - бред. Размер TCP окна - это не константа Это функция Вы отстали прогресса лет на 20 Это всеравно что цитировать Ньютоновские законы в эпоху квантовой механики, нет, ну конечно в условиях константности окна ваша формула работает, но окно не константа уже лет как 20!! А если быть точнее это май 1992 года

Я в шоке Ну это да... это конечно да.... Это то, о чем я говорю. У сессии не может быть пропускной способности по определению Это всеравно что говорить о скорости наклейки спарко на лобовом стекле шестерки Слава, вот ты мне расскажи, как это я из Гонконга в одну сессию скачиваю данные в Майами (время отклика 300мс) по фтп с пропускной способностью 11Мбайт/с, а из аналогичного серера из Орландо (время отклика 10 мс) тоже 11Мбайт/с? Это ж что за такая зависимость? Ну распиши на листике себе этот процесс. Размер окна будет хоть както косвенно влиять на производительность TCP, если у тебя на линии будут потери, и это окно большого размера. А так искусственно заниженные окна малого размера - это уже нонсенс Но потери на канале это уже не штатная ситуация и только тут срабатывает механизм автоподстройки размера окна в сторону искусственного уменьшения его размера. Т.е. говорить о пропускной способности TCP и тем более о ее зависимости от времени отклика не совсем корректно. Можно говорить о снижении производительности TCP в зависимости от потерь на канале, это да, но никак не от времени отклика, которое всегда может быть компенсировано размером окна причем физический смысл времени отклика при этом будет - фаза Зависимость "пропускной способности TCP" от времени отклика придумали хитро сделанные админы "дропнетов", не повторяй их ошибки И гарантируй пропускную способность канала связи и если пожелаешь производительность TCP только внутри своей сети.

Так а что вы смеетесь на убогими, мне и так не раз пытались доказать, что пропускная способность зависит от времени отклика Причем люди обслуживающие сети 5к+ абонентов. А после вашей формулы так вообще ссылаться начнут

Дебилы. 465 000 000 грн ~ 15 000 км ВОЛС Это до каждого хутора достроить можно от ближайшей НРП Атраком. А на 4-е млрд. LTE, так вообще в каждый частный дом, в каждом хуторе можно подать волокно.

Т.е. в итоге какая должна быть конфигурация бандла для терминирования до 32к вланов QinQ? Sup720 ES20+ Chassis Правильно? Да. Но если бы сеть строил грамотный инженер на оборудовании CISCO фанатично не экономящий капекс, то получилась бы эволюция: до 1к SUP2/SUP32 до 4 к +линейные карты +SUP720 до 16к +линейные карты +ES карта.

Собственно про vlan-per-user речь и идет, потому и вопросы по числу поддерживаемых влан. У ES карт в описании нашел цифру 16к vlan per card, никаких 32-96 и в помине нет. http://www.cisco.com...ecd805ddce3.pdf искать это: 32K VLAN IDs per line card for rich services at scale карты ES+. http://www.ebay.com/itm/Cisco-76-ES-XC-20G3C-10GigE-SFP-XENPAK-Line-Card-/180669049886?pt=COMP_EN_Networking_Components&hash=item2a10b6ec1e Это даже меньше, чем вы посчитали на наге.

Сначала надо понять, как это предлагают делать инженеры из Alcatel, CISCO... которые работают с крупнейшими телекомами и которые являются специалистами на порядки более высокого уровня чем тут околачивающиеся, включая меня. Но в отличии от других, я не считаю этих инженеров идиотами, я стараюсь понять, почему это предлагается именно так, какие они решали проблемы и как это реализовано на программном и аппаратном уровне. И только поняв это, можно уже выбирать оптимальное решение подходящее в том числе и по стоимости. Я сразу выше сказал, что не сторонник схем с unnumbered и оpt82. Одно является проприетарщиной, второе костылем. Хотя сам unnumbered кое-где использую на 3550. Опять же стоит обращать внимание на схемы выбранные другими участниками рынка, скажем КС, Триолан и т.д. Где тупо /24 на N коммутаторов, агрегация на район и вперед на мины. Никакого дилетантского опт82 или аннамберед. Второй альтернативой является схема vlan-per-user, но в этом случае возникают проблемы ограниченного количества вланов, неудобства конфигурирования коммутаторов доступа и терминации вланов, наиболее масштабируемые схемы в рамках этой парадигмы доступа конечно же реализуются при терминации qinq на BRAS CISCO/Alcatel/.... Linux.

96к клинетов может, а почему нет? 4000 vlan, в схеме vlan на коммутатор а в рамках коммутаторе port-isolation = 96к в случае 24-х портового доступа. Про 96к вланов я не говорил. Я просто когда вы назвали цифру 16, спросил от куда данные, почему не 96, потому что точно знал про 32к.

Так это аукцион Ищите buy now

Посвежее ниче не нашли? http://www.cisco.com...ecd805ddce3.pdf Designed for Carrier Ethernet, IP/MPLS PE Edge in mid-size and smaller Service Provider and Enterprise WAN applications, the Cisco 7600 Series Ethernet Services 20G (7600-ES20) supports up to 20 Gbps of bandwidth with 20 ports of Gigabit or 2 ports of 10G Ethernet interface models. The cards feature hierarchical QoS, locally significant VLANs, and up to 32K VLAN IDs per line card for rich services at scale. Странный подсчет, ну да ладно. Почему наг? Давайте по GPL считать. Ну так и С3550 по цене нага считайте $750. А также учтите, что к пачке 3550 вам понадобится еще как минимум пара С3750, которые и близко не догонет по производительности SUP720. Где масштабируемость? Пришло к нам еще 32к... да у вас уже стойка железок, ставим еще одну? В моем случае я поставлю только еще одну линейную карту на следующие 32к! Считайте заново Вы допускаете одну очень распространенную ошибку, которую допускают лиди занимающиеся связью, но сами по себе к связи не имеющие никакого отношения. Вы с фанатизмом минимизируете капекс, в отрасли связи - это недопустимо, тут минимизируется опекс и именно за счет увеличения капекса. Ну как бы вам это обьяснить... то что вы предлагает - это гирлянда свитчей по меди в ч/с, то что предлагает CISCO - это как волокно в каждый дом Но то, что невыгодно строить сети доступа на сопливой меди в ч/с вас уже жизнь я смотрю научила, а применять промышленные решения пока нет, ну чтоже, у вас еще все впереди и вам еще и тут предстоит вытереть под носом на рубеже 10к, если конечно доростете. Вы не понимаете одного, вы минимизируете капекс и я не понимаю зачем, это же капекс - это как банк положил, у этой циски высокая остаточная стоимость. Окупается она за 3! дня Вместо этого вы минимизируете капекс и увеличиваете опекс, т.е. тратите время, чтобы приставить горбатого к стенке. Это как те евреи, вчера державшие харчевню, а теперь занявшиеся связью в месяц платящие по $10к за аплинки в месяц! и жмущиеся купить себе единоразово лет на 5... С6500 с SUP720-3bxl или MX80 за $15-20к вместо этого страдают всякой ересью. Это простите не связь, ваши сексуальные фантазии с С3550 на рынке с жесткой конкуренцией увы никто оплачивать не будет.

Не 15, а 10. От куда цифра 16к? Почему не 96к? будет. Относительно резервирования, так у знакомых в 6-ти городах по две штуки 7600 + SUP720-3cxl стоит 30к+ абонентов. Для людей это не деньги даже по GPL-50% Схема у них правда без q-in-q, но все же...

Итого: $1300 SUP720-3b $7000 ES20 $1700 на все про все. Да, за 10к вы получаете профессиональное, непроблемное и масштабируемое решение. Есть посчитать брендовый сервер под аналогичную задачу на 2х10Г, то получится что то около $5000. http://www.cisco.com...c78-643759.html C6500 Central-forwarding-engine compatibility • The line cards are compatible with the Cisco Catalyst 6500 Series Supervisor Engine 720-3B

Где я писал что SUP720 это реализует? Почему ES вы считаете по GPL, а C3550 по ленд-лизу? http://www.ebay.com/...=item2eaf25fc70 http://www.ebay.com/itm/Cisco-7600-ES20-10G3C-/200642266532?pt=COMP_EN_Networking_Components&hash=item2eb73605a4 Я же написал, что есть масса вендоров, которые это реулизуют более бюджетно. А на 20G это вообще на Linux реализуемо.