Увы, готовых решений никто не даст. Приходится смотреть форумы и сайты по регистраторам, ixbt, форумы покупателей на ебае и али-экспресс, в общем перелопачивать кучу информации, чтобы найти то, что подойдет тебе.
Естественно. До сих пор продаются регистраторы качества ниже, чем тот же Каркам Q2, и ведь кто-то их покупает. Но также стоит заметить, что большинство новых топовых регистраторов — тот же Китай (реже Корея) и на Али их можно найти дешевле, чем их продают перемаркированными под символику своей фирмы тут.
Надо смотреть в сторону разнесенных мото-регистраторов, т.к. там встречаются влагозащищенные камеры. Даже я, вроде, видел клона Koonlung K1S с такими камерами, но сейчас ссылку найти не удается.
Ну и протирать камеру осенью/зимой/весной будет утомительно, т.к. после каждой поездки она будет грязная.
> У F9 mini Sport DV честное разрешение 1280х720.
Я догадался по полученному результату. Полноценный тест на всех возможных разрешениях никак не попадал в мои возможности, большинство устройств я получил только на 2 выходных дня.
> Разве при ночной съемке все не упирается во время экспонирования?
Теоретически да.
> Я так понимаю что там реальный fps меньше даже заявленных 30.
Ну, если смотреть видео покадрово, то каждый кадр отличается от предидущего даже в минимальной освещенности. Думаю iso современных регистраторов очень высокое.
Спасибо. На самом деле очень много времени ушло на изучение и пробу различных подходящих инструментов для работы с видео и картинками.
Сейчас, уже имея наработки и готовые скрипты, я бы сделал полное сравнение за несколько вечеров одной недели. Написание текста было бы самым большим по затрам куском.
> но можно же сделать камеру с 30 fps, но просто с более короткой выдержкой.
Можно, но в темноте она ничего не сможет снять, так?
> почему не поправляют алгоритмы определения экспозиции.
Поправляют. В хороших регистраторах экспозиция выставляется правильно, даже в сложных условиях, типа отражений собственных фар от краски впереди-стоящего автомобиля, отражение солнца или фонарей от своего капота, слепящий свет встречных фар и т.п.
Но вообще условия очень сложные, количество источников света и бликов большое и в произвольных местах кадра, это не «халявный» режим работы как у домашней видеокамеры, где сверху всегда светло, а снизу темно.
Ну, я привожу факты, то, что может проверить любой человек на собственном пц — создать заметно бОльшее количество запросов, чем успевает обрабатывать система и посмотреть к какому эффекту это приводит.
Если интересно, то надо дальше самими искать. Всяческие сравнения делались и пятнадцать, и пять лет назад, графики поведения высоконагруженных систем публиковались, хотя сейчас найти с ходу неудалось.
Впринципе, достаточно посмотреть по годам топ бенчмарка olap-систем. Еще даже лет семь назад там никаким x86 не пахло, даже в виде очень многопроцессорных систем.
Откройте мою статью шестилетней давности https://habrahabr.ru/post/90677/ и ответте на вопрос, почему апач перестал отвечать на запросы, когда loadavg выросла больше 50.
Мне кажется, или главная цель любой компании, которая вводит курсы и экзамены — сознательное усложнение интерфейса их продуктов, для того, что бы специалисты или их компании ежегодно выкладывали круглые денежки за обучение и переэкзаменовку?
> Т.е. на тот год (2010-2011) все банально упиралось в количество ядер
Потоков, а не ядер.
Это на x86 привычно, что одно ядро — 2 потока, на других архитектурах их было разное значение, например на спарках — заметно больше.
> Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик?
> Тем не менее идет обработка множеством ядер, в чем загвоздка?
Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?
Для сравнения берем примерно 2010-11 год, когда спарки еще не слишком сильно отставали от интела:
— Xeon Nehalem (55xx) — максимально число ядер 4, максимальное число потоков на ядро 2 (тот самый HT), итого 8 потоков на сокет. Максимум сокетов в одной системе — 2(4?).
— IBM Power7 — ядер 8, 4 потока на ядро, итого 32 потока на сокет. Максимум до 32 сокетов в одной системе — IBM Power 795.
— Sparc T3 — ядер 16, 8 потоков на ядро, итого 128 потоков на сокет. Максимум до 4 сокетов в одной системе — SPARC T3-4.
> Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
Для базы данных все все запросы одинаковы, скорее всего у нее просто нет средств приоретизации по каким-то формальным признакам.
> но разве это не лечится правильным кодом, особенно когда сервер занимается вычислением однотипных задач, как например в банковской сфере?
Там идет обслуживание транзакций, в какие-то моменты количество транзакций может быть пиковым, что вызовет значительные задержки, что вызовет создание очереди выполнения всех поступающих после.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.
Ну и протирать камеру осенью/зимой/весной будет утомительно, т.к. после каждой поездки она будет грязная.
Я догадался по полученному результату. Полноценный тест на всех возможных разрешениях никак не попадал в мои возможности, большинство устройств я получил только на 2 выходных дня.
> Разве при ночной съемке все не упирается во время экспонирования?
Теоретически да.
> Я так понимаю что там реальный fps меньше даже заявленных 30.
Ну, если смотреть видео покадрово, то каждый кадр отличается от предидущего даже в минимальной освещенности. Думаю iso современных регистраторов очень высокое.
Сейчас, уже имея наработки и готовые скрипты, я бы сделал полное сравнение за несколько вечеров одной недели. Написание текста было бы самым большим по затрам куском.
Можно, но в темноте она ничего не сможет снять, так?
> почему не поправляют алгоритмы определения экспозиции.
Поправляют. В хороших регистраторах экспозиция выставляется правильно, даже в сложных условиях, типа отражений собственных фар от краски впереди-стоящего автомобиля, отражение солнца или фонарей от своего капота, слепящий свет встречных фар и т.п.
Но вообще условия очень сложные, количество источников света и бликов большое и в произвольных местах кадра, это не «халявный» режим работы как у домашней видеокамеры, где сверху всегда светло, а снизу темно.
Если интересно, то надо дальше самими искать. Всяческие сравнения делались и пятнадцать, и пять лет назад, графики поведения высоконагруженных систем публиковались, хотя сейчас найти с ходу неудалось.
Впринципе, достаточно посмотреть по годам топ бенчмарка olap-систем. Еще даже лет семь назад там никаким x86 не пахло, даже в виде очень многопроцессорных систем.
Привет тебе :)
Читал про музей. могу только пожелать удачи.
Потоков, а не ядер.
Это на x86 привычно, что одно ядро — 2 потока, на других архитектурах их было разное значение, например на спарках — заметно больше.
> Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик?
Погугли бы? Всего 4U.
Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?
Для сравнения берем примерно 2010-11 год, когда спарки еще не слишком сильно отставали от интела:
— Xeon Nehalem (55xx) — максимально число ядер 4, максимальное число потоков на ядро 2 (тот самый HT), итого 8 потоков на сокет. Максимум сокетов в одной системе — 2(4?).
— IBM Power7 — ядер 8, 4 потока на ядро, итого 32 потока на сокет. Максимум до 32 сокетов в одной системе — IBM Power 795.
— Sparc T3 — ядер 16, 8 потоков на ядро, итого 128 потоков на сокет. Максимум до 4 сокетов в одной системе — SPARC T3-4.
> Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
Для базы данных все все запросы одинаковы, скорее всего у нее просто нет средств приоретизации по каким-то формальным признакам.
Там идет обслуживание транзакций, в какие-то моменты количество транзакций может быть пиковым, что вызовет значительные задержки, что вызовет создание очереди выполнения всех поступающих после.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.