Без XL — это 256к маршрутов.
XL — это 1М. Но!!!
Этот 1М делится ресурсно на 512К по умолчанию для IPv4 и 256к для IPv6.
Есть процедура, которая меняет соотношение TCAM для IPv4/IPv6 — для 6500 платформы.
«Банальная» задача оптимизации таблицы BGP с целью нахождения оптимальной альтернативы, которая не совпадает с текущим маршрутом выбранным маршрутизатором согласно алгоритмов работы RFC по BGP.
Собираем метрики через альтернативные направления.
Меняем таблицу маршрутизации если текущий маршрут не оптимален.
Задача сугубо логическая.
Математики там — посчитать количество и среднее арифметическое времени задержки переноса пакетов. :-)
Ну и посчитать количественно мегабиты в секунду при рассчете перегрузки канала.
Ну и несколько патентов на это дело… ;-)
Иногда нецелесообразно писать сразу по оптимальной архитектуре.
На прототипе набиваются шишки, создаются и отрабатываются алгоритмы.
Затем — третья-пятая инкарнация алгоритмов переносится в новую архитектуру.
Обе архитектуры, которые я проектировал, работали.
Линейная — была сделана и отлажена за две недели и дорабатывалась еще полтора года.
Дискретная — писалась два месяца по уже известным алгоритмам. И еще месяц была в доводке.
Чувствуете разницу?
Из за простоты реализации получить нечто работающее и быстро, либо потратить ресурсы (и не получить прибыли, поскольку ничего не продали) за нечто абстрактное, что еще не обязательно будет работать…
Что-то не хватает одной еще варианта голосования:
Я архитектор. Считаю, что нужно оптимизировать код. Но вижу что это не является препятствием для новых фич.
Как архитектор и аналитик — я вижу проблемы производительности и чрезмерного потребления оперативной памяти.
Однако комплекс был спроектирован таким образом, что эти проблемы не являются критическими, по этому дальнейшая оптимизация отложена до лучших времен (наличие некоторого количества относительно свободных человеко-часов).
А критические проблемы были взяты в разработку.
Вот пара проблем:
первый вариант приложения (С++) с линейной логикой и обработкой одиночного задания в собственной нитке приводил к его зависанию из за взаимных блокировок и т.п. Нагрузка на процессор — 200-300% (относительно одного ядра) при исполнении 70-100 ниток (одновременных заданий).
Решение: приложение переписано по другой архитектуре с дискретным исполнением заданий.
три нитки для исполнения 200-500 заданий.
нагрузка на процессор — 70% в нитке обеспечивающий уровень обслуживания сети (будущая оптимизация — переписать на очереди и таймера; ожидается 4% нагрузки).
Второй вариант:
Прототип приложения написан на Perl. Ресурсов С++ не хватало для переписывания. Прототип обеспечивал функционирование production в течении полутора лет у ВСЕХ покупателей П/О.
Затем был переписан на С++. Нагрузка на процессор снизилась в 1000 раз (в частности процесс пересчета маршрутов снизил нагрузку с 40с на 10к маршрутов до менее 1с за 40к маршрутов).
Собственно наблюдается та-же тенденция.
Если оптимизация кода влияет на увеличение прибыли опосредованно — это второстепенная задача.
Если из за не оптимального кода мы не можем реализовать какой-то функционал (получить деньги за него) — это первостепенная задача.
В основном для летающего инструмента. :-)
там важен высокий ток разряда.
Однако Li-Pol элементы имеют уменьшенное (по сравнению с Li-Ion) количество циклов заряд/разряд и менее безопасны с точки зрения пожароопасности.
Наиболее распространены круглые элементы 18650.
Они используются как для составления батарей ноут/нет-буков, так и в различных переносных устройствах.
Ручных и велосипедных фонариках, например.
Так, популярные сейчас повербанки также построены на элементах 18650, причем есть варианты на съемных элементах.
Ну и самое интересное в том, что батареи машин Tesla Motors также построена на элементах 18650.
Учитывая желание Тесла построить свой завод по производству Li-Ion элементов, который удвоит мировое производство, можно ожидать какого-то (сначала ценового) прорыва в элементах.
Прошу Вас написать про LSD (Low self discharge) вариант Ni-MH батарей.
В этом случае, остаточная емкость составляет около 70% через 5 лет хранения при допустимых 1800 цикров заряд/разряд (привожу в пример наиболее прогрессивную модель среди прочих на рынке, которой с удовольствием пользуюсь сам).
К минусам LSD относятся более дорогое производство, меньшая удельная емкость (1900 mAH для АА против 2700 у не-LSD).
Но положительные потребительские качества перекрывают все описанные минусы.
А также про Ni-Cd:
Ni-Cd элементы обладают одним неоспоримым преимуществом перед прочими батареями — они не подвержены разрушению при снижении напряжения до нуля. Наоборот — рекомендованным режимом хранения является хранение с замкнутыми контактами. :-)
Эта особенность является неоспоримым преимуществом для использования в электроприборах, допускающих полный разряд.
Например некоторые медицинские приборы и банальные светодиодные фонарики (на солнечных батареях для ночной подсветки дорожек).
Спасибо за инфу.
Вы упомянули Cisco Cloud Services Router 1000V? Который дается как бесплатная триалка на 60 дней?
В сторону Vyatta Core могу сказать только два плюса:
виртуалки 512М хватает чтобы прожевать полную таблицу BGP.
А для лабы — там 256М и много-много виртуалок под топологии разной сложности.
PS Я работаю в проекте, который является «добавочными мозгами» для протокола BGP и на бесплатных рутерах мы крутим нашу лабу с полной таблицей — чтобы не грузить Route Processor кучей BGP сессий, которые рвутся когда нам будет удобно.
Из «прикольных» адресов в IPv6 применяется и такое:
2001:db8:dead:beef::
Поскольку не у всех есть Циски, то приведу бюджетный вариант для Vyatta. У нас построена целая лаба для маршрутизации на базе этого бесплатного решения.
Привожу «выжимку» для IPv6, остальное можно додумать и дочитать через хелп:
set interfaces ethernet eth1 address '2001:db8:1:1::1/64'
set protocols bgp 65550 address-family ipv6-unicast network '2001:db8:1:2::/64'
set protocols bgp 65550 neighbor 2001:db8:1:1::2 address-family 'ipv6-unicast'
set protocols bgp 65550 neighbor 2001:db8:1:1::2 remote-as '65550'
set protocols bgp 65550 neighbor 2001:db8:1:1::2 'route-reflector-client'
Отдельно хочу отметить вот это:
::ffff:xx.xx.xx.xx IPv4, отображённый на IPv6 Для хостов, не поддерживающих IPv6
Это не совсем корректно.
Эта форма записи позволяет приложению использовать только один сокет tcp/udp для обработки одновременно и IPv4 и IPv6 соединений.
Вместо того, чтобы открывать раздельно сокеты под IPv4 и IPv6, приложение открывает сокет IPv6, делает «bind ::».
Входящие IPv4 соединения могут быть обработаны через IPv6 структуры с сохранением смыслового значения.
При необходимости установить исходящее соединение, банально "::ffff:" + IP передается для заполнения sockaddr_in6 и подается в connect.
Этот диапазон как раз и нужен хостам, ПОДДЕРЖИВАЮЩИМ IPv6, чтобы упростить переход под работу одновременно с IPv4 и IPv6 соединениями без удваивания кода приложения для работы с сокетами.
XL — это 1М. Но!!!
Этот 1М делится ресурсно на 512К по умолчанию для IPv4 и 256к для IPv6.
Есть процедура, которая меняет соотношение TCAM для IPv4/IPv6 — для 6500 платформы.
Результат работы процедуры пока не ясен.
Собираем метрики через альтернативные направления.
Меняем таблицу маршрутизации если текущий маршрут не оптимален.
Задача сугубо логическая.
Математики там — посчитать количество и среднее арифметическое времени задержки переноса пакетов. :-)
Ну и посчитать количественно мегабиты в секунду при рассчете перегрузки канала.
Ну и несколько патентов на это дело… ;-)
На прототипе набиваются шишки, создаются и отрабатываются алгоритмы.
Затем — третья-пятая инкарнация алгоритмов переносится в новую архитектуру.
Обе архитектуры, которые я проектировал, работали.
Линейная — была сделана и отлажена за две недели и дорабатывалась еще полтора года.
Дискретная — писалась два месяца по уже известным алгоритмам. И еще месяц была в доводке.
Чувствуете разницу?
Из за простоты реализации получить нечто работающее и быстро, либо потратить ресурсы (и не получить прибыли, поскольку ничего не продали) за нечто абстрактное, что еще не обязательно будет работать…
Я архитектор. Считаю, что нужно оптимизировать код. Но вижу что это не является препятствием для новых фич.
Как архитектор и аналитик — я вижу проблемы производительности и чрезмерного потребления оперативной памяти.
Однако комплекс был спроектирован таким образом, что эти проблемы не являются критическими, по этому дальнейшая оптимизация отложена до лучших времен (наличие некоторого количества относительно свободных человеко-часов).
А критические проблемы были взяты в разработку.
Вот пара проблем:
первый вариант приложения (С++) с линейной логикой и обработкой одиночного задания в собственной нитке приводил к его зависанию из за взаимных блокировок и т.п. Нагрузка на процессор — 200-300% (относительно одного ядра) при исполнении 70-100 ниток (одновременных заданий).
Решение: приложение переписано по другой архитектуре с дискретным исполнением заданий.
три нитки для исполнения 200-500 заданий.
нагрузка на процессор — 70% в нитке обеспечивающий уровень обслуживания сети (будущая оптимизация — переписать на очереди и таймера; ожидается 4% нагрузки).
Второй вариант:
Прототип приложения написан на Perl. Ресурсов С++ не хватало для переписывания. Прототип обеспечивал функционирование production в течении полутора лет у ВСЕХ покупателей П/О.
Затем был переписан на С++. Нагрузка на процессор снизилась в 1000 раз (в частности процесс пересчета маршрутов снизил нагрузку с 40с на 10к маршрутов до менее 1с за 40к маршрутов).
Собственно наблюдается та-же тенденция.
Если оптимизация кода влияет на увеличение прибыли опосредованно — это второстепенная задача.
Если из за не оптимального кода мы не можем реализовать какой-то функционал (получить деньги за него) — это первостепенная задача.
Один из комментариев к видео:
Эра
70% через год; 1000 циклов
Eneloop
70% через 5 лет, 2100 циклов (1800 — третье поколение; 2100 — четвертое «Panasonic Eneloop»).
Те показатели, которые выдает Эра, характерны либо для Eneloop первого поколения, либо для Eneloop Pro — с более высоким допустимым током разряда.
PS: Я не агитирую — привожу факты из публичных источников:
Эра
Eneloop
там важен высокий ток разряда.
Однако Li-Pol элементы имеют уменьшенное (по сравнению с Li-Ion) количество циклов заряд/разряд и менее безопасны с точки зрения пожароопасности.
Они используются как для составления батарей ноут/нет-буков, так и в различных переносных устройствах.
Ручных и велосипедных фонариках, например.
Так, популярные сейчас повербанки также построены на элементах 18650, причем есть варианты на съемных элементах.
Ну и самое интересное в том, что батареи машин Tesla Motors также построена на элементах 18650.
Учитывая желание Тесла построить свой завод по производству Li-Ion элементов, который удвоит мировое производство, можно ожидать какого-то (сначала ценового) прорыва в элементах.
В этом случае, остаточная емкость составляет около 70% через 5 лет хранения при допустимых 1800 цикров заряд/разряд (привожу в пример наиболее прогрессивную модель среди прочих на рынке, которой с удовольствием пользуюсь сам).
К минусам LSD относятся более дорогое производство, меньшая удельная емкость (1900 mAH для АА против 2700 у не-LSD).
Но положительные потребительские качества перекрывают все описанные минусы.
А также про Ni-Cd:
Ni-Cd элементы обладают одним неоспоримым преимуществом перед прочими батареями — они не подвержены разрушению при снижении напряжения до нуля. Наоборот — рекомендованным режимом хранения является хранение с замкнутыми контактами. :-)
Эта особенность является неоспоримым преимуществом для использования в электроприборах, допускающих полный разряд.
Например некоторые медицинские приборы и банальные светодиодные фонарики (на солнечных батареях для ночной подсветки дорожек).
Вы упомянули Cisco Cloud Services Router 1000V? Который дается как бесплатная триалка на 60 дней?
В сторону Vyatta Core могу сказать только два плюса:
виртуалки 512М хватает чтобы прожевать полную таблицу BGP.
А для лабы — там 256М и много-много виртуалок под топологии разной сложности.
PS Я работаю в проекте, который является «добавочными мозгами» для протокола BGP и на бесплатных рутерах мы крутим нашу лабу с полной таблицей — чтобы не грузить Route Processor кучей BGP сессий, которые рвутся когда нам будет удобно.
2001:db8:dead:beef::
Поскольку не у всех есть Циски, то приведу бюджетный вариант для Vyatta. У нас построена целая лаба для маршрутизации на базе этого бесплатного решения.
Привожу «выжимку» для IPv6, остальное можно додумать и дочитать через хелп:
set interfaces ethernet eth1 address '2001:db8:1:1::1/64'
set protocols bgp 65550 address-family ipv6-unicast network '2001:db8:1:2::/64'
set protocols bgp 65550 neighbor 2001:db8:1:1::2 address-family 'ipv6-unicast'
set protocols bgp 65550 neighbor 2001:db8:1:1::2 remote-as '65550'
set protocols bgp 65550 neighbor 2001:db8:1:1::2 'route-reflector-client'
Отдельно хочу отметить вот это:
Это не совсем корректно.
Эта форма записи позволяет приложению использовать только один сокет tcp/udp для обработки одновременно и IPv4 и IPv6 соединений.
Вместо того, чтобы открывать раздельно сокеты под IPv4 и IPv6, приложение открывает сокет IPv6, делает «bind ::».
Входящие IPv4 соединения могут быть обработаны через IPv6 структуры с сохранением смыслового значения.
При необходимости установить исходящее соединение, банально "::ffff:" + IP передается для заполнения sockaddr_in6 и подается в connect.
Этот диапазон как раз и нужен хостам, ПОДДЕРЖИВАЮЩИМ IPv6, чтобы упростить переход под работу одновременно с IPv4 и IPv6 соединениями без удваивания кода приложения для работы с сокетами.
Однако, если вернуться к теме поста — мультипликация вышла на новый уровень.
Вспоминайте спокойной ночи малыши и пластилиновую ворону :-)
www.sciencemag.org/content/341/6144/331
it.tut.by/359317
ЦУП получал с задержкой? Или это весь мир получал с 60с задержкой?
PS: попервой запутался во фразе — и подумал что ЦУП получает с задержкой…
Мне приходится работать через SSH, и графику тягать не очень приятно.
PS Подключить rpmforge к CentOS, затем yum install tig
Применялся в том числе на заре линукса для обертывания длинных имен в FAT/ISO9660.