Современная отечественная ВТ

 
1 2 3 4 5 6

Mishka

модератор
★★★
Fakir> Хм, а может, большое количество серостей, ломанувшееся писать коды, как раз и отпугивает потенциально толковый народ? ;) Возможно, это одна из причин.

Конкуренция, конечно, и для них повысится, но не думаю, что это главная причина.

Fakir> А другая причина, ИМХО, в том, что серьёзному программированию у нас учат (в большинстве), увы, весьма бездарно - подход ни к чёрту. [»]

И это тоже. Но почему не каждый выпусник МГУ — хотя бы Кострикин или тот же Фоменко, или кто там из физиков?
 

Fakir

BlueSkyDreamer
★★★★
"Почему не" что именно?


Конкуренция, конечно, и для них повысится, но не думаю, что это главная причина.
 


Я не столько про конкуренцию, сколько про общий уровень среды, и возникающее ощущение - "неинтересно".
 
+
-
edit
 

Nikita

аксакал

au> Если вы серьёзно занимаетесь чем-то в этой области, это должно как минимум порождать сильные эмоции и большие риторические вопросы.

Гы... Я писал ПО для TI'шных DSP в свое время. Эмоции были в основном матерные. Вопросы тоже :D

Тупые компиляторы не использующие и трети возможностей процессора, куча глюков как в них, так и в самих процах - проблемы совместимости. После x86 смотрелось совершенно некузяво. А так да, мощные штуки. Только вот чтобы добиться приличного результата прыгать надо очень много. История а-ля Itanium практически...

au> В них же целый исторический музей развития х86 от первых ласточек. В них же целый зоопарк выкрутасов под заказ отдела маркетинга, которые калечат и без того калечную архитектуру.

Клиентам нужна эффективная совместимость. Можете считать это маркетингом, но для потребителей сей аспект крайне существенный.

au> В них (у меня, к счастью, нет) же это чудо мысли под названием мультитрединг, в результате чего процессор в такой келейной проге как матлаб никогда не работает быстрее 50% своей скорости :)

Гы... Ну так сделайте MATLAB на FPGA, что страдаете-то ??? :D

au> В результате всего этого имеем что имеем — чудо-юдо рыбу-кот эпических размеров и неэффективности. Зато её любой дурак запрограммирует...

Вот именно. Разработка ПО для них мегадешева и по силам обычным пользователям, а не только программистам, что перевешивает все недостатки.

au> Это программистам так удобнее, быстрее и дешевле, потому что иного они не только не знают, но и представить не могут.

Гы... А где Вы других программистов-то возьмете ??? На Луне ???

au> Большая часть программистов имеет крайне смутное — если вообще имеет — представление о том ЧТО ОНИ СОБСТВЕННО ПРОГРАММИРУЮТ.

И правильно. Большинству этого совершенно не надо знать. Им надо всего лишь знать КАК программировать ЭТО.

au> Их так воспитали. И это сказывается на результатах.

Но я вообще-то не о программистах, а о пользователях речь веду. Мой шеф никакой не программист, он физик. И ему нужно просто считать свои задачи, для которых он использует MATLAB и т.п. вещи.

au> Значит цена вопроса 3 копейки. Правильно шеф сделал.

Гы... Экспериментальная установка, к которой был потом подсоединен тот самый P4 с тем самым шефовским софтом, стоит далеко не 3 копейки. Но тем не менее я рад, что Вы со мной согласились :)

Вышеописанное использование и составляет основной рынок P4 для различного рода управляющих/вычисляющих задач.

au> Я прекрасно знаю о стоимости разработки, и мне лень было писать что тот пример с томографом был посвящён компиляции С-кода в ФПГА,

Неужели такая эффективная стала ? Или такой алгоритм простой ? Или компилятор только этот один алгоритм и умеет компилировать ? :)

au> и мне ещё более лень писать что стоимость разработки и отладки системы на ФПГА вполне себе на уровне софта,

"Не верю" (с) не мой

Покажите мне тот же MATLAB на FPGA, например :) А вот обратное запросто могу продемонстрировать. У меня знакомый на MATLAB'е конструирует различные прибамбасы на Xilinx'овских девайсах :)

au> т.к. нет ни итеративного заказного производства, ни связанных с этим задержек и затрат,

Как это их нет ??? Вы же пропагандируете FPGA и т.п. в массы ??? Значит все будет.

au> Так что вкратце картина в целом такова, что железо по стоимости/производительности (с учётом разработки) уделывает софт на порядки как минимум в приведённых показательных примерах.

В показательных несомненно. Однако как только надо сделать систему чуть погибче и посложнее стоимость вырастает до небес.

au> Ещё часть картины, которую вы вообще не замечаете, это те приложения, которые на софте вообще адекватно не реализуются в силу разных причин.

И такие есть. Однако их рыночная доля "1 лира".
Учитесь читать.  

pokos

аксакал

Ну, товарищи, смотрю я тут уже схлестнулсь не на шутку. Подолью и я дизтоплива...

Извечные жалобы на программистов проистекают, думается, из того, что "железные" инженеры никак не могут примерить обычные промышленные требования к процессу программирования.
"Железные" инженеры легко расчленяют свои разаработки на слабозависимые куски, запросто вводят иерархию разработчиков, с пол-пинка достигают максимальной надёжности изделия и т.д.
А теперь представьте, что вам нужно в конкретные сроки написать программу, которая будет выполнять конкретные задачи.
Значит:
1. Полагаться на одного человека, пусть даже и гнения, совершенно недопустимо, хотя бы потому, что он может физически не успеть написать КОД! Значит гения поставим руководить разработкой, а ему в подчинение дадим хороших программистов, а им, в свою очередь, обыденных кодеров после ПТУ. Да и гения в действительно большом проекте надо бы исключить, заменив на группу полу-гениев, которых одним махом не сможет задавить паровоз или накорню скосить старшина Панасюк.
2. Поскольку продукт будут рожать разные люди, надо расчленить его на куски, которые будут взаимодействовать совершенно определённым, известным всем образом. вот тут поле вообще не паханое. Согласование параметров даже стандартных интерфейсов в программировании занимает огромное количество времени. Представьте себе, что строители железа в каждом проекте решали, сколько проводов использовать, к примеру, в ISA или I2C.
3. Железные инженеры почти всегда могут ограничиться тестированием отдельных блоков, чтобы быть практически уверенными в работоспособности всего изделия. программистам такого не дано. Тестирование программм - задача крайне тяжёлая, потому что практически не поддаётся алгоритмизации. соответственно, гарантировать какую-либо надёжность практически невозможно.
4. В чисто железных изделиях не бывает функций с разрывами кроме хорошо известного резонанса, и то, бесконечной добротности не бывает. Программисты используют ф-ции с разрывами сплошь и рядом, поэтому итеративные методы отладки в программировании практически не работают, а ещё, из-за этой особенности точечная ошибка в одном из модулей способна привести к краху всей системы.
5.
6.
7.
.
.
.
.
Поэтому существующая ситуация в программировании и существует. И всей промышленности вцелом гораздо выгодней плодить уродов типа Пня, 1ВМ/РС, Езернета или Windows и добиваться нужных параметров поддачей "кокса", нежели раз в три года переучивать всех разработчиков.

Что же касается такого интересного момента, как компиляция задач прямо в FPGA, то это, безусловно, дело стОящее. Но есть одна существенная засада. Нонешние программисты не мыслят категориями полной параллельности всех операций. Их учили, что алгоритм - это последовательность действий. Обычному программисту чрезвычайно трудно представить, что будет с программой, в которой, к примеру, одновременно и асинхронно крутятся все циклы. Вкурить такие чудовищные зависимости по данным, которые возникают при полном параллелизме, под силу не всем средствам разработки, не то что голове обыденного программиста.
Так что, и Пень и транспьютеры, и вся другая петрушка, несомненно, будут иметь свои ниши. Что же касается перераспределения объёмов между ними, то, думается, оно не будет сколько-нибудь существенным в ближайшие несколько лет.
 
RU Серокой #05.09.2005 14:03
+
-
edit
 

Серокой

координатор
★★★★
pokos> 3. Железные инженеры почти всегда могут ограничиться тестированием отдельных блоков, чтобы быть практически уверенными в работоспособности всего изделия. программистам такого не дано.

Ни в коем случае! Мало того, обычно так: что не протестировали, там обязательно будет ошибка! Тестирование сложных железок - отдельная песня... И тема не одной уже написанной, а тем более будущей диссертации!
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©  

pokos

аксакал

Серокой> Мало того, обычно так: что не протестировали, там обязательно будет ошибка!
Ясен пень, для того и тестируют.
Серокой> Тестирование сложных железок - отдельная песня... И тема не одной уже написанной, а тем более будущей диссертации!
Особенно, если учесть, что современные сложные железки что-нибудь программируемое да содержат..... Диссертации, оно понятно, а вот метода доказательства останова (!) произвольного алгоритма доселе не существует. Про работоспособность - вообще тоска.....
 

TEvg

аксакал

админ. бан
>гораздо выгодней плодить уродов типа Пня, 1ВМ/РС, Езернета или Windows

Про прочих согласен, а чем не угодил Етзернет?
 

pokos

аксакал

TEvg> Про прочих согласен, а чем не угодил Етзернет?
Есть такая нужная штука как QoS. Да и Latency, в кластерах например, весьма важная штука.
 
EE Татарин #05.09.2005 15:21  @pokos#05.09.2005 14:55
+
-
edit
 

Татарин

координатор
★★★★☆
TEvg>> Про прочих согласен, а чем не угодил Етзернет?
pokos> Есть такая нужная штука как QoS. Да и Latency, в кластерах например, весьма важная штука. [»]
Альтернативы в этой нише ?
АТМ? ТокенРинг?

Проблемы КО в езернете - это МИФ. Решаются на раз, и там где КС реально нужен, они решены.
Задержка - опять же МИФ. Какая может быть задержка в двунаправленой линии "точка-точка"?
Проблемы не относятся к физическому уровню как таковому, а на верхних уровнях езернет очень гибок... причем, без потери совместимости!
Не надо путать оригинальную сеть Ксерокса (4МБит еще :) с современными езернет-сетями.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  

Nikita

аксакал

au> Ой, да под любые... Вояки давно не оригинальны в своих задачах.

Ну так продвигайте, кто мешает-то ? Забабахайте веб-, гис-, xyz-сервер на FPGA и вперед :D

au> Надёжность — это показатель системный. Надёжность "железа", т.е. в вашей нотации это кремний, никого не интересует.

Но Вы же только о "железе" вещаете. ПО я у Вас пока не видел, у Вас оно почему-то абсолютно и идеально.

au> Надёжность техники на базе ПК поэтому — на уровне плинтуса.

Во многих случаях несомненно (однако и даже в этих случаях она вполне достаточна почти всегда). Но речь-то опять не об этом, а том что железо тут непричем. Дятлы Вам точно такую же ерунду и на FPGA сделают, даже хуже.

au> Точнее сказать её просто нет — эта техника строго говоря непредсказуема в своей глючности. И главная причина этого — ПО.

Вот именно. И P4 или там FPGA тут совершенно не при делах.

au> Но не оно само лишь, а то, что вокруг него всё крутится.

Следствия тоже несомненно влияют. Совместимость одно из таких следствий. И если в массовых решениях Вы будете её игнорировать, то просто разоритесь.

au> Оно калечит архитектуру железа, оно же стирает всякие понятия о надёжности и качестве техники, и оно же заставляет принимать всё это как неизбежное.

Всё и всегда есть компромисс.

au> Развивать его — это значит усугублять ситуацию дальше. Уже "наразвивали" его по самое некуда.

Ерунда. Методы разработки ПО находятся в самом начале пути. Работы непочатый край. Никто так и не знает как быстро, дешево и качественно делать сложные программные системы.

au> Я уж не упоминаю что ПО-центричный подход сразу перекрывает кислород массе задач и приложений.

Да пускай желающие копаются и в железе, не проблема, "рука рынка" сама тут все решит. Но серьезные усилия и ресурсы туда заливать не надо.

au> Но с эгоистичной точки зрения я сильно протестовать не буду — гораздо лучше делать то, что мало кто умеет, чем конкурировать с ордами программистов-недоучек на их поле. [»]

Что-то странное Вы сказали... В данной области недоучки конкурируют только между собой, бо профи нехватка и их с руками рвут. Везде кадровый голод на специалистов. И если Вы боитесь недоучек здесь, значит Вы такой же недоучка :)
Учитесь читать.  

pokos

аксакал

Татарин> Альтернативы в этой нише ?
Татарин> АТМ? ТокенРинг?
Забейте на это старьё, на текущее время это разве FC, и то потеря маркера могёт случиться. С разбегу не помню, как называется то, что щас ставят в кластеры, но можно легко найти. Latency на порядок меньше, чем в ГигЕ.

Татарин> Проблемы КО в езернете - это МИФ. Решаются на раз, и там где КС реально нужен, они решены.
Это не миф, а то, с чем я почти ежедневно сталкиваюсь на работе. В Езернете эти проблемы "решены" путём добавки кокса, остальные её средства - мёртвому припарки.

Татарин> Задержка - опять же МИФ. Какая может быть задержка в двунаправленой линии "точка-точка"?
Хотя бы пакетизации. В курсе, что в гиговом Езернете минимальная длина пакета увеличена по сравнению с фастом? Можно найти ещё пару-тройку причин, если внимательно почитать 802.х.
Кроме того, не забывайте, что Ваша точка-точка обычно заканчивается на коммутаторе.

Татарин> Проблемы не относятся к физическому уровню как таковому, а на верхних уровнях езернет очень гибок...
Я про физический уровень и не говорю, я говорю про канальный. Ни CoS, ни DiffServ не обеспечивают настоящих гарантированных параметров. Любая очередь в любом коммутаторе Езернет може переполниться.
 
EE Татарин #05.09.2005 16:16
+
-
edit
 

Татарин

координатор
★★★★☆
Mishka> Как Фейнман вспоминал, когда он пошел работать инженером по разработке шестереночных передач. Начал он со своего подхода, но был быстро поправлен товарищем — тот показал как правильно выбирать шестеренки из справочника, как одно решение тянет другое и какие параметры можно и нужно варьировать. Фейнман восхищался уровнем проработки, насколько я помню, и быстро освоил дело. Я надеюсь, что понятно куда я тяну. Вот когда такой уровень будет в программировании, тогда и можно будет, что программирование достигло уровня инженерной науки.
Так ведь в чем вопрос?
ПРограммирование как индустрия возникло раньше, чем микроэлектроника (именно в их современном виде). ПРограммистов - больше, чем электронщиков. Технических препятствий к увеличению числа программистов нет.

Но программирование до сих пор во многом на кустарно-артельном уровне. Отчего и качество.

Почему - мне непонятно.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  
EE Татарин #05.09.2005 16:29  @pokos#05.09.2005 15:42
+
-
edit
 

Татарин

координатор
★★★★☆
Татарин>> Альтернативы в этой нише ?
Татарин>> АТМ? ТокенРинг?
pokos> Забейте на это старьё, на текущее время это разве FC, и то потеря маркера могёт случиться. С разбегу не помню, как называется то, что щас ставят в кластеры, но можно легко найти. Latency на порядок меньше, чем в ГигЕ.
Ну, кластера - это не ниша езернета.
Скажем, офисная сеть, сеть предприятия, сеть города - последней мили.
Где альтернативы, которые могли бы конкурировать по всем параметрам?

pokos> Это не миф, а то, с чем я почти ежедневно сталкиваюсь на работе. В Езернете эти проблемы "решены" путём добавки кокса, остальные её средства - мёртвому припарки.
Альтернатива - разве что АТМ. :)
Вот там с КС, конечно, все просто зашибись. Только кроме КС, оказывается, людям еще кое-чего от сетки надо. :)

pokos> Хотя бы пакетизации. В курсе, что в гиговом Езернете минимальная длина пакета увеличена по сравнению с фастом? Можно найти ещё пару-тройку причин, если внимательно почитать 802.х.
А что, джумбо-кадры прям так жестко необходимы?
Пользуйтесь маленькими пакетами, и будет счастье. Да, будете не выбирать полностью возможности канала... И чего? С чем сравниваем-то?

pokos> Кроме того, не забывайте, что Ваша точка-точка обычно заканчивается на коммутаторе.
А это зависит от.

Татарин>> Проблемы не относятся к физическому уровню как таковому, а на верхних уровнях езернет очень гибок...
pokos> Я про физический уровень и не говорю, я говорю про канальный. Ни CoS, ни DiffServ не обеспечивают настоящих гарантированных параметров. Любая очередь в любом коммутаторе Езернет може переполниться. [»]
Если специально отключен или не поставлен флуд-контроль... если сеть спроектирована неправильно и много потоков маршрутизируются в канал с недостаточной пропускной способностью... если криворукий админ поставил неподходящее железо и недостаточно памяти на маршрутизаторе...
Да.

А что, это проблемы технологии? :)
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  

pokos

аксакал

Татарин> Где альтернативы, которые могли бы конкурировать по всем параметрам?
Альтернативы в данный момент не являются стандартами. Езернет, к примеру, довольно тяжко пользовать, если нужно гнать пользователю IPTV. Да и речь не обо всех параметрах, а о конкретном, разговор-то об уродцах. С Пнём по всем параметрам тоже никто не в силах конкурировать. Пока.

Татарин> Альтернатива - разве что АТМ. :)
Смайлик к месту..... Ещё MPLS туда же.

Татарин> А что, джумбо-кадры прям так жестко необходимы?
Джумбо - это то, что больше, а не то, что меньше, а разговор о минимальной длине фрейма.

Татарин> А это зависит от.
В реальной жизни практически не зависит.

Татарин> А что, это проблемы технологии? :)
Конечно. Технология принципиально не позволяет сделать гарантированный QoS, остальное - только следствия и припарки.

 
RU Nikita #05.09.2005 17:01  @Татарин#05.09.2005 16:16
+
-
edit
 

Nikita

аксакал

Татарин> ПРограммирование как индустрия возникло раньше, чем микроэлектроника (именно в их современном виде).

Неверно. Микроэлектроника это обычная инженерная отрасль, такая же как автомобилестроение, например. Так что совершенно неважно когда она возникла, приемы там те же.

Татарин> ПРограммистов - больше, чем электронщиков.

Так и софта нужно гораздо больше чем железяк. И спрос на программистов сейчас неудовлетворен.

Татарин> Технических препятствий к увеличению числа программистов нет.

Есть. Можно настругать сколько хошь только середняков да кодеров всяких. А вот тех кто может вести и рулить проектами всегда не хватает, за них ведь еще и другие отрасли борются.

В нашей компании, например, постоянно висят несколько достаточно крупных проектов, на которые просто нет архитектора/ведущего разработчика (недавно ситуация еще более ухудшилась, один из наших ведущих специалистов, мой хороший друг скончался от рака). Появись они, и мы сразу бы увеличили штат еще человек на 6-8, бо кодеров и середняков в избытке.

Татарин> Но программирование до сих пор во многом на кустарно-артельном уровне. Отчего и качество.
Татарин> Почему - мне непонятно. [»]

Потому что большинство методов решения проблемы сроки/цена/качество из массового промышленного производства в индустрии разработки ПО просто неприменимы. Суть другая.
Учитесь читать.  
Это сообщение редактировалось 05.09.2005 в 17:28
RU Dem_anywhere #05.09.2005 18:07
+
-
edit
 

Dem_anywhere

аксакал
★☆
Давайте всё-таки не забывать, что и таблица умножения - тоже математика. И ещё совсем недавно её знал ничтожный процент людей.
Так и с программингом - скоро написать прогу из десяти строчек или сделать "умную" веб-страничку - сможет каждый.
А вот серьёзные программы - так и останутся за единицами...
 

Mishka

модератор
★★★
pokos> Забейте на это старьё, на текущее время это разве FC, и то потеря маркера могёт случиться. С разбегу не помню, как называется то, что щас ставят в кластеры, но можно легко найти. Latency на порядок меньше, чем в ГигЕ.

FC — Fiber Channel. Интересно, какие там цифры?

Что такое КО?

pokos> Это не миф, а то, с чем я почти ежедневно сталкиваюсь на работе. В Езернете эти проблемы "решены" путём добавки кокса, остальные её средства - мёртвому припарки.

Про эзер хорошо известно, что при достижении утилизации 60%, количество битых пакетов возрастает очень сильно.

pokos> Хотя бы пакетизации.

FC тоже не стрим.

pokos> В курсе, что в гиговом Езернете минимальная длина пакета увеличена по сравнению с фастом? Можно найти ещё пару-тройку причин, если внимательно почитать 802.х.

Не зная насчет минимальной (вроде не видел), а максимальная точно — jumbo packets.

pokos> Кроме того, не забывайте, что Ваша точка-точка обычно заканчивается на коммутаторе.
pokos> Я про физический уровень и не говорю, я говорю про канальный. Ни CoS, ни DiffServ не обеспечивают настоящих гарантированных параметров.

А чем CoS отличается от DiffServ? Это вовсе не гарантированный QoS.

pokos> Любая очередь в любом коммутаторе Езернет може переполниться. [»]

Это справедливо для любой системы с очередями, у которой на входные очереди поступает инфа быстрее, чем вылезает через выходные. Посмотрите на самые простые модели из теории очередей.

 

Mishka

модератор
★★★
pokos> Альтернативы в данный момент не являются стандартами. Езернет, к примеру, довольно тяжко пользовать, если нужно гнать пользователю IPTV.

Имеется ввиду не контролируемый jittering и latency или что-то другое?

pokos> Да и речь не обо всех параметрах, а о конкретном, разговор-то об уродцах. С Пнём по всем параметрам тоже никто не в силах конкурировать. Пока.

А какие альтернативы. Тот же FC — хорош, если звезда.

Татарин>> Альтернатива - разве что АТМ. :)
pokos> Смайлик к месту..... Ещё MPLS туда же.

Это каким местом? Он вырос, частично из АТМ, но гораздо проще и таблицы меток сейчас piggy back на BGP, хотя и есть механизм локального распротранения, но последний не гарантирует того, что поток будет распозноваться с теми же условиями.

Татарин>> А что, это проблемы технологии? :)
pokos> Конечно. Технология принципиально не позволяет сделать гарантированный QoS, остальное - только следствия и припарки. [»]

А кто или что из канального уровня позволяет сделать гарантированный QoS?
 

Mishka

модератор
★★★

Nikita> Потому что большинство методов решения проблемы сроки/цена/качество из массового промышленного производства в индустрии разработки ПО просто неприменимы. Суть другая. [»]

Я всегда говорю, что технология в программировании лишь повышает вероятность выхода продукта, в то время как в инженерных отрослях технология гарантирует.
 

pokos

аксакал

Mishka> Я всегда говорю, что технология в программировании лишь повышает вероятность выхода продукта, в то время как в инженерных отрослях технология гарантирует.
Согласен на все 100.

 

pokos

аксакал

Mishka> FC — Fiber Channel. Интересно, какие там цифры?
С разбегу не скажу, надо искать, причём, щас актуален FC1200.
Mishka> Что такое КО?
Думается, Татарин имел в виду CoS.
Mishka> Про эзер хорошо известно, что при достижении утилизации 60%, количество битых пакетов возрастает очень сильно.
Для ГигЕ это не так. Но для этого приняты специальные меры, которые не имеют ничего общего с CSMA/CD.
Mishka> FC тоже не стрим.
Я и не спорю. Только в FC изначально есть простой и эффективный метод ограничения скорости клиента - коммутатор просто не отдаёт маркер сразу, а в Езернете для этого приходится использовать "примочки", поэтому Latency принципиально больше.
Mishka> Не зная насчет минимальной (вроде не видел), а максимальная точно — jumbo packets.
Если мне не изменяет склероз, то в ГигЕ минимальный пакет - 512 байт.

Mishka> А чем CoS отличается от DiffServ? Это вовсе не гарантированный QoS.
Тут надо отделить локальные применения от магистральных. DiffServ относится к пакету, а не к каналу, поэтому при сложной топологии DiffServ не гарантирует CoS.

Mishka> Это справедливо для любой системы с очередями, у которой на входные очереди поступает инфа быстрее, чем вылезает через выходные. Посмотрите на самые простые модели из теории очередей.
Спасибо за науку, это мне известно. Сейчас есть масса применений, где очереди в любом виде весьма вредны.

Mishka>Имеется ввиду не контролируемый jittering и latency или что-то другое?
И то, и другое, и время восстановления при неисправности, и потеря пакетов.

Mishka>А какие альтернативы. Тот же FC — хорош, если звезда.
Ну, речь шла о "по всем параметрам", поэтому не стоит забывать про стоимость оконечного оборудования, да и коммутаторы доступа. FC прекрасно работает там, где эти факторы малозначительны, причём без гемора достигаются, к примеру, внутримосковские расстояния .

Mishka>Это каким местом? Он вырос, частично из АТМ, но гораздо проще и таблицы меток сейчас piggy back на BGP, хотя и есть механизм локального распротранения, но последний не гарантирует того, что поток будет распозноваться с теми же условиями.
Опять же, нужно рассматривать вцелом. И получается, что тащить MPLS до клиетна - чрезвычайно дорого, да и на магистральном уровне оч. желательна хорошая связность сети, а это тоже не дёшево обходится. MPLS - это сейчас довольно модно, все хотят IP-MPLS (многие, правда, плохо представляют, зачем), только когда дело доходит до подсчёта капитальных и эксплуатационных затрат, энтузиазм резко убавляется.

Mishka>А кто или что из канального уровня позволяет сделать гарантированный QoS?
АТМ и коммутация на первом уровне. АТМ на магистрали сейчас уже не актуален ввиду маленькой скорости, а в локалке он никогда и не был актуален.

В общем, по этой теме можно написать целую статью.
А Езернет щас шагает по странам и континентам, довольно успешно даже на магистралях с применением чего-либо типа Mac-In-Mac. Дело в том, что QoS клиента и QoS оператора никак не связаны, у оператора свои взгляды на бизнес, именно поэтому всякие DiffServ слабо применимы.
Читсый Езернет прекрасно применяется в сетях с 20тыс. клиентов, правда до тех пор, пока не нужно сколько-нибудь реальное время. Как только оно становится нужным, затраты на планирование и администрирование сети возрастают на порядки.
Что же касается настоящего QoS, то его на магистралях сейчас может обеспечить только SDH, причем в SDH понятие QoS имеет несколько иной смысл - это всего лишь время восстановления канала при аварии на сети.
 

Mishka

модератор
★★★
pokos> Думается, Татарин имел в виду CoS.

Здесь, похоже, мы плаваем в терминологии. Я приведу, как ее знаю (к сожалению, я ее знаю больше по-английски):
CoS — Class of Services
QoS — Quality of Services
ToS — Type of Services
DiffServ — Differentiated Services
IntServ — Integrated Services
Controlled Load Services
Guaranteed Qos

CoS, ToS, Diffserv — они все одного класса. Гранулярность очень небольшая и определение типов траффика очень грубое. Они принципиально относятся к Controlled Load типу. На уровне IP они переиспользуют тоже самое поле (ToS), только. И хотя рабочяя группа Diffserv сделала много, и классы сервиса ввела (Assured Forwarding, etc) — это все равно очень грубая, но хорошо масштабируемая модель. IntServ включает в себя RSVP и его поддержку, но эта часть гораздо ближе к ATM, чем DiffServ — QoS АТМ базируется на том, что он (АТМ) connection oriented. Да, там есть понятия CBR и VBR, но это уже дополнительная грануляция и параметры виртуального канала. Впрочем, в PATH/RESERV сообщениях RSVP можно описать не меньше.


pokos> Для ГигЕ это не так. Но для этого приняты специальные меры, которые не имеют ничего общего с CSMA/CD.

??? Точно ??? И там нет MA? Надо будет почитать.

pokos> Я и не спорю. Только в FC изначально есть простой и эффективный метод ограничения скорости клиента - коммутатор просто не отдаёт маркер сразу,


Этот метод очень плохо масштабируется. При наличии пары устройств — хорошо, а потом растет линейно. Опыты с многими маркерами тоже были, но там другая проблема — как отслеживать количество маркеров и разрешать ли им обгонять друг друга. Кроме того, можно перегрузить центральное устройство. Я так регулярно делаю с моим кабельным модемом (точнее с CMTS). В результате ошибка таймера Т4 и перезагрузка модема.

pokos> а в Езернете для этого приходится использовать "примочки", поэтому Latency принципиально больше.

Правильно, он не был расчитан на это, но вроде 802.3p/q (приоритезация и VLAN — которые те же тэги) уже кое что поправляют.

pokos> Если мне не изменяет склероз, то в ГигЕ минимальный пакет - 512 байт.

Вот, перерыл IEEE сайт и таки нашёл. Гигабит, все-таки обычный CSMA/CD и размеры фремов даны такие:

802.3-2002_part3.pdf
Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications

SECTION THREE: This section includes Clauses 34 through 43 and Annexes 36A through 43C.

34. Introduction to 1000 Mb/s baseband network

34.1 Overview

Gigabit Ethernet couples an extended version of the ISO/IEC 8802-3 (CSMA/CD MAC) to a family of 1000 Mb/s Physical Layers. The relationships among Gigabit Ethernet, the extended ISO/IEC 8802-3 (CSMA/CD MAC), and the ISO/IEC Open System Interconnection (OSI) reference model are shown in Figure 34–1.


....

page 373

43B.6.2.3 Transmission characteristics
SP2 Frame size 43B.2 Normal IEEE 802.3®frame size range (see 4.4.2)
 


802.3-2002.pdf
Parameters
 Values
slotTime 512 bit times
interFrameGap 9.6 μs
attemptLimit 16
backoffLimit 10
jamSize 32 bits
maxUntaggedFrameSize 1518 octets
minFrameSize 512 bits (64 octets)
burstLimit not applicable
 


pokos> Тут надо отделить локальные применения от магистральных. DiffServ относится к пакету, а не к каналу, поэтому при сложной топологии DiffServ не гарантирует CoS.

Ага, local vs global? Diffserv — это простое раскрашивание траффика. Он все-таки относится к потоку, а не пакету. Поскольку красится по решению поток. Другое дело, что он может в раутере перекрашиваться. Кроме того, он относится к controlled load, а не guaranteed, так что говорить о полноценном QoS-е (с точки зрения real time intollerable applications не приходится.

pokos> Спасибо за науку, это мне известно. Сейчас есть масса применений, где очереди в любом виде весьма вредны.

Покажите мне хоть один прибор, где очереди не применяются. Системы с маркером не приводить — они не масштабируются.

pokos> И то, и другое, и время восстановления при неисправности, и потеря пакетов.

Потеря пакетов — это стандартная модель траффика. А вот время восстановления — это, ИМХО, уже к надежности (reliability) относится. Не надо все в кучу валить. Там математика, конечно, похожая, но всё-таки это разные вещи.

pokos> Ну, речь шла о "по всем параметрам", поэтому не стоит забывать про стоимость оконечного оборудования, да и коммутаторы доступа. FC прекрасно работает там, где эти факторы малозначительны, причём без гемора достигаются, к примеру, внутримосковские расстояния .

Сколько приборов на линии? Два — типа точка-точка? Тогда и у эзера нет проблем.

pokos> Опять же, нужно рассматривать вцелом. И получается, что тащить MPLS до клиетна - чрезвычайно дорого, да и на магистральном уровне оч. желательна хорошая связность сети,

A иначе MPLS безполезен — какой смысл метить пакеты для ускоренной маршрутизации, если маршрут один?

pokos> а это тоже не дёшево обходится. MPLS - это сейчас довольно модно, все хотят IP-MPLS (многие, правда, плохо представляют, зачем), только когда дело доходит до подсчёта капитальных и эксплуатационных затрат, энтузиазм резко убавляется.

А как распространение меток происходит? Через BGP/OSPF или статически устанавливаете? Или только локальное?

pokos> АТМ и коммутация на первом уровне. АТМ на магистрали сейчас уже не актуален ввиду маленькой скорости, а в локалке он никогда и не был актуален.

АТМ делает это в основном методом резервирования — он же ориентирован на создание виртуального канала. Можно еще поиграться CBR/VBR — это пожалуй и все. Тогда RSVP тоже такой же.

pokos> В общем, по этой теме можно написать целую статью.

Можно :D — я QoS для IP сетей занимался 3 года. На митинги IETF ездил, конференции разные. Завел знакомства с Герцогом Шаем, Ликсией Джанг, Бобом Квином :D, с кучей народу из киски. Но потом проект прикрыли :blink:

pokos> А Езернет щас шагает по странам и континентам, довольно успешно даже на магистралях с применением чего-либо типа Mac-In-Mac. Дело в том, что QoS клиента и QoS оператора никак не связаны, у оператора свои взгляды на бизнес, именно поэтому всякие DiffServ слабо применимы.

Это не просто DiffServ — это любой глобальный QoS имеет такие проблемы. Впрочем, MBone — хоть и не QoS, а multicast — имеет те же проблемы. Поэтому, сейчас в США идет вверх всякий софт по SLA/SLM.

pokos> Читсый Езернет прекрасно применяется в сетях с 20тыс. клиентов, правда до тех пор, пока не нужно сколько-нибудь реальное время. Как только оно становится нужным, затраты на планирование и администрирование сети возрастают на порядки.

Overprovisioning — вот ключевое слово. Затраты на QoS могут превысить затраты на планирование и администрирование очень легко. Поскольку его самого надо планировать и администрировать. Особенно это верно для ATM-RSVP — там без COPS или admission service просто никуда.

pokos> Что же касается настоящего QoS, то его на магистралях сейчас может обеспечить только SDH, причем в SDH понятие QoS имеет несколько иной смысл - это всего лишь время восстановления канала при аварии на сети. [»]

Это уже к надежности ближе, как я говорил.
 

pokos

аксакал

Mishka> Этот метод очень плохо масштабируется. При наличии пары устройств — хорошо, а потом растет линейно.
Ну, я и не говорю, что это панацея, но при линках только к свичам, как в Езернете, работает хорошо.

Mishka> Вот, перерыл IEEE сайт и таки нашёл. Гигабит, все-таки обычный CSMA/CD и размеры фремов даны такие:
Нащёт обычности поспорю, только буквари в памяти обновлю...

Mishka> .....так что говорить о полноценном QoS-е (с точки зрения real time intollerable applications не приходится.
Тут, конечно, есть масса вариантов перекраски, но результат именно такой.

Mishka> Покажите мне хоть один прибор, где очереди не применяются.
Дык, любой мультиплексор SDH.

Mishka> Потеря пакетов — это стандартная модель траффика. А вот время восстановления — это, ИМХО, уже к надежности (reliability) относится. Не надо все в кучу валить. Там математика, конечно, похожая, но всё-таки это разные вещи.
Оно, конечно, верно, только понимание QoS может быть несколько разным. В Езернете - это вероятность, а параметры надёжности имеют такую же природу. Для SDH - это время, и смысл говорить о вероятных потерях пакетов отсутствует, без аварий они отсутствуют в прнинципе.
Возвращаясь к напечатанному, нужно плясать от услуги, а клиент, у которого при просмотре любимой (и недешёвой!) порнухи раз в минуту херится изображение из-за потери пакетов, пошлёт такой сервис нах и купит DVD.

Mishka> Сколько приборов на линии? Два — типа точка-точка? Тогда и у эзера нет проблем.
Проблемы есть у оператора, который хочет такую убогую услугу выгодно продать.

Mishka> A иначе MPLS безполезен — какой смысл метить пакеты для ускоренной маршрутизации, если маршрут один?
Я не о том, что маршрут один, а о том, что MPLSу чрезвычайно полезно, когда маршрут проходит через минимальное кол-во коммутаторов.

Mishka> А как распространение меток происходит? Через BGP/OSPF или статически устанавливаете? Или только локальное?
А вот тут каждый оператор мутит в силу способностей своих инженеров. На мой взгляд, наиболее грамотно иметь на магистрали десяток MPLS узлов с BGP, OSPF вынести за границу магистрали, пускай по нему соседние районные узлы друг друга нюхают. А вообще, без конкретной задачи это всё бессмысленно мусолить.

Mishka> АТМ делает это в основном методом резервирования — он же ориентирован на создание виртуального канала. Можно еще поиграться CBR/VBR — это пожалуй и все. Тогда RSVP тоже такой же.
Дык, поэтому у АТМ наиболее подходящее к таким случаям качество из всех распространённых пакетных технологий. Усли уж АТМ дал тебе нужный CoS, можно спать спокойно.

Mishka> Это не просто DiffServ — это любой глобальный QoS имеет такие проблемы.
Эт тошна.

Mishka> Overprovisioning — вот ключевое слово. Затраты на QoS могут превысить затраты на планирование и администрирование очень легко.
Истинно так!

Mishka> Это уже к надежности ближе, как я говорил.
Ближе, конечно, но с комплексной точки зрения - неразрываная связь налицо.
 

Mishka

модератор
★★★
pokos> Дык, любой мультиплексор SDH.

Ага, а вторую часть фразы опустил. :P В этом случае возникает проблема QoS на самом мультиплексоре. Хорошо, если он мощный, а, если нет? Тут возникает та же проблема, что у shapping-а — что будет, если центральное устройство перегрузить? Правильно — потери пакетов не будет, но джитеринг появится только так. Значит мощь проца и routing fabric надо очень сильно overprovide. Что, опять-таки есть развитие экстенсивное.

pokos> Оно, конечно, верно, только понимание QoS может быть несколько разным.


Оно разное не только в технологиях, но даже у вендоров. Я в свое время был очень озадачен, как Cisco понимает QoS.

pokos> В Езернете - это вероятность, а параметры надёжности имеют такую же природу. Для SDH - это время, и смысл говорить о вероятных потерях пакетов отсутствует, без аварий они отсутствуют в прнинципе.

Если нет перегрузки мультиплексоров и других элементов.

pokos> Возвращаясь к напечатанному, нужно плясать от услуги, а клиент, у которого при просмотре любимой (и недешёвой!) порнухи раз в минуту херится изображение из-за потери пакетов, пошлёт такой сервис нах и купит DVD.

Так весь QoS возник из этого — когда не хочется тратить слишком много на перефирию, чтобы best effort работал, и, в тоже время, предоставлять услуги одним (за большие деньги) за счет других (которые платят меньше). Проблемы начинаются, когда эту границу не могут провести корректно — то ли от жадности, то ли от глупости.

pokos> Проблемы есть у оператора, который хочет такую убогую услугу выгодно продать.

Надо иметь хороший маркетинг. :P

pokos> Я не о том, что маршрут один, а о том, что MPLSу чрезвычайно полезно, когда маршрут проходит через минимальное кол-во коммутаторов.

Я это к тому, что минимальное кол-во коммутаторов отличается от единственного пути только тогда, когда хорошая связанность есть.

pokos> А вот тут каждый оператор мутит в силу способностей своих инженеров. На мой взгляд, наиболее грамотно иметь на магистрали десяток MPLS узлов с BGP, OSPF вынести за границу магистрали, пускай по нему соседние районные узлы друг друга нюхают. А вообще, без конкретной задачи это всё бессмысленно мусолить.

Подожди, а внутри — что всё ручками будет делаться? Алгоритм переключения в MPLS до тупого прост — метка фиксированного размера и является индексом в таблице. Проблемы начинаются, когда надо распознать поток, для которого входов в таблицы еще нет. Тут два (грубо) пути. Попытаться распознать и маршрутизировать стандартными путями, а по ним и добавить метку с маршрутом в таблицу, либо полагаться на глобальную информацию, которая приходит в качестве паразитной на протоколах маршрутизации (piggy backing). Дурдом начинается, если потоки коротко живущие — работа по разметке сделана, а поток кончился. Плюс надо всегда решать проблему, как сообщать о метках — downstrem или upstream методом. Понятно, что это выбирается один раз, но про это думать тоже надо.

Хотя моя родная компания предпочитает создавать MPLS маршруты руками для нашего intranet-а. :huh:

pokos> Дык, поэтому у АТМ наиболее подходящее к таким случаям качество из всех распространённых пакетных технологий. Усли уж АТМ дал тебе нужный CoS, можно спать спокойно.

У таких систем существенный недостаток — их можно переполнить и клиенты, на которых не хватило каналов тихонько стоят в сторонке. В то время как best effort — предоставляет хоть какие-то услуги всем.

Mishka>> Это уже к надежности ближе, как я говорил.
pokos> Ближе, конечно, но с комплексной точки зрения - неразрываная связь налицо. [»]

В интегрирование понятие QoS это, безусловно, включать надо. Поэтому, говоря по марксистко-ленински. QoS — в узком смысле слова — это софт, а в широком — это еще и надежность. :D
 

pokos

аксакал

Mishka> ....джитеринг появится только так.
Не появится. Что до потребных мощностей, то тут задача весьма примитивная, она решается простым многопортовым ОЗУ.

Mishka> Хотя моя родная компания предпочитает создавать MPLS маршруты руками для нашего intranet-а. :huh:
То-то и оно....

Mishka> У таких систем существенный недостаток — их можно переполнить и клиенты, на которых не хватило каналов тихонько стоят в сторонке. В то время как best effort — предоставляет хоть какие-то услуги всем.
С точностью до наоборот. В АТМ никто не мешает поставить минимальную скорость каждого канала так, чтобы все хоть как0то работали всегда.

 
1 2 3 4 5 6

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru