Смотря как сеть сделана.
Если стрелять не через тот же канал, через который осуществляется связь между нодами, то да, бессмысленно и опасно.
А если и выстрел и связь по одному линку будут проходить (грубо, 4 линка, eth+ipmi от каждой ноды, будут приходить в один коммутатор\маршрутизатор), то:
1. eсли упал только eth линк, то выстрелят оба, но у одного eth линка нет и его выстрел не дойдет до адресата;
2. eсли упали и eth, и ipmi линки, то выстрелят оба, ни один STONITH не сработает, ресурсы мигрировать не начнут.
Без определения базиса для оценки далеко не уедешь.
По полученным результатам может ничего не получиться: задача может отказаться или слишком простой, или слишком сложной.
Без нормировочной оценки или много людей «пройдет» тест или много «завалится».
Как вариант, можно попросить коллег написать подобного рода задачек, а решать самому (как заинтересованному лицу). Тогда у вас будет нормировка на вас и по своим результатам можно будет оценить кандидата.
Прежде чем просить найти ошибки на собеседовании, с целью определения уровня кандидата, хорошо бы провести «нормировку» на людях с известной квалификацией, что бы понимать какой уровень ответов чему соответствует.
Может быть, даже, на коллегах на работе, чья квалификация известна и может использоваться в качестве базиса для оценки уровня кандидата.
Расскажите, пожалуйста, по подробнее про антенны. Я так понимаю к стандартной аппаратуре (управления и передачи видео) были прикручены самодельные антенны? Как рассчитывали, по каким соображениям подбирали (кроме экспериента с дальностью), как ставили (если это не тривиальная процедура)?
И еще вопрос: какую камеру для FPV взяли и почему?
Да, по поводу аппаратуры еще момент: попробуйте вообще отключить YAW канал (те что бы приемник не давал на него сигнал). Если симптомы останутся, при прочих равных условиях, это будет говорить что аппаратура ни при чем и нужно смотреть на гироскоп\крутить PID'ы.
Я у себя очень долго боролся с паразитными движениями коптера, пока не догадался сгладить кривую радиоуправления (через GUI) и выставить DEADBAND в конфиге.
Если летаете с компасом — отключите компас. Проверьте показания гироскопа. В этом случае multiwii начнет ориентироваться только на гироскоп и будет пытаться выправлять вращение.
Проверьте что аппаратура на центральное положение стиков по всем каналам дает уовень сигнала 1500 (по GUI).
Проверьте что в конфигурации multiwii центральное положение стиков — это 1500.
Значит я не верно понимаю суть этого крепления (я с квадриками вожусь).
По мне так, если тяги заменить на прямое соединение к серве (как в статье), то получается именно такой шарнир, который позволяет наклонять мотор в нужной плоскости.
Проблему сети решит так же реплицирование: если клиентов много, то в качестве источника файла будут выбираться разные узлы.
А тестирование скорости интересовало в контексте сравнения с чистым NFS при равных условиях (у себя, к сожалению, мы такой тест провести не в состоянии из-за режим работы dCache).
А с реплицированием не заморачивались? Это позволит сделать дублирование данных на уровне dCache и выход из строя пулов не будет влиять на жизнеспособность системы в целом (пока свободное место есть).
Не занимались ли вы сравнением NFS-dCache и чистого NFS, в плане производительности (iozone, например)? Очень интересно было бы сравнить производительность.
Это не опасения. Мы раньше использовали схему с приоритетом доступного места(правда classic partition, без случайностей, просто лучший пул) и получали замечательный результат: на нас записывают болк данных, а потом 1000 клиентов этот блок начинают забирать (да, данные весьма специфичные). И все, 1000 потоков, скорость 100 мегабайт в час (на сети 1GB/s и данные 2Gb). Те пул фактически блокировался. И быть лучшим на запись, по идее быть не должен.
Со случайным выбором пула «не хуже чем», возможно тоже самое. Для трансфера может выбираться перегруженный клиентами пулл. По этому мы пожертвовали симметричностью заполненности в пользу симметричности загрузки.
2.7 еще далеко. Поскольку у нас требуется безотказная работа хранилища в режиме 24/7/365, мы используем только golden release. А на 2.6 перебраться пока нет возможности. по тем же причинам.
Институты (вычислительные центры) данные сами не заказывают. Они только предоставляют физикам вычислительные мощности. Решение что у вычислительного центра должны быть те или иные данные принимается на уровне команды отвечающий за вычисления в самом эксперименте.
У нас как раз 2.2. По исходникам суть остается именно такой: dCache смотрит только на вес пула по свободному месту (если используется партишен с такой системой выбора пулов для записи), что может привести к проблемам описанным выше.
У разных экспериментов разный подход к данным. LHCb, например, данные в Tier-2 вообще не хранит. А в ATLAS все поделено на регионы и каждый Tier-2 ходит исключительно к Tier-1 своего региона (у нас, пока, это Голландия). ALICE имеет действительно распределенное глобальное пространство, но подробностей, к сожалению, не знаю, так как с ними много не работал.
Горизонтальные трансферы — это реплицирование. Поскольку данные первичны и задачи могут прийти только туда где есть данные для них, а один вычислительный центр редко работает с одним экспериментом, важно что бы не было ситуации что некуда запускать задачи.
И сеть далеко не p2p. Трансфер всегда идет точка-точка. Данные разделены на блоки и такого что половина блока берется с одного сайта, а половина с другого не бывает (за Алису точно не скажу, поскольку они были первыми кто для установки софта на вычислительные узлы начал пользоваться торентами. Могли и к данным что-нибудь хитрое прикрутить, в плане алгоритмов).
У dCache немного не такая структура, как вы ее себе представляете.
На сервере метаданных самих метаданных нет. У него все их только спрашивают. А сама информация хранится в postgresql базе данных. На сервере метаданных живет только кэш последних запросов в памяти.
У нас не очень нагруженная система (в день где-то 10 миллионов запросов к базе, не только метаданных). Из которых 54% SELECT и 30% — начало/конец транзакций. В пике 3000 запросов в секунду.
Запросы, в среднем, обрабатываются меньше чем за 0,037 секунды (верхняя граница самых «тяжелых» запросов).
Так что база узким местом не является. Сами файлы передаются дольше.
Когда она падает — неприятно. Но мы собрали HA кластер и это перестало быть бедой.
Больше сложность -> больше найденных блоков подходит под условие -> блоки генерируется быстрее.
В реальности, вроде, наоборот.
Если стрелять не через тот же канал, через который осуществляется связь между нодами, то да, бессмысленно и опасно.
А если и выстрел и связь по одному линку будут проходить (грубо, 4 линка, eth+ipmi от каждой ноды, будут приходить в один коммутатор\маршрутизатор), то:
1. eсли упал только eth линк, то выстрелят оба, но у одного eth линка нет и его выстрел не дойдет до адресата;
2. eсли упали и eth, и ipmi линки, то выстрелят оба, ни один STONITH не сработает, ресурсы мигрировать не начнут.
Про кворум спасибо что напомнили. Метод «настроил и забыл» плох именно тем, что настроил и забыл. Сейчас дополню.
По полученным результатам может ничего не получиться: задача может отказаться или слишком простой, или слишком сложной.
Без нормировочной оценки или много людей «пройдет» тест или много «завалится».
Как вариант, можно попросить коллег написать подобного рода задачек, а решать самому (как заинтересованному лицу). Тогда у вас будет нормировка на вас и по своим результатам можно будет оценить кандидата.
Может быть, даже, на коллегах на работе, чья квалификация известна и может использоваться в качестве базиса для оценки уровня кандидата.
Те FPV и запись видео идут с одного источника… Понятно.
Спасибо за разъяснения.
И еще вопрос: какую камеру для FPV взяли и почему?
Я у себя очень долго боролся с паразитными движениями коптера, пока не догадался сгладить кривую радиоуправления (через GUI) и выставить DEADBAND в конфиге.
Проверьте что аппаратура на центральное положение стиков по всем каналам дает уовень сигнала 1500 (по GUI).
Проверьте что в конфигурации multiwii центральное положение стиков — это 1500.
По мне так, если тяги заменить на прямое соединение к серве (как в статье), то получается именно такой шарнир, который позволяет наклонять мотор в нужной плоскости.
Для крепления заднего мотора есть готовые решения. Вроде www.hobbyking.com/hobbyking/store/__28985__Micro_3D_Single_Axis_Thrust_Vectoring_Motor_Mount.html
А тестирование скорости интересовало в контексте сравнения с чистым NFS при равных условиях (у себя, к сожалению, мы такой тест провести не в состоянии из-за режим работы dCache).
Не занимались ли вы сравнением NFS-dCache и чистого NFS, в плане производительности (iozone, например)? Очень интересно было бы сравнить производительность.
Со случайным выбором пула «не хуже чем», возможно тоже самое. Для трансфера может выбираться перегруженный клиентами пулл. По этому мы пожертвовали симметричностью заполненности в пользу симметричности загрузки.
2.7 еще далеко. Поскольку у нас требуется безотказная работа хранилища в режиме 24/7/365, мы используем только golden release. А на 2.6 перебраться пока нет возможности. по тем же причинам.
У разных экспериментов разный подход к данным. LHCb, например, данные в Tier-2 вообще не хранит. А в ATLAS все поделено на регионы и каждый Tier-2 ходит исключительно к Tier-1 своего региона (у нас, пока, это Голландия). ALICE имеет действительно распределенное глобальное пространство, но подробностей, к сожалению, не знаю, так как с ними много не работал.
Горизонтальные трансферы — это реплицирование. Поскольку данные первичны и задачи могут прийти только туда где есть данные для них, а один вычислительный центр редко работает с одним экспериментом, важно что бы не было ситуации что некуда запускать задачи.
И сеть далеко не p2p. Трансфер всегда идет точка-точка. Данные разделены на блоки и такого что половина блока берется с одного сайта, а половина с другого не бывает (за Алису точно не скажу, поскольку они были первыми кто для установки софта на вычислительные узлы начал пользоваться торентами. Могли и к данным что-нибудь хитрое прикрутить, в плане алгоритмов).
На сервере метаданных самих метаданных нет. У него все их только спрашивают. А сама информация хранится в postgresql базе данных. На сервере метаданных живет только кэш последних запросов в памяти.
У нас не очень нагруженная система (в день где-то 10 миллионов запросов к базе, не только метаданных). Из которых 54% SELECT и 30% — начало/конец транзакций. В пике 3000 запросов в секунду.
Запросы, в среднем, обрабатываются меньше чем за 0,037 секунды (верхняя граница самых «тяжелых» запросов).
Так что база узким местом не является. Сами файлы передаются дольше.
Когда она падает — неприятно. Но мы собрали HA кластер и это перестало быть бедой.