Бьюсь головой об отладчик уже несколько месяцев ). Не могу найти ошибку. В связи с чем захотелось узнать: а есть ли эта ошибка вообще? может быть никакой ошибки нет и всё работает как и должно. Попробую максимально коротко обьяснить ситуацию: Есть промышленная ОС ЖРВ. Есть чип i82551 (ER и IT). Нужно написать железобетонно надёжный и сверскоростной драйвер (т.к. на сеть нагрузка большая, а ресурсов не много). Драйвер был написан. Всё как бы зашибись работает, но только, если из двух чипов висящих на PCI работает только 1 чип. (в качестве платформы выступает ETX модуль Advantech SOM4455 и несущая плата с этими самыми злосчастными эзернетами) А если нагрузить ещё и третий чип, то ошибки начинают сыпаться просто на глазах. Тестирующая прога нагружает чипы вот так: OUTTER_CYC = 20 INNER_CYC = 10 for( j = 0; j < OUTTER_CYC; j++ ) { for( i = 0; i < INNER_CYC; i++ ) { Посылка по первому интерфейсу 1492 байта. Посылка по второму интерфуйсу 1492 байта. } Ждём 2 микросекунды. } Это в задаче, которая запускается через каждые 4 микросекунды. С другой стороны стоит такая же железяка с таким же софтом, который принимает эту пачку пакетов и отсылает такуюже. Ну и всё это с проверкой на потери и прочей тестовой фигнёй. Короче две железяки, у каждой 2 эзернета и они друг в друга фигачат пачками по 10 пакетов. с вышеописанной скоростью. Беда в том, что если у обоих сторон задействовать только 1 чип, то всё ок. они так могут работать до посинения. А вот если задействованы оба эзернета с обоих сторон, то картина следующая: 1) несколько раз за 10 часов происходят ошибки типа Overrun 2) 1 - 2 раза за сутки происходят ошибки контрольной суммы (у чипа) 3) с той же частотой иногда просто исчезают фреймы. т.е. потерю пакета видно на верхнем уровне, однако куда он исчез - никому неизвестно. Всё это совершенно недопустимо для нашей системы. =\\\ Но если снизить пиковую нагрузку в 2 раза (т.е. INNER_CYC сделать 5 а не 10) то становится гораздо легче (две недели вообще без сбоев). В итоге я какие только вивисекции с драйвером не выделывал - лучше не становится. И я постепенно начинаю думать, что всё нормально и просто я реально наступаю на пропускную способность эзернетов или PCI (хотя я следил за регистрами ошибок PCI-я и там вроде было всё ок.). И лучше уже быть и не может. Однако по фирме ходят легенды о неком мифическом чипе i82546GB, который якобы под такой нагрузкой работал шикарно и без всяких ошибок. Соответственно начальство говорит "Ничего не знаем. Другой чип работал, значит и этот тоже должен", а мне ответить нечего. В общем такая вот душещипательная история. Т.к. особо крутых спецов по эзернетам на фирме нет, то обращаюсь за вопросом сюда. Если нужна какая-то информация по драйверу или железу - спрашивайте.
эээ а 82546 развер не гигабитэзернет ???? (в то время как 551 вроде как фастэзернет) здеся ктото тестил 546 http://www.archivum.info/port-i386@netbsd.org/2005-05/msg00032.html переходи на PCI-X =)
Интересная проблемка, есть о чем мозг поломать Попробую порассуждать так, как я могу и как поступаю сам в подобных безобразиях. Собственно неясно о какой скорости речь, скокаУровневая система, протокол до самого верха сколько слоёв...? 10 пакетов это я-ля ТСР, а-ля сокеты типа юзаются? А я и дожидаться не буду ответа, а что бы я сделал - так это воспользовался принципом разчленяй и властвуй, т.е. тесть кусками, модулями! Тесть покусочно, раз такая байда, а лишь потом сшивай куски, уровни, протоколы в общую "дорожку данных" вплоть до уровня приложения. Зачем же все кучей проверать, коль уж ясно, что это уже программно-аппаратный комплекс... да еще + линия связи, собственно. Помехи, к стати тоже никто не отменяет... Я это прежде всего к тому, что факторов много на самом деле может быть и один рецепт и точный тут быть не может, да и наивно это будет, несерьезно. НУ вот варианты расчленения и проверок: 1 некий драйверный слой (самый нижний) в максимально быстром цикле пулит проверочный блок и сам его принимает, т.к. пара Tx на разъёме RJ-45 заводится заглушечкой на собственный Rx (обязательна статистика +проверка на устройчивость и отсутствие "забития", потери НЕДОПУСТИМЫ); 1.1 почти тоже но, на одном борту, т.е. RJ-45 <-> RJ-45 двух контроллеров юзаются 1.2 я бы зацепил 2 прибора двумя точка-точка пачкордами и прогнал бы по максимуму Далее без стабильных, устойчивых результатах двигаться безсмысленно и протоколы более верхнего уровня лишь усубят картину... Что это дает? Выявляются все аппратные проблемы и PCI конфликты чипов на шине и буфера RX, TX и IRQ чипов, их потеря и их поведение и узкие места + линии связи... к стати если предполагается линия(кабель) неслабой длины + помехи, наводки на объекте установки, то тут же и надо прогон делать. Т.е. ложить бухту, скажем 100м кабеля SFTP и через неё гнать пакеты. Возможно тут же и хоть какая нибудь проверка на сбои от помех, например импульсных бытовых. Можно внутрь бухты положить дроссель с разомкнутым сердечником и по ней "долбится" помеха типа искра. Простейший источник искры коллекторный мотор со щетками(они всегда искрят) конденасторов тока там не должно быть ни снаружи ни внутри (вполне может подойти движочек от детской игрушки). Ну и уровень напряжения (регулируемый от БП) будет определять и обороты двигуна и период искры и амплитуду искры... Конечно это может быть не совсем то что на объекте творится, но приналичии соответствующего парка радиоихмерительной аппаратуры у железячников + смекалка и опыт, можно создать аналог даже на таком смешном полевом стенде! Это лучше чем ничего, это лучше чем корячится на объекте или позориться перед серьёзным заказчиком при серьёзном заказе и бабосах. Ну если уж тут все вылизано или будет достигнуто, тогда пожалуй я бы поочередно добавлял бы протокольные слои + послойные логи и сверка! К стати это весьма полезно оставить, т.е. ВМОНТИРОВАТЬ в виде технологического тестировочного сервиса в успешную реализацию изделия. Соответствующий код, функция, пароль перехода в режим... неплохо и фоновая проверка на живом потоке. Необязательно это давать заказчику и освещать всем. Это надо тебе в первую очередь, а то загоняют по командировкам на объект пока не сделаешь, как надо, а все ведь идеально хоца всем особенно нАЧаЛнЫКаМ!
Тему, пожалуй, нужно перенести в NETWORKS или пожалуй более она соответствует ELECTRONICS раделу. Имхо.
dag да. 82546 это гигабит, но т.к. у нас обычный PCI, то и гоняли мы его как 100мегабитный. ) к сожалению вопрос выбора платформы решался без меня, по этому мне приходится иметь интимные отношения с тем, что есть. VaStaNi тестовый протокол находится аккурат над драйвером. Фактически его можно было встроить прямо в драйвер, но это мне показалось не очень удобным. вероятно я всёже перенесу его в драйвер. на счёт отделения драйвера от системы, то тут есть пара моментов: 1) по заверениям руководства драйвер 82546 чипа работал на ура именно под этой версией оси, и вроде как это значит, что всякие там менеджеры задач узким местом не являются 2) к сжалению ОС рукописная и вынесение драйвера в одну из коммерческих осей для тестирования будет равносильно переписыванию драйвера почти совсем ) по поводу линии связи: провода короткие (30см). Вообще такого рода связь нужно делать внутри кроссплаты, но вот почему-то такой конструктив ещё только в разработке. По этому приходится работать через кабели. на счёт помех и качества плат: приходил сторонний инженеринг, сморел на выходные каскады эзернетов и сказал что всё сделано в точечности наперекор рекомендациям интела по разводке их эзернетов, но этот вариант брать за основу не хочется т.к. новую ревизию платы делать - 3 месяца, а их нету)) Да и потом это никак не обьясняет появления Оверранов. замкнуть сам на себя чип я пробовал. работает отлично. почему-то мне в голову не пришло замкнуть на себя оба чипа и напряч их. =\ надо этим занятся __ мне очень не нравятся способности PCIа к самодиагностике. те биты ошибок, которые можно вытащить из BAR эзернета - говорят что всё ок. А регистр статистики самого чипа при этом говорит, что ему нехватат PCIя. хочу поискать в мануале на северный мост способы получения более развёрнутой статистики по состоянию PCI, хотя врятли там что-то такое есть.
Странно это. Вообщее на 100МБит\с PCI хватает выши крыши, другое дело неравномерность работы. Overrun ошибка переполнения буфера. 16Кб(16384) буфер на получения данных. Отпровляем мы 14920, еще один и будет переполнение. Значит проблема на приеме. Интел пишет две причины софт не увеличил указатель на следующий буфер либы PCI медленный. Вот это и проверять. Либы увеличить порог пола FIFO что-бы раньше отпровлял прерывание либо проверять драйвер на наличие возможности исчерпания его временных буферов. Надо понять на каком буфере(уровне) происходит сбой. Это мало что дает. Надо эксперементировать с настройкой прерываний на карточке.
Ага, только на 551 всё упёрлось похоже в сам чипак, а на 546 уперается в PCI ку. Сдаётся мне что 546 будет значительно шустрее. Посмотри по даташитам http://download.intel.com/design/network/datashts/82546GB_ds.pdf http://download.intel.com/design/network/datashts/82551it.pdf http://download.intel.com/design/network/datashts/82551ER_DS.pdf попробуй разогнать 551
dag Еще руководство для разработчиков. http://download.intel.com/design/network/manuals/8255X_OpenSDM.pdf http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf
ишшо раз сначала а где видно что юзаются прерывания? При таких делах: + 82551 получается Вам хватает именно как бы ВПРИТЫК!??? Я имею ввиду его аппаратно-ресурсный потенциал? Или Вам хватает именно работа в 2 "ствола" чипов 82551??? Ао лубому тут без грамотного тайминга, который базируется на механизмах прерываний в которых бегом выгрузка-загрузка данных буферов должна быть вряд ли получится и БЕЗ потерь и стабильно и вне некоторого разгула +- многозадачности... обойтись. А я вижу, что вижу просто циклы... как там готов неготов клисталл не вижу т.е. просто и втупую бомбится буфер и все и типа втупую какието 2 и 4 мкс! Это жестко, но кристалл не обязан быть готов по их истечении... Так не делается. С контроллерами надо играться по ИХ правилам и всячески ИХ убдажать иначе ОНИ не отвечают взаимностью Уж как понимаю-вижу так и воспринимаю-оцениваю ситуацию. Теперь: а что ни исходников ни результатов того супер-пупер варианта НЕТ? НЕ дают? Тебя что экзаменуют в экстремельных ситуациях? Сдается это не ты чипы проверяешь, а тебя проверяют - настолько ли он АС, чтобы из говна(82551) "НАМ конфетку заколбасить", да еще на "0" опираясь и туман...? ) Как это "работал", а ты догадайся как. Так получается? Ище. 82546 наверняка буфера больше имеет, потому по любому выигрыш будет и отсутсвие потерь и оверранов. Там есть куда писать, есть некое времячко даже опоздать с вычиткой принятого! Тебе это чтото подсказывает быть может уже? ни в коем разе нельзя инородное в отладках потодного рода юзать. Только родная среда! Там искомая правда зарыта, только родной расклад временных диаграмм, таймингов, waitИНГОВ! Надо чтобы проявилось СЛАБОЕ звено, надо вымучать его, заставить проявиться стать более заметным, устойчивым и тогда... хватать энто дело "за хвост и наматывать на руку" дабы... это что "плата - плата" на расстоянии 30см в шкафу будут через Eternet соединяться? НАфига такой изврат???? Если нужно и скорость и дуплекс и помехозащита и пр... есть же ОПТОВОЛОКНО!? Тады передавай "пламенный привет" своим железячникам! Бесперспективный отстой и прошлый век, изделие обречено на мнОгие проблемы, сегодня 21 век - век ОПТИКИ и цифры! не трать время зря! Тут КАТЕГОРИЧЕСКИ не рекомендую искать - ЛОЖНЫЙ СЛЕД.
dag Pavia мануалы это конечно хорошо, но вот только я их уже наизусть знаю. ) легче от этого не становится. VaStaNi я может не так выразился немного написав этот цикл ). это верхний уровень. Под ним естественно TX драйвера, который проверяет готова ли CU машина. Если готова, то шлём, если не готова, то ставим пакет в очередь. далее по прерыванию: если CU выполнил комманду и в текущем TXD есть бит OK, то мы подсовываем следующий дескриптор и пинаем машину. ) как ты мог подумать, что я пихаю в бедный чип подряд пакеты не проверив готов ли он? )) я всётаки не на столько нуб. =\ всё есть. я запускал, проверял, действительно работает ок. к сожалению мои железячники являются по совместительству ещё и начальством, которое "всегда право". так что у меня вариант или заставить это работать, либо уволится ) увеличил существенно. по моему максимальный поставил. с дефолтным Оверранов было больше, но увеличение буферо от Всех оверранов не избавило. всё равно редко, но появляются
Arisu А если нагрузку снизить. Вот таким вот способом? Число пакетов почти столькоже, а паузы увеличились и распределили во времени. Код (Text): OUTTER_CYC = 66 или 67. INNER_CYC = 3 for( j = 0; j < OUTTER_CYC; j++ ) { for( i = 0; i < INNER_CYC; i++ ) { Посылка по первому интерфейсу 1492 байта. Посылка по второму интерфуйсу 1492 байта. } Ждём 1 микросекунду. } Или просто разбить 2мс паузу на равные интервалы? Код (Text): OUTTER_CYC = 40. INNER_CYC = 5 for( j = 0; j < OUTTER_CYC; j++ ) { for( i = 0; i < INNER_CYC; i++ ) { Посылка по первому интерфейсу 1492 байта. Посылка по второму интерфуйсу 1492 байта. } Ждём 1 микросекунду. }
Arisu я не про мануалы, просто ты писал он не мефический, он реально существует и с ним будет работать проще, ибо при требуемых нагрузках он не упирается в предел своего потенциала.
Arisu итак, как говаривал Карлсон: "продолжаем разговор..." с твоего дозволенья, конечно. Ты вообще кричи, если того, хватит типа, достало это все сдаюсь, ну или чего лучше победил, усЁ, урА. А пока, лишь довольсьвуясь краткими форумными выдержками намётками и намёками, бум кумекать, кроссвордными манерами. Кто "плавал", тот занет как бывает туго в подобных ситуациях..., посему пожалуй даже подсознательно додумываешь ситуацию, перебрав несколько "комбинаций" в мозгу, ну и изложить думаю надо, может "стрельнёт" в цель то. Может не по порядку, но все же выскажусь так. я про это писал выше, только другими словами так суть не в том, а постановка, так сказать задачи, А вот это означает, что есть реальный подопытный на 82546? Гонял своё на нём или "шатное" типа? И еще непонятно всеже и не ответил ты на вопросик уточняющего характера это по ТЗ видимо так два чипа это не сжиру ведь, это посчитанная пропускная способность, а потом схема, плата и кодинг, соотвт. обеспечивающий это? Т.е. я хочу понять и додумываю дальше, что оба потока может нужно тебе еще и складывать либо синхронные они вообще... ну как минимум нужно 2x100мБ/с по ТЗ. Отсюда 2 чипа? Pavia бросился в бой первым и правильно и по существу кода, только что то мне, как инертному лодырю не совсем понравилось, вернее засомневался я и только сегодня прояснение пришло, как альтернатива, спасибо Pavia за активные мозгодвижения! Я жуткий альтернативщик и это моя фича. Когда все пионеры в детстве строем и хором поворачивали вправо, моё непреодолимое нутро тянуло веня непременно влево, меня просто кондубасоло от противоречий! Не так как ВСЕ! Не так как у ВСЕХ! Ну оставим моё мутное прошлое, а воспользуемся фичей . Итак надёргиваю цитат из постов нанизанных на одну красную нитку идеи и ответа и смысла: Мне не жалко форумных страниц, мне смысл важен, поэтому буду повторять и комментировать. - АгА!!! Тут то все равномерно и все успевает! Так как, твоя ОС ЖРВ то ли в одном потоке это делает, толи вообще в одном прерывании... Неважно детали, ЭТО ОСь твоя виновна!!! ОНА ЖРЕТ ВРЕМЯ! Вернее она ЗАДЕРЖИВАТ ПРОЦ перед выходом в прерывыние по ричине события "буфер RX полон", "предел FIFO RX превышен" и т.п.!!! Не драйвер, а ОСь! Драйвер, бедняга виновен лишь в том "что хочется мне кушать" (с) Крылов Аппаратного ресурса впритык, диаграмма временная впритык, промедления "смерти подобны", а тут еще ОСь не считает нужным и ВЫСОКОПРИОРИТЕНЫМ(!?) переключать проц на твой драйвер и еще по команде "бегом" ). Она вошкается где то, умничает себе как то, что то еще там себе чухается, ведь она же жутко жесткая да крутая, куда же жесткость ломать, пусть подождут плебейские приложения и даже драйвера некоторые! Стало быть ОТСРОЧКА == получите милостивый государь текущий оверран. Ха! Ага, имеем, ну и что? Тока тут слово "отправляем" заменяем на получаем (RX Overrun ведь!), помимо своей воли, мы приняли и рады бы забрать и драйвер умеет(сам на себя это доказывает), тока пока в драйвер попали(CPU,IRQ,планировка задач, приоритеты...) уже затирается часть RX BUFF новой инфой, буфер же не такой крутой как в 82546...... А я "налево пойду" ))) не "увеличить" а УМЕНЬШИТЬ ПОРОГ FIFO!!!!!!!! И тогда дейстивельно можно ожидатьЖ: "что-бы раньше отпровлял прерывание". Принудим ОСЬ дергаться в ЧАСТЫХ конвульсиях по нашему IRQ запросу! Буфер 16, а порог поставим 8. Оверраны? Ставим 4. До сих пор? Ставим 2!!! И пусть гадина отдает процессорное время! У нас RX может переполниться! Это важно, понимаешь. А нагрузка увеличится. Я имею ввиду %CPU в данной задаче, драйвере, слое... И паузы уменьшатся, сами, а может случиться и так, чтои х вообще не будет. Это при очень низком, пожалуй пороге FIFO сработки. Ну и фиг сним, нам же задачу решить надо! Пусть ОСь напрягается... Ну тут далее идет поэма про ОСь, ее приоритеты, свойства, планирование... а я с ней лично не знаком поэтому на сем умолкаю, The END".
ситуация с работающим 46-ым и сбоящим 51-ым достаточно проста: промышленной версии 46-ого чипа у интела нет )) т.е. он нам не подходит по температурным характеристикам (если конкретнее, то он отрубается уже при 50 градусах окружающей) а у 51 чипа есть промышленная версия. вот и всё. на 46-ом чипе для тестов запускалась таже софтина, которой я сейчас тестирую драйвер 51-ого. разница была только в драйверах. да. на этих чипах сидит синхронизация и сравнение троированной системы. Т.е. нагружаются одновременно оба интерфейса и на приём и на передачу и достаточно серьёзно, но на очень короткие промежутки времени. но это в "боевом" варианте. А в тестовой программе происходит сначало лёгкая синхронизация, а потом посылка по вышеописанному алгоритму, затем опять синхронизация. Т.е. "передышек" ему почти не дают. уменьшение INNER_CYC до 5 уже лечит все проблемы, даже если существенно увеличить OUTTER_CYC. если INNER_CYC поставить 3, то я думаю это надо будет месяцок - другой погонять, что бы что-то выловить ). я вчера человеку ответственному за ядро высказал предположение, что мы упираемся в логику операционки, )) он помрачнел и ушел думать. я его увеличил именно потому, что оверранов было больше. увеличение порога резко снизило колличество оверранов =\\\ но я попробую ещё поиграться с этим, у меня появилась пара идей. есть пара технических вопросов: 1) в RX дескрипторе есть бит OK. Чип его выставляет только, когда Полностью закачал пакет в дескриптор, или уже сразу после достижения порога FIFO? 2) кладёт ли чип данные в RX дескриптор, если прерывания запрещены? т.е. на пример мы обрабатываем предыдущее прерывание, прерывания запрещены, а в это время чипу приезжает новый фрейм и он его должен бы класть в дескриптор.
а дай ему посты почитать, дабы не пересказывать а я наизусть не знаю думаю тебе это реаЛом проверить - щелкнуть пальцами. "Это элементарно Ватсон"! 1.1 посылаешь LEN FIFO +1 и стопаешь наглухо TX затем - см. бит (для чистоты лучше на разных зелезках. Независомость 100%) 1.2 посылаешь LEN FIFO - 1 и аналогично, затем досылаешь немного лишь бы перевалить за барьер - см. результат до и после Я думаю что он выставится когда фактически прошёл объём LEN FIFO +1 а все остальное ему по барабану, нато он флаг-бит. По п.2 думаю есть ли они или нет ему все равно, т.к. это механизм ПДП и неважно дескрипторами описан или как еще. Разработчики чипов в таких механизмах преследуют цель именно НЕ потерять ценную инфу ввиду возможного "отсутствия внимания" к контроллеру со стороны процессорной части. Опыт следующий. Запрет прерывания, затем отправка блока, пауза, смотрим дескриптор или разрешили прерывания и вычитали переданное - значит прием работает независимо. Еще. Тебе возможно нужно попробовать метод, как бы динамического перепрограммирования дескипторов. Цель избежать затирания. Каждая новая инфа должна ложиться в гарантированно-ВЫЧИтанную ранее область ОЗУ. Это или нечто подобное применялось(ется) при работе с аудиокартами, звуком.... шиты читать влом и некогда, ну если очень нуна скажи вкурюсь, раз надо. Итак типа такого. Пусть у тебя 4 области RX 0,1,2,4 по 16К. Предел RX стоит один 8. Изначально на прием заряжен(описан) 0-й. Пошла пердача. Достигли границы и свыше, сработала железка, пошла байда по ОСи, что нуждаешься... пока проц вывалился к тебе, есть надежда, что мы ХОТЯБЫ не перевалили за первые 16К! Это важно и тут тебе с ядерщиками решать полюбому!!! Хай обеспечат кровь из носу. Далее попал ты к себе, прерывания стопнулись, но ДАННЫЕ ИДУТ! Ты должен предусматривать худший вариант, а это именно ТАК. Таким образом сначала нужно декриптор(голову) заколбасить НА НОВУЮ ПОЗИЦИЮ на 1-ю!!! Никаких вычиток, пусть в неком регистре адреса еще будет работа по 0-й зоне и он(некий регистр адреса еще растет и пишет! Относительно головы 0-й) а нам надо превести БЕЗРАЗРЫВНО его поток в новую в 1-ю. Поэтому пробомбили дескриптор или что там еще (надежда на твое наизусть) 1-ю зону ОЗУ, ОК! Теперь можно и культурно заняться 0-й. Но тут тоже может быть подвох, т.к. где же хвост? Мы попали при превышении FIFO, а заначит нет гарантии, что хвост еще не растет в 0-й зоне. Это надо понимать и сделать умнёхонько, т.е. либо убедиться что все и он не растет и пошел таймаут, либо увидеть что он уже в 1-ю аппаратно перекинулся, проиинилась головой 1-й зоны... Тебе видней ). Ну и конечно закольцовка! Надо предусмотреть то после 3-й переход на 0-ю. Я пишу в общих словах О ПРИНЦИПЕ, а не конкретно к чипу. В большинстве случаев часть этого уже реализована в самом механизме дескрипторов. Вернее работы с ними. Остается только правильно мониторить по битам и указателям где ОН находится, что делает, куда пишет, что находится в "захваченном" состоянии... Короче ДИСТАНЦИЯ! То что читается должно иметь дистанцию от того что пишется и по адресам и по номеру зоны в ОЗУ и по ВРЕМЕНИ(устранение неравномерности(еЙ!)). Но это по времени мы и получим в виде ГАРАНТИрованной работы, что нужна. И она сложится в силу принципов и логики работы железка + алгоритм + код драйвера + реалии жизни ОСи.
