В цивилизованных странах принято ездить на такси, с шашечками и счетчиком.
Чисто дискретных систем нету чтобы так защищать генерацию из таймера по случайным событиям.
В андроид девайсах есть несколько источников аналогового шума.
Lavarnd говорит что она очень крута.
Посмотрите как печально работает qrngd — все потому что /dev/random такой какой он есть.
entropy_avail не отображает сколько байт ожидается на чтение.
к примеру — ты пытаешься прочитать 24 байта — а в настоящий момент есть только 16. entropy_avail будет 16. когда оно станет 24 то чтение завершится и entropy_avail изменится
Ну тоесть это нормально, что текущий софтовый генератор на 4х десктопных ядрах, при минимизации внешних событий 128 случайных байт «считает» более 7 минут?
Вы считаете что позициию «к пуговицам претензии есть?» правильной?
Получается что те кто критиковал андроид за фрагментацию таки правы.
С текущий /dev/random — даже если _все_ приложения будут вести себя «корректно» можно набрать критическую массу когда /dev/random не будет справляться (не считая того что сервер который начнет корректно дробать https может неожиданно усугубить ситуацию на стороне клиента).
Счас, если тормозит — ждать не надо — надо пальцем водить по экрану или громкость тапать )))
Я выше не зря написал что надо инфу от пользоватей систематизировать.
На телефоне может спокойто стоять и от оператора трэкер и от производителя и куча всяких приложений — которые, к примеру, шифруют данные. Малоли чего еще пользователь поставил?
Это все может оч радостно генерировать те самые тормоза (если аппаратный генератор не работает) ибо софтовый не сильно много бит в секунду может сгенерировать.
time dd if=/dev/random of=/tmp/rnd.txt bs=1 count=128
под вмварой за NAT — real 7m6.553s (!!!) (это у меня терпение лопнуло и я начал пробел нажимать)
на арм 200mhz (много чего сетевого на нем) — real 0m 42.37s
на dual xeon — real 2m3.688s (дофига пользователей)
Читал конечно же. И исходники /dev/random — ниже отписался.
Только позиция девелоперов VM это аналог «к пуговицам претензии есть?».
Сам далвик не дергает но вот приложения дергают. Как в том же кейсе человек пишет про то что торрент клиент «кладет» все — а с «дурной» (потомучтно не безопасно) программой вдруг все «поднимается».
Там же есть камент что гугломапсы перестают работать у некоторых (некоторые пишут что начинает быстрее работать) если не настоящим генератором пользоваться (что, как правильно заметили, означает что гугломапс _зависим_ от случайных чисел).
Кстати — /proc/sys/kernel/random/entropy_avail показывает текущий размер пула но не учитывает сколько данных из пула будет вычитанно (грубо говоря не видно очереди на чтение — там может быть запрос на 256 байт).
Вообще, после ковыряния в сорцах /dev/random волосики немного дыбом стоят.
В /dev/random счас пул энтропии набивается синхронно с событиями ввода (еще прерывания и диска) — и если ктото ожидает чтения из /dev/random то в общем его пнут когда данные наполнятся.
Тоесть у кого никакая прога особо /dev/random не читается — у тех чуть впустую проц работает и визуально ничего не видно, а у кого читает — у того I/O «проснется» слишком рано.
Посколько никто не читает из /dev/random по несколько бит — вот вам и лаги а не равномерное подтормаживание.
Это баг не андроида а матрицы где мы все существуем — приблуда просто повышает в матрице энтропию и начинаются тормоза рендеринга бытия, но поскольку рендеринг мобил работает на фиксированной скорости, нам кажется что они работают быстрее.
Вот и баг есть — code.google.com/p/android/issues/detail?id=42265. Поскольку никто из девелоперов не сообразил что надобы на гуглодоках собрать версии ядер, прошивок, железяк\проца (в частности WiFi — а возможно и AP), запущенного софта — а некоторые так прямо говорят что раз на моем девайсе с фиг знает какой прошивкой все без изменений то бага нету — то это 100% матрица пытается защититься.
Чисто дискретных систем нету чтобы так защищать генерацию из таймера по случайным событиям.
В андроид девайсах есть несколько источников аналогового шума.
Lavarnd говорит что она очень крута.
Посмотрите как печально работает qrngd — все потому что /dev/random такой какой он есть.
к примеру — ты пытаешься прочитать 24 байта — а в настоящий момент есть только 16. entropy_avail будет 16. когда оно станет 24 то чтение завершится и entropy_avail изменится
Получается что те кто критиковал андроид за фрагментацию таки правы.
С текущий /dev/random — даже если _все_ приложения будут вести себя «корректно» можно набрать критическую массу когда /dev/random не будет справляться (не считая того что сервер который начнет корректно дробать https может неожиданно усугубить ситуацию на стороне клиента).
Счас, если тормозит — ждать не надо — надо пальцем водить по экрану или громкость тапать )))
На телефоне может спокойто стоять и от оператора трэкер и от производителя и куча всяких приложений — которые, к примеру, шифруют данные. Малоли чего еще пользователь поставил?
Это все может оч радостно генерировать те самые тормоза (если аппаратный генератор не работает) ибо софтовый не сильно много бит в секунду может сгенерировать.
time dd if=/dev/random of=/tmp/rnd.txt bs=1 count=128
под вмварой за NAT — real 7m6.553s (!!!) (это у меня терпение лопнуло и я начал пробел нажимать)
на арм 200mhz (много чего сетевого на нем) — real 0m 42.37s
на dual xeon — real 2m3.688s (дофига пользователей)
Кто сделает /dev/random benchmark app?
Только позиция девелоперов VM это аналог «к пуговицам претензии есть?».
Сам далвик не дергает но вот приложения дергают. Как в том же кейсе человек пишет про то что торрент клиент «кладет» все — а с «дурной» (потомучтно не безопасно) программой вдруг все «поднимается».
Там же есть камент что гугломапсы перестают работать у некоторых (некоторые пишут что начинает быстрее работать) если не настоящим генератором пользоваться (что, как правильно заметили, означает что гугломапс _зависим_ от случайных чисел).
Кстати — /proc/sys/kernel/random/entropy_avail показывает текущий размер пула но не учитывает сколько данных из пула будет вычитанно (грубо говоря не видно очереди на чтение — там может быть запрос на 256 байт).
Вообще, после ковыряния в сорцах /dev/random волосики немного дыбом стоят.
Тоесть у кого никакая прога особо /dev/random не читается — у тех чуть впустую проц работает и визуально ничего не видно, а у кого читает — у того I/O «проснется» слишком рано.
Посколько никто не читает из /dev/random по несколько бит — вот вам и лаги а не равномерное подтормаживание.
Вот и баг есть — code.google.com/p/android/issues/detail?id=42265. Поскольку никто из девелоперов не сообразил что надобы на гуглодоках собрать версии ядер, прошивок, железяк\проца (в частности WiFi — а возможно и AP), запущенного софта — а некоторые так прямо говорят что раз на моем девайсе с фиг знает какой прошивкой все без изменений то бага нету — то это 100% матрица пытается защититься.
На сколько он автономен или «живет» только с TestLink? Что он может и пр. пр.
Как 1+1 redundancy для контроллера сделать?