evd Опубликовано 18 мая, 2009 · Жалоба Клавдий, Вы рядом график счетчика дропов приложите Надо полагать, что если КМ обрежет полосу на гигабитном порту до 800 метров, то дропы канут в лету, и будет скупому клиенту щазсчастье? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Клава Маус Опубликовано 18 мая, 2009 · Жалоба Визирь, у меня дропы не на сети, а непосредственно на порту к клиенту. На том порту, который он заказал и полностью без лукавства его утилизует. И клиент это осознает и непосредственно видит. И это картинка не с жесткой полкой, кои я видАл на ДВ, в Сибири и у домушников, когда они только начинали предлагать анлимы. А вот, если 1GE порт не может отдать чистых 0,94GE без оверхедов, то дропы уже внутри вашей сети. У вас узлы или каналы между ними болеют. Вот тут и просите вам показать дропы, нагрузки процев, ошибки и т.п., чтобы причину найти и лечение придумать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j_box Опубликовано 18 мая, 2009 (изменено) · Жалоба МрБир, Клава Маусович! Нет никакого преднамеренного резервирования полосы у магистралов. Если у ТТК точно такие же "симптомы" как и у РТ, то дело ИМХО в следующем: РТ строил свою ПД сеть на существующем "телефонном" синхронном транспорте. То есть не было смысла поднимать лишние лябды там, где хватало для старта уже построенной полосы. Синхронный транспорт - это СТМы. Вся схема предоставления услуг ПД выглядит так: бордер - маршрутизатор - интерфесная плата SDH мукса - плата кросс-коммутации SDH мукса - транспортная интерфейсная плата SDH мукса - траспондер DWDM - цветной сигнал в магистраль. То есть работает схема Ethernet over SDH over DWDM. Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит... Думаю это не так. Какой разработчик будет делать платы заявленный функционал которых не будет соответсвовать действительности? Я бы ни за что не рискнул двигать такую свою продукцию на профессиональном рынке. Это пи@@@ц деловой репутации фирмы ни за грош. Знаю есть такие прецеденты в бытовухе (например с мобилами). Модели один в один по техническому исполнению. Одна стоит 100 баксов, другая 300 баксов. Разница только лишь в прошивке чипа, позволяющего реализовать потенциал модели на 100%. Ну да ладно. Я отвлекся. Может быть жадных так наказывают и на профессиональном уровне. Сэкономил 100 баксов из тысячи, получил производительность в 4-е раза меньшую. Я о другом. Схема Ethernet over SDH - имеет свои особенности. ( Тут небольшой экскурс в технологию ) SDH - синхронная технология. То есть нигде, никогда нет очередей на входных и выходных буферах. SDH предназначен для передачи телефонного сигнала т.е. каждую секунду 8000 раз АЦП считывает сигнал с микрофона телефонной трубки и оцифровывает его 8 битами. Данный байт - немедленно уходит абоненту на другом конце провода. Получаем 8 х 8000 = 64к - стандартный оконечный цифровой телефонный канал или ОЦК. Один ОЦК - и есть один тайм-слот в потоке Е1. Тайм-слотов в Е1 - 30 штук ( полезная нагрузка 30 + 2 служебных). Итого 2048 кБ/с = Е1 То есть, оборудование работающее с Е1 передает 8000 раз в секунду пакет (виртуальный контейнер VC12) размерами 8 * 32 = 256 бит. Заметно, что 16кбит информации - служебные ( не доступны пользователю для передачи полезной информации ). Значит реальная пропускная способность Е1 ( для пользователя) = 30 * 8000 = 1920кб/с. Дальше больше. Е1 пакуются в STM-1 по 63 штуки (больше не помещается. Сделано так для совместимости со стандартами США где 30 разговорных каналов помещаются в 1,5 Мб/с) Итого 63 * 2048 = 129 мб/с = реальная пропускная способность STM-1 но есть ньюансы... Это верно если грузить СТМ двушками. Если грузить плезеохронным сигналом ( не разбивая на Е1) можно закачать 140 Мб/с. К полезной нагрузке добавляется заголовок (регенераторной секции, мультиплексорной секции + указатель) и получается транспортный модуль 155 мб/с. Это и есть СТМ-1. или витруальный контейнер 4-го уровня (VC4). Реальная пропускная способность его (полезная нагрузка) 129 мб/с. Дальше еще больше. Мультиплексоры SDH могут выполнять роль L2 коммутаторов. то есть есть платы с 1GE портами для данных мультиплексоров, но в магистраль передаются не 1GE, а адаптированные под SDH технологии Е1 х 500 или VC4 x 7. В первом случае реальная пропускная способность 960 мб/с во втором 129 * 7 = 903 мб/с. или 140 * 7 = 980 мб/с Вся остальная полоса 2съедается заголовками СТМ - кадра... В каждом конкретном случае нужно смотреть как сконфигурирует мультиплексор админ, такой и будет реальная полоса. Если же в качестве трнспорта (хребта магистрали) использовать Ethernet ( 10GE over DWDM). то ничего подобного не происходит. Все пакеты уходят как им положено не подстраиваясь под SDH технологии и не теряя полосу на заголовки SDH, что убедительно доказал Клава Маусович MRTG графиком. Резюме. SDH предназначен для синхронной передачи информации. В нем неизбежно будут Ethernet пакеты паковаться еще и в виртуальные контейнеры SDH. и реальная полоса не соответствует привычной провайдерам. SDH идеально подходит для передачи голоса ( 8000 контейнеров в секунду... всегда будь то Е1, Е3 или СТМ-х. SDH резервируется по схеме 1+1 при кольцевом резервировании и в состоянии дать связь с гарантированным качеством ( скорость переключения на резерв 50мс). Именно поэтому L2VPN поднятые на транспорте так приглянулись провайдерам доступа, но по сути провайдеры получают гораздо более дорогую услугу, чем IP-транзит. Они пполучают гарантированный тоннель, не зависящий от загруженности маршрутизаторов. Такой L2VPN на скорости 1GE равен по цене VC4 x 7 SDH или 500 х Е1 на данном маршруте. ЗЫ: Я пару раз упоминал на форуме про "экстратрафик". Это тот трафик, который используется для резервирования проданных синхронных каналов (Е1, СТМ-х и пр.). По сути они 99,999% времени не задействованы. Технически сконфигурировать Ethernet, используемый для бекапа (продажа не полосы на погиговке) с плат мультиплексоров на по трассам Экстратрафика (верхняя часть диапазона) позволит сэкономить до 5 гиг/с на на КАЖДОЙ магистрали, где Ethernet шурует поверх SDH. Это удвоение мощности существующей сети без аппаратного апгрейда!!! Я пробовал это решение (чисто в познавательных целях) когда-то в учебном классе!!! Это работает. Е1 - резервируются как и прежде. Интернет провайдеры получают полосу, используемую под резервирование SDH трафика в момент "Ч" на своих магистралях, но только при условии. что все "дорогие" связи SDН функционируют в штатном режиме... ЗЫЫ: Черт возьми!!!! Почему мне нужно служить интерфейсом между синхронными технологиями и технологиями ПД? И те и другие мне кажется не как не поймут на каком же языке разговаривает их сосед... Вроде все слова по русски, но суть... разница от обеих сторон ускользает... :((( Сейчас словоблудие было для обеих сторон. Вот пакет (ПД) - который передается асинхронно. Вот СТМ-кадр который передается 8000 раз в секунду и сколько в него успел загрузить данных юзер - его проблемы. Давайте разбираться господа. Тестить. И не бросаться словами как господин Дятел или еще кто по поводу "фу... отстой...". :((( С уважением.... Изменено 18 мая, 2009 пользователем j_box Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 18 мая, 2009 · Жалоба многа букаф. перечитаю позже :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
СУХОВ Опубликовано 18 мая, 2009 (изменено) · Жалоба Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит...Думаю это не так. Какой разработчик будет делать платы заявленный функционал которых не будет соответсвовать действительности? Cisco.., HP.., Foundry.., на моей памяти были подобные дефолты , где количество портов скажем пропускной способностью каждый в 1 гигабит, в совакупе не позволяли дать нагрузку ,пропорционально количеству портов на модуле . В общем , если установлен подобный модуль с 4-мя гигабитными портами - далеко не факт , что общий трафик через него будет бегать в районе 4-х гигабит , причем причин может быть куча , начиная от этого злополучного модуля и заканчивая всевозможными процессорами , системными шинами и т.п. Изменено 18 мая, 2009 пользователем СУХОВ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wawa Опубликовано 18 мая, 2009 (изменено) · Жалоба Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит...Думаю это не так. Какой разработчик будет делать платы заявленный функционал которых не будет соответсвовать действительности? Я бы ни за что не рискнул двигать такую свою продукцию на профессиональном рынке. Это пи@@@ц деловой репутации фирмы ни за грош. может он про это говорил про оверсабскрайб 4 к 1 ? вот Вам, пожалуйста, пример: Cisco WS-X4424-GB-RJ45 - все порты сгруппированы по четыре и если есть превышение - оно летит в корзинку Cat 450x вполне себе профессиональный прибор, не самый свежий правда. Но оверсабскрайб такого типа живее всех живых. Изменено 18 мая, 2009 пользователем wawa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 18 мая, 2009 (изменено) · Жалоба Нет никакого преднамеренного резервирования полосы у магистраловА если вдруг где-то и обнаружилась свободная полоса, то это чистая случайность ;) Схема Ethernet over SDH - имеет свои особенностиIP over SDH уже не модно? Всякие там PPP, HDLC и иже с нимиИли Вы про 10G wan-phy? Ну да, там есть свои особенности. Абсолютно прозрачные для тех, кто эту технологию использует SDH - синхронная технология. То есть нигде, никогда нет очередей на входных и выходных буферахEthernet-фреймы/ip-пакеты прилетают строго по расписанию? ;)Вообще же, Джей, ваша правда: sdh-мультиплексор и ethernet-свич таки работают по-разному. Один вопрос остался: какое это имеет отношение к резервированию полосы? Изменено 18 мая, 2009 пользователем evd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Клава Маус Опубликовано 18 мая, 2009 · Жалоба Браво, Джей! А я уже забыл как набрать 1GE из ОЦК. И просто так, в качестве язвы классическим телефонистам под дыхло, так и не познавшим ATM и ISDN, чтобы сделать по-настоящему супер хорошо и супер непокупаемо дорого: Вы все еще over SDH, тогда мы идем к Вам... :)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
separaf Опубликовано 18 мая, 2009 (изменено) · Жалоба эммм в крупных сетях 99% траффика насколько я знаю так и организовывается, как написал джей. только забыли еще про конкатенацию добавить. На деле реализацию IP через DWDM я видел всего 1 раз. на 10гиговых джуповских платах. странно вообще (лично для меня) использовать волокно меньше чем для stm-64 (его жеж прокладывать замучаешся :) ) Хотя интересно было бы послушать, у кого еще как организован IP транзит. ЗЫ насчет эктратрафика, ну фиг знает, вариант канала который "какбы" работает имхо мало кого устроит. а вот если продумать это дело( какиенить сцепленные кольца, правда время переключения возрастает) то тогда да 50% апгрейд емкости. Изменено 18 мая, 2009 пользователем separaf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 18 мая, 2009 · Жалоба Давайте разбираться господа. Тестить. И не бросаться словами как господин Дятел или еще кто по поводу "фу... отстой...". :(((г-н Джей!Пропуск 300мегабит/сек в том месте, где по договору стоит "до 1Гбит/сек" никакого отношения к упаковке, заголовкам и прочим техническим терминам не имеет. А имеет отношение только к желаниям продать то, чего ещё (или уже) нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 18 мая, 2009 (изменено) · Жалоба Визирь, у меня дропы не на сети, а непосредственно на порту к клиенту. На том порту, который он заказал и полностью без лукавства его утилизует. И клиент это осознает и непосредственно видит.Я никоим образом не наезжал на вашу сеть. Загрузка более 80% при усреднении в пять минут (как на вашем графике) часто означает кратковременные прыжки до 90% и выше, а значит наличие заметного джиттера, а то и вовсе дропов. К сожалению, легко визуализировать на графиках можно только второе... Клиенты бывают разные, да. Кто-то любит полку по 20 часов в сутки... другие готовы доплачивать за полный гигабит лишь из-за того, что на нем не будет висеть полисера/шейпера. Бывают и желающие купить 300мбит через один STM-1... я не шучу. Еще больше поражают манагеры, готовые им это продать ("да, я знаю, что не прокачает через S1 он столько, но вы поставьте, как в бумаге написано, ограничение в 300М и все - остальное не наши с вами проблемы"). А вот операторов, которые предупреждают о недостижимости интерфейсных скоростей я еще не встречал :-). Вы конечно хорошо пишете сочинения... вот только к реальности они никакого отношения не имеют.Для информации: POS-интерфейс STM-64 на маленьких пакетах более эффективен, чем 10GE LAN PHY (но не на столько, чтоб за это переплачивать). Касаемо 4к1: http://www.juniper.net/techpubs/en_US/rele...et-iq2-qpp.html ;) Про Ethernet-over-SDH я вам еще больше скажу: при составлении линка из множества VC у него большие проблемы с поляризацией трафика - в один из VC может идти больше трафика, чем в другой - то есть один на полке, а другой еще скажем на половине... это при реальном трафике, а IMIX-трафик от крутого генератора трафика при этом распределяется между VC идеально :-) Вы все еще over SDH, тогда мы идем к Вам... :))OTN - наше все :-) странно вообще (лично для меня) использовать волокно меньше чем для stm-64DWDM системы с S16 еще долго будут жить... Изменено 18 мая, 2009 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 18 мая, 2009 · Жалоба Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит... Я видел карточки 16ГЕ с 10ГЕ на карту. Но к ним шло уточнение, что это карты или высокоскоростного доступа, или для серверных ферм малонагруженных. Т.е. внутри карты wirespeed, но с карты в шасси только 10-ка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j_box Опубликовано 18 мая, 2009 · Жалоба Визир. Мне до вашего уровня владения темой далеко. Больше словоблудия и попыток нахвататься верхушек у более знающих людей. :( Заметье я ни разу не упомянул Джупы. Я их не знаю. К сожалению. :(( Теперь о сабже. Вы сами прекрасно знаете какие возможности у транспортной сети. Но не самое главное связать ключевые точки нужной пропускной способностью. Главное дать достаточное количество нужных портов и полосу на переферию. А это уже дороже, гораздо дороже и дольше. Я предложил вариант решающий эпизодические проблемы на переферии во многих и многих начинающих сужаться местах сети. Дешево. Без апгрейда. Почувствуйте разницу... Ну а в остальном мне трудно спорить. Мало знаю. :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LeOs Опубликовано 18 мая, 2009 · Жалоба Уважаемые, пара комментов: - у Juniper как раз есть ограничения пропусконой способности интерфейса, вызванне модульной структурой (http://www.juniper.net/techpubs/en_US/rele...s/frameset.html, например), - когда говорят о пропуске EoSDH, стоит, наверно, упомянуть и GFP (например, GFP-T) маппирование, - практика показывает ограничение трафика по STM-1 в 145Мбит/с, а не 140, т.к. размещение идет не в VC-4, а в AU-4, - да и с E12 - если unframe, то 32 * 8000*8 =2048кб/с, Но я, как вшивый, опять о бане: 80-85% из каких соображений? только из-за возможных всплесков, и, как следствие, потерь, или же я просто упускаю еще какой-то фактор ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 18 мая, 2009 · Жалоба Но я, как вшивый, опять о бане: 80-85% из каких соображений? только из-за возможных всплесков, и, как следствие, потерь Потери - это уже крайний случай, когда буфера переполнены. Перед ними начинается рост задержки, из-за ожидания отправки в буферах.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LeOs Опубликовано 18 мая, 2009 · Жалоба Но я, как вшивый, опять о бане: 80-85% из каких соображений? только из-за возможных всплесков, и, как следствие, потерьПотери - это уже крайний случай, когда буфера переполнены. Перед ними начинается рост задержки, из-за ожидания отправки в буферах.. А не сочтете за труд, поянить недогадливому, о каких буферах идет речь, если, по умолчанию, идет тоько Интернет, все помечено классом нормал, и ограничения производителности железа еще не достигнуты ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Клава Маус Опубликовано 18 мая, 2009 · Жалоба Загрузка более 80% при усреднении в пять минут (как на вашем графике) часто означает кратковременные прыжки до 90% и выше, а значит наличие заметного джиттера, а то и вовсе дропов. К сожалению, легко визуализировать на графиках можно только второе...Прыжки делового трафика в штатном режиме на гигабитном интерфейсе величиной в 100Мбит и выше, не видимые на фоне усреднения? А на сколько же скачут у вас пики в 10GE? Это какой такой тип клиента/сервиса/железа их организует? Может у вас вся совокупность пользователей на том конце сети чудом синхронизуется на несколько секунд в попытке вдуть пик, а на другом конце сети этим же чудом в этот же момент синхронизуются потребители этих коротких пиков? А потом эти чудом синхронизированные предъявляют претензии, хором тряся эсэлеями, где вы прописали нормативы по джиттеру? И поэтому, написав в заказе 1000Мбит, вы клиенту их не даете, в борьбе за минимизацию джиттера клиентских пакетов :)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j_box Опубликовано 18 мая, 2009 · Жалоба практика показывает ограничение трафика по STM-1 в 145Мбит/с, а не 140, т.к. размещение идет не в VC-4, а в AU-4, Полез я в доки... вспоминать... AU-PTR муксы разбирают из STM кадра на каждой мультиплексорной секции еще до кросс-комутации. Это указатель. При следующей сборке STM кадра мукс влепит туда новое значение. использовать эти девять байт под полезную нагрузку не получится. ИМХО. А вот VC4 можно пропустить через матрицы кросс-комутации не разбирая, но на входе и выходе из транспорта мукс отрежет РОН... Отсанется С4 а это 260 * 8 * 9 * 8000 = 142,82 Мб/с Все. Больше из STM-1 не выжать. ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 мая, 2009 (изменено) · Жалоба А вот VC4 можно пропустить через матрицы кросс-комутации не разбирая, но на входе и выходе из транспорта мукс отрежет РОН...Отсанется С4 а это 260 * 8 * 9 * 8000 = 142,82 Мб/с Все. Больше из STM-1 не выжать. ИМХО. Джей, упаковывать данные в VC4 могут только дорогие Channelized платы.Обычные POS-ы тупо без сложной упаковки используют весь payload STM-фрейма, получается ~150мбит для HDLC/PPP-трафика. Что с учетом HDLC-заголовков и bit/byte stuffing-а дает ~135-145 мбит на IP уровне. Для мультиплексирования в верхние уровни в payload заглядывать необязательно. Изменено 19 мая, 2009 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Нерубящий инспектор Опубликовано 19 мая, 2009 · Жалоба Заметно, что 16кбит информации - служебные ( не доступны пользователю для передачи полезной информации ). Значит реальная пропускная способность Е1 ( для пользователя) = 30 * 8000 = 1920кб/с. Я так понимаю - это если Е1 фракшинл ( по нашему ИКМ 30), а если унфракшнл - то все 2048 (по нашему ИКМ 32). А есть еще и ... по нашему ИКМ 31. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 мая, 2009 (изменено) · Жалоба А не сочтете за труд, поянить недогадливому, о каких буферах идет речь, если, по умолчанию, идет тоько Интернет, все помечено классом нормал, и ограничения производителности железа еще не достигнуты ?И что, при этом буфера не используются ?Результат получается такой: Изменено 19 мая, 2009 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 19 мая, 2009 · Жалоба - у Juniper как раз есть ограничения пропусконой способности интерфейса, вызванне модульной структурой (http://www.juniper.net/techpubs/en_US/rele...s/frameset.html, например), Не совсем так. У (младших) Джуниперов M-серии существует ограничение по пропускной способности FPC. Карточка STM16, занимающая как раз все четыре слота FPC M20, например, способна пропустить ровно столько трафика, сколько влезает в STM16. А вот 4 гигабитных PIC'а, вставленных в этот же FPC, загрузить все разом свыше 80% не получится. Но можно раскидать их по двум FPC, получив полноценные 4Gbps full duplex Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vsn Опубликовано 20 мая, 2009 · Жалоба Доброго времени, уважаемые! Если позволите, приведу разъяснения, откуда взялись эти пресловутые 80% в данном, конкретном случае. Дело в том, что в нашем случае, клиент не забирает услугу напрямую с магистрального порта КТТК. Между КТТК и клиентом есть последняя миля. Миля с интерфейсом GE. Давным-давно в КТТК, разработана процедура паспортизации линий доступа с Ethernet окончаниями, согласно которой, основная услуга, передаваемая по этой ПМ не должна занимать более 80% пропускной способности ПМ. Т.е. - не более 800 Мб/с по гиговому линку. Хорошо это, или плохо - разговор другой, но обойти это требование удается только в экстренных случаях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LeOs Опубликовано 20 мая, 2009 · Жалоба Спасибо. Теперь понятно. Иначе получалось, что одни говорят о том, что утилизация порта с точки зрения буфера не должна превышать определенного порога, а другие подразумевают допустимый предел полосы, оставляя за потребителем право решать, на сколько близко подходить к данному пределу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vsn Опубликовано 20 мая, 2009 · Жалоба Ой, надеюсь, что уважаемые разберутся, о каком конкретно случае речь идет? :) К Ростелеку я отношения не имею :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...