Мониторинг МАП и MPPT МикроАРТ. Продукты пользователей

По частоте в config. txt остался дефолт от родной прошивки. Которая идет для всех RasPi.
Я не повышал, ибо условия эксплуатации у людей совершенно различны. И если он находится в неблагоприятных условиях - вообще рекомендуется 400 ставить.
700МГц за глаза ему для этой задачи. Зачем повышать до 900? Это что-то меняет?
Да и если вы читали ветку, ранее написано, что образ работает и на RasPi, но рекомендуется RasPi2
Кто желает - может ставить 900.
Только может объясните - какова практическая польза от изменения 700 на 900? Платформа становится стабильнее? Меньше ошибок? Еще что-то? Я пробовал разные частоты - разницы не увидел, кроме как ухудшения стабильности и роста чувствительности к питанию с ростом частоты.
Если работать лучше становится - вы скажите, пожалуйста, я тогда в будущих образах сразу 900 буду ставить

И если уж пишете, чтобы кто-то что-то сделал, будьте добры впредь сразу пояснять, что и как. Чтобы ненужных вопросов не возникало. А то " проверить". Что проверить, почему, что должно быть. Для чего. Мне лично - не понятно.

 

Ой ну зачем так бурно то? Я вовсе не хотел что то указывать или как то дискредитировать автора
Просто есть спецификация устройства, я придерживаюсь позиции эксплуатации железа на рекомендованных параметрах.
Прошу прощения если каким то образом задел Вас, но такой цели точно не было.
Для меня это может и субъективно снизило время отклика системы

 

Я много написал только потому, что достаточно большому числу вещей, которые реализованы и настроены именно так, есть объяснение.
Как например отсутствие поиска устройств микроарт по портам, а вместо этого достаточно жесткая привязка. Потому как у пользователя может быть еще какое-то tty устройство, типа модема, и банально любой нештатной цепочкой байт в порт мы можем вызвать непредсказуемую реакцию девайса.

Рекомендованные параметры для АРМ - это весьма расплывчатая вещь. Например, один и тот же изготовитель (Самсунг, например) выпускает на одном и том же камне 2 разных устройства - в одном частота 1.2ГГц, в другом, скажем 1.4ГГц. А на самом деле все определяется напряжением и делителем и шкалой доступных частот CPU и как следствие только общей стабильностью системы.

Во-первых, 900 МГц это верхняя граница. Во-вторых, текущая частота будет зависеть от текущего алгоритма управления частотой (governor)
Текущая частота отнюдь не 700 и не 900 МГц
Возьмите команду cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
И увидите текущую частоту. Для меня, например, это 600МГц в основном. Т. е. если при текущем алгоритме управления частотой я подниму планку до 1ГГц, то моя рабочая частота так и останется 600
Кроме того, вся система еще тормозится скоростью обмена по шинам, в т. ч. с самым медленным устройством - USB Flash

 

@Osolemio, Вы написали, покрасовались, скриншотики положили.[/QUOTE]

Несколько человек в качестве альфа-теста, альтернативный интерфейс эксплуатируют уже. Батарейный монитор написан новый. На SQL запросах. Напомню, это 90% клиентский интерфейс. Сервер, кроме SQL никто не трогает.

Кстати, коли уже тему затронули . Вопрос об обоснованности полей number, date, time в базе. Почему не таймштамп индекс?

 

И да, я по экспериментировал и разогнал свою животину до 1 Гц
root@microart-map:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1000000
Но это на доп. радиаторах и в условиях нормального охлаждения.
Работа устойчивая без сбоев и ошибок, стоит на тесте, результаты отпишу, что в этом плохого?
Я же не говорю что это должны делать все - это информация.
Я просто не могу представить нормального технаря который не стремится что то улучшить.

 

Очень интересно как это будет работать на тонких каналах при длительных во времени циклах батареи. Оргомнейшие запросы-ответы. Ну-ну. Кроме того, вы, используя SQL теряете точность, ибо в БД пишутся значения с гораздо меньшей точностью и с гораздо большей задержкой, чем они передаются через разделяемый сегмент памяти от процесса к процессу. Ну да вам виднее.

Потому как нужна иногда бывает синхронизация и отдельные выборки по дате, по времени. Читалки не синхронны сами по себе и между собой и поля timestamp не будут идентичны. Следовательно SQL запросы будут не единообразны, а уникальны. И все придется пересчитывать в timestamp
Далее - выработка квтч за день
SQL запрос очень прост. максимальное значение за дату.
На основе timestamp запрос бы вешал RasPi навсегда

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

 

В смысле все основываться будет на уже полученных ранее данных?
Данный подход может внести неоднозначность в интерпретацию результатов при обработке результатов тригерром, нет?
Актуальность данных в БД может сыграть злую шутку, в том числе и при работе с таймштампом.

 

Предложение ваше по-идее должно было примерно так и выглядеть:
мол, частота сейчас 700 МГц. Можно легко разогнать до стольки-то, если хотите.
И т. д. и т. п. Как и полагается на тех. форумах

От себя скажу - МАП штука такая, что при переходе на резерв может до 1 периода терять. Источники питания просаживаются в это время часто. Меньшая частота - залог более стабильной работы
То, что вы видите 1ГГц - это всего лишь заслуга говернора, который при малейшем чихе выводит проц на максимальную частоту. Не забываем, что при этом наш RasPi начинает кушать больше. Что некоторым пользователям совсем не понравится. Особенно в автономии.

 

Ну я могу только догадываться, но ранее он написал, что все происходит на стороне клиента. Возможно я чего-то не понимаю просто

 

Ну да, тут для чистоты специально поставил спец питание, наверное интуитивно уже
Да возможно Вы правы, многие вещи уже не пытаешься объяснить считая их самим собой необходимым условием...
Старею...

 

Кроме того, база сегментирована по 10 календарным дням. В целях ускорения обработки запросов. И снижения нагрузки на накопитель. Таймстамп для этого не подходит. Нужно поле даты как первичный. Я над структурой БД и оптимизацией запросов несколько дней провел.
И еще очень много примеров, где запросы оперируют отдельно датами, отдельно номерами (как уникальный индекс с постоянным приращением), отдельно временем

Например, риплей по истории - проще найти индекс по совпадению и дальше поле номер инкрементировать, чем думать - какая будет следующая запись по timestamp. А она может быть через секунду, а может быть и через час.
И как следствие - офигенная быстрота обработки запросов и минимальная нагрузка на ЦП

 

Ну тут есть естественный выход - индекс по timestamp, но он же и порочный учитывая перезагрузки, старты и прочие нештатные ситуации с установкой времени в системе и в МАП. Практически своими руками готовим себе головняк с обработкой всего -всего.
Самое верное - исключить возникновение подобных ситуаций.
Это как с интерфейсом пользователя - во всех смыслах дешевле исключить даже вероятность ошибки пользователя, чем тратить время на обучение пользователя НЕ совершать этих действий - все равно бесполезно

 

Как подтверждение - в своих системах при проектировании и внедрении выделяем специальны этап на повторный анализ запросов и систем репортинга. Результат всегда положительный. Был случай когда нестандартный подход использования web запроса вместо классики дал 500% прирост скорости обработки запроса.
Я до сих пор в шоке от результата, но там реально был сложный замут реализации обработки запросов из неструктурированных БД.

 

Индекс timestamp всего лишь ускоряет поиск по timestamp , но вносит кучу усложнений в код в т. ч.
Примеры я уже привел
Нашли вы, к примеру, timestamp на 01.01.15 23:12:12 и хотите с этого времени посмотреть историю.
Какая будет следующая запись? Опять искать? Или выборку в temp таблицу делать по интервалу и оттуда плей. А ресурсов у нас мало. И лишняя запись на флеш тоже ни к чему.
А у меня мы нашли по индексу number, и следующая запись number+1 - можно проигрывать бесконечно, даже не особо заботясь о верхней границе
Да и вы правы, сбой в системном времени и т. п. полностью херит просто все

 

web services