NiTr0

Т.е. - если нужно, скажем, осуществление снятия денег и в ядре, и в вебке - и в ядре код дублируется,и в вебке код дублируется? А если вебка на другом языке писана - что, все библиотеки перепиливать? Ужс... Ядро - это ядро, оно осуществляет все операции с БД и т.п. Вебка/софтина/CLI/etc - отдельная сущность, в общем случае - не обязательно из "доверительной зоны" кода (банально для секюрности системы, особенно если она является модулем для некой CMS), которая должна общаться с ядром, а не с БД напрямую. В такой схеме и вебку сменить элементарно (у кого-то, к примеру, страничка на джумле

К слову, существуют в природе биллинговые системы, у которых ядро и веб-морда не склеены в единый неделимый комок, а общаются между собой по какому-то из вариантов RPC (XMLRPC к примеру)?

Это примерная статистика. Ибо у нас пппое юзается для доступа в инет, а локалка - благодаря раздаваемым по дхцп маршрутам, как-то кол-во проблем можем сравнить. Зачем авторизировать как-либо при однозначной идентификации абонента по порту? Повторюсь, выявление ошибок сотрудников - это задача не авторизации, а последующего анализа логов и генерации уведомлений при подозрительных ситуациях (к примеру, миграция мака с одного порта на другой). И потом уже их рассматривать - если мак на постоянно поселился на другом порту и перед этим на узле присутствовали сотрудники, давать по рукам за нес

Однако 5 проблем, или 50 - есть разница же? В общем-то отменяет. Т.к. известно, в какой порт какой абонент включен - накой еще что-то проверять? Ну а технологические проверки по косвенным признакам (миграция мака и т.п.), для выявления и наказания виновника ошибочного включения (прощелкавшего клювом диспетчера либо же монтажана, самовольно поигравшегося кабелями), проходят прозрачно для абона.

Неужели ни у кого из абонов не выскакивало волшебной 720-й ошибки, которая возникает от чего удобно (один из примеров - прерванная установка дров на сетевуху из-за подвисания процесса), и в общем случае решается только переустановкой оси? А пофиг, что не умеют. Один клиент за аткой точкой прекрасно будет работать. Без необходимости поднимать туннель и т.п. Однако проблем с туннелями по причине проблем на стороне абонента намного больше, чем проблем с DHCP - факт. Основной "практический опыт" для вас будет заключаться в перенастройке оборудования клиентов, приучиванию их к не

А накой геморрой везде наживать-то? Вон, по вафле больше пары мегабит абонам реально нельзя раздавать - так что, по всей сети ставить такие же тарифы? Не стоит лепить костыли там, где и без них прекрасно работает. Портал авторизации, авторизация средствами самих точек доступа (да-да, многие умеют радиус-авторизацию), и т.п., ну или же туннели только на отдельных участках (т.е. только на вафлях). К слову, туннели никоим образом не должны отменять какую-либо авторизацию на самой AP. Иначе получается рай для пионернетов, перепродающих тот же укртелекомовский инет через вашу AP, либо (если

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

Скрипт мониторинга радиуса и рестарта в помощь. Сделали в свое время, когда rlm_perl был нестабилен еще. В последние более чем год не срабатывал ни разу, кроме как при потере БД (оно-то и понятно, база отвалилась - радиус не авторизирует). Не защищенный от чего??? Причем биллинг к насу? rlm_perl в помощь. Видно же, тазик ваш не справляется, LA более 10-15 - это уже катастрофа, а у вас до 50 (!) доходит. Апгрейдить железо либо переключаться на rlm_perl. У нас цифры в несколько раз больше, сервер биллинга и сервер БД едва на 10% в ЧНН загружен. Бред (с) 1) Пользуй

Дык в том-то и дело, что такая система мало кому нужна. Завязанная на куче проприетарщины типа визио, с большим, но далеко не всегда нужным функционалом... Мы свою систему потихоньку строгаем, в виде эдакого учебно-промышленного проекта, на котором заодно обучаем одного студента правильному кодингу - пусть это дольше и времени занимает больше в итоге, чем написание лично, но в итоге есть все шансы помимо системы получить еще и человека, который будет ее обслуживать и допиливать, причем делать это качественно и с соблюдением стандартов, в отличие от фрилансеров. В общем-то, в первом приближени

Статистика примерно следующая: 1-1.5 мбита в ЧНН на онлайн абона, онлайн - 50% из оплативших, т.е. ~0.5-0.7 мбит на рыло. Если вводить резко новые тарифы - может быть 1-2 месяца нештатного потребления трафика, по причине "ого, анлим, надо весь интернет выкачать". Но по мере засирания винтов у хомячков - трафик вернется к тем же ~0.5-0.7 мбит на рыло. Для минимизации пикового потребления можно вводить тарифы с дневной/ночной скоростью, и т.п., хотя актуальны будут только в первое время.

Ну в педивикии всяческие к.т.н. и прочие любители сферических коней в вакууме часто любят сравнивать яйца с легкими... Подумайте на досуге, почему AMD перешла от шустрой EV6 (64бит, 400 МГц) на медленный гипертранспорт (HT 1.0 - 16бит, 800 МГц) в свое время, и почему это не принесло сколь-либо заметной просадки производительности. А еще подумайте, что было бы, если бы инженеры AMD надумали в каком-то из офисных процов вынести северный мост в отдельный кристалл, соединенный по HT с ядрами. Мсье мастер включать фантазию на ходу, да...

Какой такой весомый? Подросла теоретическая пропускная способность за счет дуплексности (причем - никак не на порядок, как кто-то утверждал), и при этом в 2 раза выросла латентность... Тут скорее наличие L3 кеша сыграло роль, а не замена одного тормоза на более другой.

Ура, до вас дошло. Поделите 2.93 на 2 (ибо тактовая частота - 2.93 ГГц, частота обмена данными по шине - в 2 раза больше ибо DDR), и получите 1.47 Гтранзакций/сек в каждую из сторон. Чкча не читатель, чукча писатель? Интел вообще упразднила FSB (Front Side Bus, шину между мостом с контроллером памяти, и ядрами ЦП). И сделала QPI - аналог АМДшного гипертранспорта - исключительно для связи проца с периферией. И высокая скорость от этой шины не требовалась - по ней какбы никто с памятью обмениваться не собирался. Ну и мимоходом эту же шину влепила между ядрами и северным мостом в свер

Итак, читаем вместе, по буквам: Потому еще раз задаю вам вопрос: вы L3 форвардинг пакета, с прохождением его по всем цепочкам, от тупого ретрансмита отличить можете, или нет? Что же, разжую как для детского сада, если вы не поняли глупость вашего вопроса. QPB (FSB) - 64 бита, 1 трансфер за такт, 1.33 GT/s для указанной корки QPI - 40 бит, 1 трансфер за 4 такта (ибо атомарный блок данных - flow control unit - 80 бит, шина - 20 бит), частота обмена по шине - 2.93x2 ГГц, т.е. 5.97GT/s на физическом уровне, но 1.47GT/s на "канальном" уровне. Огромная разница с 1.33GT/s, да...

Чукча не читатель, чукча писатель, да? Форвардинг от тупого ретрансмита отличить можете, не? Или для к.т.н. любая передача пакетов - форвардинг? И опять же, где вы там нашли хоть одно упоминание о обмене через оба интерфейса? Повторяю еще раз вопрос: что вам даст знание кол-ва передач данных в секунду, если минимальный размер передаваемых данных - 64 бита независимо от ширины шины CPU-NB? Операция заполнения строки кеша, как и операция записи данных в модуль памяти - атомарная, невозможно записать половину строки кеша, или половину ячеек памяти по данному адресу.

За китайцев как по мне цена несколько завышена... С акорпом не пытались связываться по поводу поставок WR-N150/WR-N300?

Да показываю уже 5-й раз: http://shader.kaist....nchmark/i3.html Мсье к.т.н. имеет проблемы с пониманием ангельского, или намеренно приводит вместо форвардинга голую синтетику "прими-передай"? Настойчиво повторяю просьбу показать софтроутер на 62 Мппс (да-да, 32 гбита пакетами по 64 байта это именно 62 Мппс) на i3-550. Бред. Пропускная способность вполне определенной шины однозначно зависит от частоты обмена данными по ней (те самые GT/s). Латентность, батенька, латентность, которая у clarkdale в 2 раза выше, чем у корки. Ну и накой вам писькомерки в GT/s, которые не им

Латентность памяти - "синтетическая величина", ни на что не влияющая Бред (с). И покажите мне 32 гбита форвардинга на i3-550 пакетами по 64 байта... Даташиты и спеки к.т.н. не читают принципиально, да При FSB 333 (1333) МГц имеем пропускную способность 10666 МБ/с (симплекс). Для QPI 2.96 ГГц (5.93 GT/s) при 16 битах имеем 11866 МБ/с в каждую из сторон. Латентность же памяти у i3 почти в 2 раза больше, чем у старого Core2, кеш - никоим образом не завязан на ИКП, т.е. задержки на получение данных нового пакета ядрами будут в 2 раза больше чем у корки...

Факты я вам показал. В виде тестов латентности подсистемы памяти и т.д. То, что вы ссылки не читаете - ваше личное горе. А при чем тут энергопотребление? На словах? Ну-ну... Да и то, что корка на 200 кппс загибается - бред(с). 2-головый феном к примеру роутит более гигабита трафла в сумме при среднем размере пакета 800-900 байт, при загрузке ядер % до 30 максимум... И это - с солидным кол-вом правил иптейблса. Хотя да, если юзать какашные сетевухи - в 100 кппс упереться легко.

Сравнительного теста нет? Бред (с) http://www.fcenter.ru/forprint.shtml?online/articles/hardware/processors/27965 - посмотрите, обратите внимание на латентность памяти (именно она играет роль для роутеров, а не пропускная способность). И там же сравнение с lynnfield с полноценным ИКП, и с LGA775 платформой. А вообще и в LGA775 контроллер PCI-E на том же кристалле, что и контроллер памяти. Ну и еще дровишки о "высокопроизводительной" QPI. К слову, ее пропускная способность на номинальных 3.2ГГц в одну из сторон такая же, как и ПСП стандартной QPB корок на частоте 400(1600) МГц (разве ч

man sar

В том-то и дело, что у clarkdale он не встроенный. Он физически лежит на одной подложке, но не интегрирован с ядрами - т.е. ядра с ним общаются по все той же FSB. Со всеми вытекающими. Ну-ну. Clarkdale собссно по большому от core2 отличается только тем, что северный мост чуть ближе геометрически к ядрам. Все. Ибо узкое место в виде FSB что там, что там присутствует. Разве что в одном случае длинна линий FSB порядка 10 см, в другом случае - порядка 10 мм. И clarkdale - шаг назад по производительности на гигагерц, хотя и частоты выше, и ядро практически то же что и у nehalem (различия мини

Нет, разница есть. clarkdale (i3-xxx и некоторые i5) по сути есть не что иное как совмещенные на одной подложке чуток допиленное ядро core2 и северный мост с контроллером памяти и графикой (те самые 2 кристалла). С соответственно печальной производительностью, которая лишь немногим выше старого wolfdale. Nehalem/lynnfield/bloomfield (старшие i5, i7-xxx) - как раз монолитный 45нм кристалл с набортным контроллером памяти. 2-е поколение (LGA1155/2011) - уже все монолитные.

С т.з. абонентов - да, понятно, неприятно, возмущаться надо. А вот с т.з. провов, как ни цинично это звучит - чем больше таких "интернетов за 2600 грн" по регионам будет, тем выгоднее будет именно мелким провам работать. Ибо несколько случаев кидалова, хорошо освещенных в желтой прессе (лучше - национального масштаба), будут весьма весомым ударом по имиджу, тщательно поднимаемому маркетологами и прочими пиарастами. Т.е. если у кого-то из операторов/провов в регионе есть знакомые, попавшие под кидок - сделайте им доброе дело, приведите к ним журналиста, и человеку приятно, и вам профит

Дофига ИМХО. Для 16 кппс-то... На интелах гигабитных 945 феном более 1к сессий (пппое) лопатит и шейпит, причем шейпит как мир, так и украину, раздельно либо вместе (в зависимости от ТП), с коннтраком, при трафике порядка 1 гбита. Хотя да, не микротик и без ната, но все же...