Спасибо за ответ. Статью по гистограммам максимального и среднего времени конечно читал. Правильно понял, чтобы получить их процентили, надо ведь делать снимки pg_stat_statements достаточно часто (чтобы было больше стат. данных), при этом ещё и обнулять статистику при каждом снимке, чтобы не терять максимальные значения?
Удивляюсь, как интересно работают продавцы вроде ВсехИнструментов или Кувалды.
Там и гарантийная работа, и доставка не суперредких товаров быстрее недели, и цена для покупателя не дороже Мерлена (но часто дешевле озона, особенно в низком сегменте), и даже бесплатные звонки для покупателей.
Выходит, что за этот сервис платит производитель. Но сколько он платит больше (по сравнению с озоном и вб) и что получает взамен?
Если за основу брать снимки pg_stat_statements, то они ведь уже содержат усреднённые значения. Дополнительное применение медианы по большим временным интервалам кажется избыточным, так как скрывает детали происходящего: пики по calls/<единицу времени> всплески rows/calls, аномалии shared_blks_read или shared_blks_hit и т.п. Для грубой оценки динамики нагрузки по времени суток годится, а для расследования инцидентов - будто бы и не очень.
Всегда думал, что в pg_stat_statements не хватает процентилей времени и других показателей по запросам, но поменял мнение. Вижу, что для адекватной реализации процентилей за временное окно нужно либо постоянно сбрасываться через pg_stat_statements_reset(), или же хранить довольно много данных в виде распределения по бакетам, а сами бакеты надо заранее определить и при этом ещё и нельзя двигать на лету. Снимки pg_stat_statements придётся уже делать по сырым счётчикам в бакетах и на выходе пересчитывать довольно упрощённые процентили.
сопротивления должны иметь погрешность в районе , что на несколько порядков меньше 1%.
Подскажите, как это можно доказать и ко всем ли разрадам это применяется?
Когда моделировал r2r из минимального набора резисторов с равномерно распределённой ошибкой, на несколько порядков большей, чем относительная величина младшего разряда, то стабильно удавалось путём перебора всех перестановок получить несколько комбинаций с максимальной абосолютной ошибкой сильно меньше значения сигнала младшего разряда, не говоря о дифференциальной нелинейности, которая получалась просто ничтожной.
В мю-повторителе не стоит делать фикс-смещение верхней лампы. Верхняя лампа - не только активная нагрузка нижней, но и катодный повторитель с общей сеткой для нижней лампы. Если убрать катодный резистор и сделать фикс-смещение, то из каскада она превратиться в активную нагрузку. Одно из последствий - увеличится внутреннее сопротивление каскада из двух ламп.
ГСТ будет у пентодов (в пентодном ключении). Тут включение триодное, мю невелик, немногим более 20, поэтому уползание будет, хоть и не резкое. Проблема, как отметили выше, в разном смещении: у нижней фикс, а у верхней - авто.
Действительно интересная схема с двумя каскадами мю-повторителей. Каждый из них будет иметь очень большое (может быть >100) усиление, потому что ВАХ у jfet - пентодные, отчего на втором каскаде будет сеточное затворное ограничение с плавающей рабочей точкой.
Из минусов отмечу, что не смотря на rc-фильтры по питанию, грязь из питания с виртуальной средней точки r2-r3 полезет как есть на затвор второго каскада и там её усилят в коэффициент усиления.
Тут либо отказаться от питания не батарейкой (даже в литиевой Кроне есть шумная повышайка, если это не Soshine), либо сделать активный фильтр в питании, либо, что кажется более правильным, добавить в среднюю точку RC-фильтр с низкой частотой среза. И плюс 1 резистор, чтобы развязаться от средней точки по переменке.
Вроде такой вопрос не задавали, почему при смешении RGB в ярконстный канал требуется в 3 раза меньше полоса видеоусилителя? Как мне кажется, она останется той же, она ведь определяется числом точек по горизонтали, а усилителей для RGB 3 шт. и они независимы.
Пожалуйста. В случае с btree, чтобы найти ближайшую точку (значение, не вектор), надо сделать 2 подзапроса: максимальное слева и минимальное справа. Когда не потребуется сканировтаь весь индекс.
Спасибо за то, что подсветили эту проблему. Если IT-сотрудник захочет слить данные, он найдёт, как это сделать даже с DLP.
По моему опыту, >60% компаний даже до удалёнки использовали DLP. Не все правда пытались проводить mitm, но почти все - урезать права и запретить внешние носители.
Кроме того, только в тех из них, где не было DLP, постоянно жаловались на потерю крупных клиентов и слитые проекты из-за двойной игры менеджеров.
Сам я не оправдываю использование DLP, стараюсь выбирать тех, у кого есть BYOD или есть возможность работать на чистом образе с максимальными правами. Так для себя решил, как в одной конторе я получал предъявы, что (по данным DLP) я не отрабатывал 8 часов. А лютые безопасники "на живца" подсовывали от имени коллег псевдо-фишинговые ссылки и предложения продать дамп.
Большое спасибо за находку и за тестирование.
Параметры впечатляют, особенно выскоий R9.
Подскажите, это эта лента?
Спасибо за ответ. Статью по гистограммам максимального и среднего времени конечно читал. Правильно понял, чтобы получить их процентили, надо ведь делать снимки pg_stat_statements достаточно часто (чтобы было больше стат. данных), при этом ещё и обнулять статистику при каждом снимке, чтобы не терять максимальные значения?
Удивляюсь, как интересно работают продавцы вроде ВсехИнструментов или Кувалды.
Там и гарантийная работа, и доставка не суперредких товаров быстрее недели, и цена для покупателя не дороже Мерлена (но часто дешевле озона, особенно в низком сегменте), и даже бесплатные звонки для покупателей.
Выходит, что за этот сервис платит производитель. Но сколько он платит больше (по сравнению с озоном и вб) и что получает взамен?
Если за основу брать снимки pg_stat_statements, то они ведь уже содержат усреднённые значения. Дополнительное применение медианы по большим временным интервалам кажется избыточным, так как скрывает детали происходящего: пики по calls/<единицу времени> всплески rows/calls, аномалии shared_blks_read или shared_blks_hit и т.п. Для грубой оценки динамики нагрузки по времени суток годится, а для расследования инцидентов - будто бы и не очень.
Всегда думал, что в pg_stat_statements не хватает процентилей времени и других показателей по запросам, но поменял мнение. Вижу, что для адекватной реализации процентилей за временное окно нужно либо постоянно сбрасываться через pg_stat_statements_reset(), или же хранить довольно много данных в виде распределения по бакетам, а сами бакеты надо заранее определить и при этом ещё и нельзя двигать на лету. Снимки pg_stat_statements придётся уже делать по сырым счётчикам в бакетах и на выходе пересчитывать довольно упрощённые процентили.
По-моему там воздушный зазор.
Не подскажите, какие требования должны быть к такому зазору?
Подскажите, как это можно доказать и ко всем ли разрадам это применяется?
Когда моделировал r2r из минимального набора резисторов с равномерно распределённой ошибкой, на несколько порядков большей, чем относительная величина младшего разряда, то стабильно удавалось путём перебора всех перестановок получить несколько комбинаций с максимальной абосолютной ошибкой сильно меньше значения сигнала младшего разряда, не говоря о дифференциальной нелинейности, которая получалась просто ничтожной.
В мю-повторителе не стоит делать фикс-смещение верхней лампы. Верхняя лампа - не только активная нагрузка нижней, но и катодный повторитель с общей сеткой для нижней лампы. Если убрать катодный резистор и сделать фикс-смещение, то из каскада она превратиться в активную нагрузку. Одно из последствий - увеличится внутреннее сопротивление каскада из двух ламп.
ГСТ будет у пентодов (в пентодном ключении). Тут включение триодное, мю невелик, немногим более 20, поэтому уползание будет, хоть и не резкое. Проблема, как отметили выше, в разном смещении: у нижней фикс, а у верхней - авто.
Более недорогой вариант Li-Ion без преобразователя есть на Алике.
Там же - вариант Ni-MH, но требуется зарядник.
Есть вариант Ni-MH с зарядником
Действительно интересная схема с двумя каскадами мю-повторителей. Каждый из них будет иметь очень большое (может быть >100) усиление, потому что ВАХ у jfet - пентодные, отчего на втором каскаде будет
сеточноезатворное ограничение с плавающей рабочей точкой.Из минусов отмечу, что не смотря на rc-фильтры по питанию, грязь из питания с виртуальной средней точки r2-r3 полезет как есть на затвор второго каскада и там её усилят в коэффициент усиления.
Тут либо отказаться от питания не батарейкой (даже в литиевой Кроне есть шумная повышайка, если это не Soshine), либо сделать активный фильтр в питании, либо, что кажется более правильным, добавить в среднюю точку RC-фильтр с низкой частотой среза. И плюс 1 резистор, чтобы развязаться от средней точки по переменке.
В 8087-CORDIC
Благодарю!
Спасибо. Результат Spectrum anylysis (FFT) можно выгрузить в csv ?
Подскажите, пожалуйста: как измерить thd (кни) синусоидального генератора?
Вроде такой вопрос не задавали, почему при смешении RGB в ярконстный канал требуется в 3 раза меньше полоса видеоусилителя? Как мне кажется, она останется той же, она ведь определяется числом точек по горизонтали, а усилителей для RGB 3 шт. и они независимы.
Пожалуйста. В случае с btree, чтобы найти ближайшую точку (значение, не вектор), надо сделать 2 подзапроса: максимальное слева и минимальное справа. Когда не потребуется сканировтаь весь индекс.
Спасибо за то, что подсветили эту проблему. Если IT-сотрудник захочет слить данные, он найдёт, как это сделать даже с DLP.
По моему опыту, >60% компаний даже до удалёнки использовали DLP. Не все правда пытались проводить mitm, но почти все - урезать права и запретить внешние носители.
Кроме того, только в тех из них, где не было DLP, постоянно жаловались на потерю крупных клиентов и слитые проекты из-за двойной игры менеджеров.
Сам я не оправдываю использование DLP, стараюсь выбирать тех, у кого есть BYOD или есть возможность работать на чистом образе с максимальными правами. Так для себя решил, как в одной конторе я получал предъявы, что (по данным DLP) я не отрабатывал 8 часов. А лютые безопасники "на живца" подсовывали от имени коллег псевдо-фишинговые ссылки и предложения продать дамп.
Для выбора ближайших точек индекс btree полезен только для точек, но не для векторов.
В postgresql есть либо cube+gist
Либо сторонее расширение pgvector
Какой-либо из обозначенных проектов пал жертвой кризиса дефицита электронных компонентов 2020 ?