NEP
Сitizens-
Content Count
2,843 -
Joined
-
Last visited
-
Days Won
22
Content Type
Profiles
Forums
Calendar
Everything posted by NEP
-
Ну так произведите на нас впечатление фотографиями своих линий. На фото которые я выложил в основном действительно один оператор. Это Verizon. Есть второй мощный игрок - это Comcast ну и еще держатель кабельной канализации AT&T, кое где он тоже есть на фото. Что делать двум операторам в чс я честно говоря не понимаю, это идиотизм высшего пошива. В США культура конкуренции несколько выше, зачем палить деньги, чтобы дважды покрыть один и тот же район Этого в США нет. Весь рынок разделен. Скажем четные номера улицы подключены к Comcast, а нечетные к Verizon и в этой концепции ни та ни другая
-
Выдыхайте. Связью я не занимаюсь. Можете спать спокойно. Да мне не надо это цитировать, я это знал задолго до вашего сообщения в посте #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 6
-
Бред. Никому он ничего не должен, размер окна в современных реализациях стека 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, ес
-
Так а что вы смеетесь на убогими, мне и так не раз пытались доказать, что пропускная способность зависит от времени отклика Причем люди обслуживающие сети 5к+ абонентов. А после вашей формулы так вообще ссылаться начнут
-
В Украине создается новый государственный оператор связи
NEP replied to kvirtu's topic in Flame about networks
Дебилы. 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. Одно яв
-
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.
-
Не 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 реализуемо.
