Техно Шаблон (Осотонел 2)

Посмотрел уже несколько обзоров на Poco F5. Слабоватые они (обзоры). Единственное что узнал значимое - что в Poco F5 Pro быстрее память по части чтения (значит, приложения будут быстрее загружаться из постоянной памяти в оперативную, т.е. запускаться будут быстрее), ну и троттлит он меньше. Остальное и так понятно из технических характеристик, ну и на@уй мне смотреть констатацию этих самых технических характеристик - не е@у, тупо впустую потраченное время. Жду дальше обзора от Лысого из MT.

объясняю ещё раз. Я не понимаю людей, которые аж наяривают на эту @уйню и на постоянке только быстрой зарядкой и пользуются. Ну, и вот, мне дали простой и понятный ответ в духе: "мне так по кайфу, @ули дое@ался, старый хрыч?". И, знаете что? Меня такой ответ более чем устроил. Почему он меня устроил? Да потому, что с телефоном в принципе должно быть по кайфу всё, иначе е@ал я в рот брать себе такой телефон. Если у вас другие вещи вызывают это самое ощущение "по кайфу", базара нет, значит, так и делайте. Если бы я сейчас занимался обзорами, без базара, специально бы для этих людей делал бы замеры по скорости заряда, хоть лично мне и пое@ать. Такие дела

Прочитал ваши комментарии, и вот ей богу, не могу понять, почему для некоторых из вас не вариант поставить телефон на зарядку телефон ночью, чтобы к утру он был уже заряжен. Вот надо некоторым целенаправленно игнорировать возможность медленной бережной зарядки телефона ночью за 5-8 часов, когда вы один хер спите и не пользуетесь телефоном. Зачем аккумулятор беречь и медленно заряжать, если его можно изнасиловать, заставив его впопыхах с утра восполнять свой заряд? Такая же логика? Точно такой же вопрос про дозарядку днём: зачем именно быстрой зарядкой заряжать его на работе/учёбе? Вы куда-то спешите с телефоном, когда на учёбе/работе? Вот не могу понять, зачем именно быстро это делать. От быстрой зарядки аккумуляторы не только много тока принимают, отчего изнашиваются быстрее, но и сильно греются, отчего их износ только усугубляется. При медленной зарядке таких проблем нет. По вопросу влияния быстрой зарядки до@уя исследований уже проведено, и всё равно люди клюют на эту маркетинговую @уйню, которую навязали потребителям компании, и насилуют свои аккумуляторы, когда в этом нет никакой необходимости. Вот сколько не пытались мне объяснить, зачем это надо, я так и не понял. Мне по@уй, сколько телефон будет заряжаться: будь то 1, 3 или даже 5 часов. Я всё равно сплю в это время, так почему меня должно е@ать, сколько часов из тех, что я спал, было потрачено на зарядку. А если телефону не хватает заряда до вечера, и нет возможности медленно его заряжать в течение дня, может, такой телефон в принципе лучше не брать себе?

Не понимаю я надр@чивания блоггеров на мощность зарядки у смартфона. Зрителей это вообще волнует? Меня вот, к примеру, на это пое@ать от слова совсем. Ну, окей, зарядился он, допустим, не за 1.5 часа, а за 1 час. Что от этого поменялось? Ровным счётом, ни@уя. Всё равно его ставить на зарядку ночью, либо ставить его на зарядку ещё и днём на учёбе/работе. От того, что он эту зарядку восплоняет быстрее, ничего толком не меняется, кроме того, что у вас аккумулятор быстрее дохнет и раньше его менять надо будет. Не, я бы понял, если бы в телефоны пихали зарядку в 120 Ватт, и с ней бы трубки заряжались не за 1.5 часа, а за 10 минут. Но на деле же даже те трубки, которые поддерживают быструю 120 Ватт зарядку, применяют эти 120 Ватт в полной мере лишь в течение минуты или около того, а затем скорость заряда падает до 80 Ватт, до 60, до 40, 20, 10 и т.д., и конечный результат от аналога в 27 или 33 Ватта отличается не в 4 раза, а на 15-20%. В чём смысл тогда надра@ивания на эти быстрые зарядки? Вот честно, не е@у. Либо аккум сдохнет к @уям за несколько десятков циклов заряда, выдав максимальную скорость зарядки с сопутствующим износом аккумулятора, либо зарядка будет "троттлить", чтобы сберечь аккум, и один @уй между 120 Ватт и +- 30 Ватт какой-то многократной разницы не будет. Всё это мощное питалово нужно для ноутбуков, но никак не для телефонов. Равно как и X1/X2/X3 ядра на@уй не надо в телефоны пихать, тем более в количестве 2 штук и более.

Ну, всё, жду обзора от Лысого на Rog Phone 7 и на Poco F5 (Pro). https://mobiltelefon.ru/post_1683639606.html Если новый Poco нормальный, возьму его, как появится тут в местных магазинах. Из Китая его заказывать не возьмусь. Лучше уж тут куплю с наценкой, но также в случае чего смогу вернуть его, если он с проблемами окажется. Прошку брать или обычную версию - потом решу, когда обзоры гляну. Если херовым вышел, возьму Rog Phone 7. А если и он херовым вышел, буду тут в местных магазинах искать нераспроданные остатки Poco F3.

Слухайте, мне от вас денег не надо. У меня с этим, благо, проблем нет. Даже благодарности не надо. Если лайков будет больше, мне, конечно, будет чуть приятнее, хоть не жалко людям, значит, на кнопку ткнуть. Но хоть бы кто уже опробовал разок скрипт и отписал, что классно, или, напротив, что работает хреново или не работает. Лишь один человек отписал, что хочет его попробовать потом. Ну и всё. Такое ощущение, что только мне не пое@ать на реальные более-менее объективные цифры, а всем остальным это на@уй не надо и их устраивает слепая вера словам популярных нынче техноблоггеров о том, что лагов нет, но вы держитесь.

Итак, вначале вы указываете, хотите ли вы первой строкой, которую он выводит, видеть время отрисовки по последним <= 120 кадрам. Если нет, вам нужна только статистика, а не время каждого такого кадра, выставляйте 0 вместо 1. Далее происходит проверка версии Android. У меня на Poco F3 и Pixel 6 Pro с Android 12 и Android 13 определение текущего запущенного приложения и его окошка (Activity) проходило по параметру topResumedActivity, но вот на Pixel 2 XL со старым Android 11 такой херни нету (там вместо этого mResumedActivity). Поэтому я сделал, чтобы на Android 12+ он брал topResumedActivity, а на более ранних версиях скрипт хватается за mResumedActivity. Если у вас он ничего не определяет, правьте эту хрень сами. Какое название параметра вам нужно искать, вы можете понять, выполнив эту команду: dumpsys activity activities | grep -i $ResumedActivity Далее я беру куски времени кадра и складываю их в одну нормальную цифру и округляю её. Зачем что-то складывать? Ну, дело в том, что Android не пишет вам просто время кадра в мс. Это информация для разработчиков, и она разбита на 4 составляющие, т.е. вместо одного числа мы видим 4 разных числа, отражающих время, затраченное на каждый из этапов отрисовки кадра. Чуть подробнее об этом можете прочитать в документации Google в статьях "Inspect GPU Rendering speed and overdraw" и "Analyze with Profile GPU Rendering". Только эти статьи Google не обновляли дохреналиард лет, и они с сегодняшним Android не особо стыкуются, но общее понимание, тем не менее, они дают. Я - не разработчик, и мне глубоко наплевать, почему тот или иной кадр отрисовывался долго. Мне важно знать конченый результат, т.е. общее время, затраченное на отрисовку кадра, а не то, из каких компонентов он складывается. Поэтому мой скрипт эти 4 показателя складывает в один, округляет до целых и выплёвывает затем одной строкой. Как я уже писал выше, это отключаемо переключением опции showframes в 0. Далее скрипт цепляет общее число отрисованных кадров (с момента последнего сброса статистики), перцентили, которые я уже объяснял ранее, ну и гистограмму. Гистограмму скрипт чистит, оставляя только те значения, время которых соответствует реально отрисованным кадрам (никаких мс с 0 кадров вы более не увидите), ну и в конце он сбрасывает статистику. Зачем её сбрасывать? Чтобы листать контент и не мешать вместе статистику, скажем, при просто пролистывании контента, и статистику при зумировании фотографий, например. Вроде, всё описал. Если ещё что-то осталось непонятно, пишите, я разжую. Методика тестирования в этих ваших интернетах у меня всегда была, есть и будет открыта. Я вам не один из тех петухов блоггерских (не буду тыкать пальцем), который кичится, что у него своя мега уникальная методика, которой ни у кого нет, и делиться он ей не будет. Хватайте и повторяйте на здоровье. Только ссылку оставьте на источник и всё. Peace

Переписал набор команд (скрипт), который я использовал для замера времени, затраченного на отрисовку кадров в приложениях (или, по простому, для замера "лагов" в приложениях, в т.ч. системных). Да, он по-прежнему не работает с такими элементами интерфейса, как шторка уведомлений, но Activity приложений он захватывает корректно на Android 11, 12 и 13. На более ранних версиях его сейчас не проверял. Короче, скрипт сейчас лучше, чем то, что вы видели ранее на видео. Он немного фильтрует информацию и предсталяет её в более удобоваримом виде, а именно: не вываливает каждый кадр отдельной строкой, а собирает последние <= 120 кадров в одну строку и округляет их (никаких больше сотых долей миллисекунды типо 7.21 мс). В гистограмме он теперь оставляет только те цифры ms, которым хоть один кадр да соответствовал (т.е., если, к примеру, кадров с длиной в 4950 мс не было, то он и не покажет, что 4950мс=0). Сделал 2 варианта скрипта. Один - для винды (для cmd), а другой - для Linux (bash) и macOS (zsh). Тестировал скрипты на винде 10 (22H2), Ubuntu 22.04.2 и macOS 11.7.6. У меня всё ок было, проверяйте теперь у себя. Не имею никаких возражений, если захотите воспользоваться ими в коммерческих и некоммерческих обзорах, статьях, да чём угодно. Просто если воспользуетесь им, оставьте ссылку на этот пост в Телеге (или на тот, что выше со скринами), и тогда вопросов у меня к вам не будет. Работают оба варианта с приложениями, использующими стандартный View UI для отображения контента. Они не предназначены для игр, и они и не должны вам там никакой FPS показывать. Для игр используйте другие утилиты, коих навалом в этих ваших интернетах (да на Android 13 даже на пикселях есть встроенная игровая панель, чего уж там). Собственно, сами скрипты ниже. Windows: adb shell "showframes=1; echo; AndroidVersion=`getprop ro.build.version.release`; if [[ $AndroidVersion -ge 12 ]]; then ResumedActivity='topResumedActivity'; else ResumedActivity='mResumedActivity'; fi; appname=`dumpsys activity activities | grep -i $ResumedActivity | cut -d '{' -f 2 | cut -d '/' -f 1 | cut -d ' ' -f 3`; frames=`dumpsys gfxinfo $appname 2>&1 | grep -E '^[[:space:]]+[[:digit:]]\..*' | awk '{sum=0; for (i=1; i<=NF; i++) { sum+= $i } printf(\"%.0f\n\", sum)}'`; if [[ ! -z $frames ]]; then if [[ $showframes -eq 1 ]]; then echo Ms at up to 120 last frames: $frames; fi; dumpsys gfxinfo $appname 2>&1 | grep -i -E 'Total frames rendered|th percentile'; histogram=`dumpsys gfxinfo $appname 2>&1 | grep -i -E '^HISTOGRAM: ' | sed 's/HISTOGRAM: //' | tr ' ' '\n' | grep -v 'ms=0'`; echo $histogram; echo $appname && dumpsys gfxinfo $appname reset 2>&1 >/dev/null; else echo 'Unable to get gfxinfo. Please, check that you have enabled Profile HWUI rendering'; fi; echo" Linux / Mac: adb shell 'showframes=1; echo; AndroidVersion=$(getprop ro.build.version.release); if [[ $AndroidVersion -ge 12 ]]; then ResumedActivity="topResumedActivity"; else ResumedActivity="mResumedActivity"; fi; appname=$(dumpsys activity activities | grep -i $ResumedActivity | cut -d "{" -f 2 | cut -d "/" -f 1 | cut -d " " -f 3); frames=$(dumpsys gfxinfo $appname 2>&1 | grep -E "^[[:space:]]+[[:digit:]]\..*" | awk "{sum=0; for (i=1; i<=NF; i++) { sum+= \$i } printf(\"%.0f\n\", sum)}"); if [[ ! -z $frames ]]; then if [[ $showframes -eq 1 ]]; then echo Ms at up to 120 last frames: $frames; fi; dumpsys gfxinfo $appname 2>&1 | grep -i -E "Total frames rendered|th percentile" ; histogram=$(dumpsys gfxinfo $appname 2>&1 | grep -i -E "^HISTOGRAM: " | sed "s/HISTOGRAM: //" | tr " " "\n" | grep -v "ms=0"); echo HISTOGRAM: $histogram; echo $appname; dumpsys gfxinfo $appname reset 2>&1 >/dev/null; else echo "Unable to get gfxinfo. Please, check that you have enabled Profile HWUI rendering and that something is being rendered in View UI"; fi; echo' Ну и тут чуть вкратце поясню, как работает скрипт. Пример информации, которую он выводит, вы могли видеть выше на скриншоте.

Вечер наступил. Не забыл. Тут я распишу, как всем этим пользоваться, а сам скрипт пойдёт следующим постом (банально не хватило места в сообщении). Если будете снимать обзоры или писать статьи с использованием этого набора команд, пожалуйста, сошлитесь на этот пост в Телеге. Других просьб нет. Если просто оставите ссылку на этот пост, пользуйте скрипт как вам угодно. В комментах к этому или следующему посту разжую интересующимся, что делает каждая часть кода тут. Итак, что вам надо иметь заранее: adb (SDK Platform Tools) на компе. Я бы советовал брать 33-ую версию для винды / мака / линукса, т.к. последняя, 34-я, вышла косячной. Или добавьте его в переменные среды в PATH, или в начале команды замените adb на полный путь (C:\platform-tools\adb.exe, или хз, куда вы его распаковали). Вводите adb devices, проверяйте что устройство видно и выдавайте на нём разрешение на доступ по adb для компа. Смотрите на скрины. Вам надо разблокировать настройки разработчика. На всех оболочках это делается по-разному, гуглите как у вас. Выше пример с PixelOS на Poco F3. В настройках разработчика вам надо включить отладку по adb, а также включить "учёт времени работы HWUI" или "профайлинг HWUI" или "мониторинг HWUI", короче, без разницы. Эта штука по-разному зовётся в разных прошивках и в разных переводах, тут уж сориентируйтесь как-нибудь. Там вам надо выбрать между двумя опциями "на экране в виде полос" или "в adb shell dumpsys gpuinfo". Если вам хочется на экране видеть все эти наложения, графически отражающие время кадра, выбирайте "на экране в виде полос". Если вам пофиг и вам чисто в Терминале на компе хочется увидеть цифры, выбирайте последний пункт. Всё, дальше на телефоне, открываете любое приложение, листаете какой-то контент, вставляете команды и жмёте Enter. Больше ничего делать не надо. После каждого ввода команд будет сброшена статистика, так что при каждом последующем вводе вы будете видеть статистику только по последним действиям. Сам скрипт в следующем посте, сюда он уже не влез.

Если вам интересно моё мнение, которое, опять же, я не планирую никому навязывать, вот оно: Pixel 4 (XL) был последним хорошим пикселем. Всё, что вышло после него - полнейшая @уета. Я это своё мнение постарался подкрепить объективными показателями. Там уж соглашаться со мной или нет, сами для себя решайте. Единственная моя просьба к вам: не будьте мудаками и не навязывайте мне, на что мне тратить свои кровно заработанные деньги, как делали тут некоторые индивиды в комментах. Не надо мне часами рассказывать, что я чересчур предвзят и что мне стоит ещё раз попробовать смартфоны Samsung, например. Спасибо, бл@дь, но я как-нибудь сам разберусь, что мне взять себе в постоянное пользование, и на что тратить свои деньги. Я тут не обзорами занимаюсь в свободное от работы время, а себе на постоянку ищу аппарат, напомню об этом. Тут просто делюсь своими мыслями и наблюдениями, пытаясь их как-то подкреплять, не более того.

Если вам он нравится, базара нет, я вам своё мнение не собираюсь навязывать. Я неоднократно говорил, что считаю, что хороший телефон - тот, который радует своего владельца. Если вас он радует, живите с ним в радость-сладость, 0 вопросов. Я тут описываю исключительно свой опыт взаимодействия с ним и стараюсь это подкреплять каким-то замерами и объективными показателями, цифрами. Надеюсь, для кого-то они окажутся полезны. P.S. Вечером, если не забуду, запощу тут небольшое пособие по тому, как проводить тест плавности интерфейса в приложениях (в т.ч. системных, типо, лаунчера, но это не работает в панелях по типу шторки уведомлений).

Если вам он нравится, базара нет, я вам своё мнение не собираюсь навязывать. Я неоднократно говорил, что считаю, что хороший телефон - тот, который радует своего владельца. Если вас он радует, живите с ним в радость-сладость, 0 вопросов. Я тут описываю исключительно свой опыт взаимодействия с ним и стараюсь это подкреплять каким-то замерами и объективными показателями, цифрами. Надеюсь, для кого-то они окажутся полезны. P.S. Вечером, если не забуду, запощу тут небольшое пособие по тому, как проводить тест плавности интерфейса в приложениях (в т.ч. системных, типо, лаунчера, но это не работает в панелях по типу шторки уведомлений).

Подытожим проблемы, с которыми я столкнулся на Pixel 6 Pro, и из-за которых я его сдал обратно в магазин: 1. Плохо ловит сотовую сеть. Там, где я сейчас нахожусь, даже на Poco F3 со Snapdragon 870 и его интегрированным X55 5G модемом, ловит сеть довольно херово, так что я думал "ну, хуже уже не будет". Pixel 6 Pro в этом плане меня удивил, связь с ним - полнейшая катастрофа, и никакие Magisk-модули для улучшения сети не решают проблему кардинально. 2. Кошмарно работает с Wi-Fi и Bluetooth. Его модуль BCM4389, тот же, что установлен и в Pixel 6 (Pro), и в Pixel 6a, и в Galaxy S21, работает просто отвратительно. Когда устройств подключено больше 2 (допустим, к фитнес-браслету и наушникам добавляется ещё планшет или телефон на раздаче интернета по Bluetooth), если отойти от 3-го/4-го устройства и вернуться обратно, он показывает что якобы соединение есть, но его на деле нет. Старое соединение не разрывает, новое не устанавливает, никаких устройств он больше не видит. Даже если подключены лишь 2 устройства по Bluetooth, когда я приезжал на работу, он мне показывал, что я, якобы, подключен к домашней Wi-Fi сети (каким @уем, бл@дь, у меня от дома до работы - 40 км), и разъединиться от неё не давал, подключиться к рабочей сети не позволял. И так пока не перезагрузишь телефон. А потом всё по-новой. 3. Быстро разряжается. За 3.5 часа работы экрана он у меня садится на 83%. Это без игр, без тяжёлой нагрузки. Так, браузер, YouTube, музыка в фоне, чаты в Телеге и т.д. И да, это с тёмной темой. Я встаю в 5:40 утра, и мне его хватает лишь до часу-двух, до вечера не доживает вот вообще никак. 4. Тормозит при обычном повседневном использовании. Я ранее показывал с замерами времени кадра, что Pixel 6 Pro в сравнении с Poco F3 на Pixel Experience тратит в 1.5 раза больше времени на отрисовку кадров в обычных приложениях при обычном использовании. Т.е. FPS у него ниже, просадки у него случаются чаще, явные тормоза у него возникают раз в 10 чаще, чем у Poco F3, и тормоза эти куда сильнее, ощущаются они жёсче. Вы можете не замечать этих проблем, если у вас Pixel 6a с экраном 60 Гц, но вот на 6 Pro при 120 Гц эти проблемы чересчур отчётливо видны. Тут это вызвано, в первую очередь, хреновым планировщиком задач, который @уй пойми как вообще определяет, на каких ядрах, как и когда решать те или иные задачи. 5. В играх троттлит что 3.14здец. Всему виной - безумно горячие X1 ядра процессора. У него и так задран порог срабатывания троттлинга по процу (TJmax) до 90-94 градусов (там 2 фазы троттлинга). Но даже если вы "отсрочите" (повысите порог срабатывания) ограничитель на основе температуры батареи, вы всё равно не увидите больше 30 FPS в Genshin спустя 5+ минут. У него проц греется до 90+ градусов уже через 2 минуты, и с этим ничего не поделать, от этого троттлинга не избавиться (и не стоит от него избавляться в общем-то, иначе сожжёте телефон к @уям). Да и если поднять порог срабатывания троттлинга на основе температуры батареи, она начнёт греться аж до 50 градусов, рамки телефона начнут обжигать вам руки, и всё, что вы с этого получите - рост FPS в Гене с 10-15 до 25-30. 6. Далеко не со всеми NFC-чипами работает. Например, не работает с картами Тройка, выпущенными примерно с 2021 по 2022 годы (точные даты уточняйте по серийному номеру). Не даёт их ни считать, ни пополнить. Проблем то у него может и больше намного, но вот те, что я заприметил. Если на 6-й пункт похер, можно новую Тройку взять 2023-го года выпуска и проблемы не будет, то вот проблемы с производительностью и плавностью в повседневных приложениях, малое время работы от аккумулятора, плохую работу с модулями связи (сотовой связи, Bluetooth и Wi-Fi), ужасную производительность в играх и т.д., я никак не могу проигнорировать. Ну и да, когда сталкиваешься с таким дерьмом, понимаешь, что Poco F3 так-то очень даже хорошим телефоном был. Не на MIUI, конечно, я этой оболочки рот е@ал, но вот ранее на Pixel Experience 12.1 и сейчас на PixelOS 13 он работает намного лучше оригинального Google Pixel 6 Pro. Такая вот история

По графическому ускорителю (GPU): троттлинг в 38% даже после задействования того самого Magisk-модуля для "отсрочки" троттлинга по батарее. По батарее он при этом нагрелся до 50 градусов................ Мде. Телефон при этом держать в руках крайне некомфортно. Его металлическая рамка начинает жечь ладони при таком нагреве. Да и для аккумулятора такая температура не так уж и рекомендована. Для сравнения я прикладываю следом результаты Xiaomi Poco F3 на PixelOS 13 с производительным режимом. На MIUI этот производительный режим активируется в Game Turbo, а на сторонних прошивках на базе AOSP (типо Pixel Experience 12.1 или Pixel OS 13) можно воспользовался утилитой F**k MIUI thermal, что я и сделал. Я выбрал там профиль Performance (можно и профиль F#@k выбрать, если хотите сжечь аппарат к @уям, мне же хватило и просто Performance). Раз уж я решил сравнивать аппараты "на максималках", со всеми доступными твиками, на Poco F3 я ещё понизил напряжение графических ядер при помощи Konabess. На всех частотах выставил минимальное напряжение, при котором аппарат работает стабильно и никаких артефактов не возникает. Так, на максимальной частоте (670 МГц), снизил напряжение на 107 мВ, выбрав профиль "SVS_L2" вместо "NOM_L1"). Я бы также андервольтнул и графический ускоритель в Pixel 6 Pro, но увы и ах, инструментов для подобных модификаций тупо нету для него. И Poco в итоге выдал практически 100% стабильность (99.5%). Аккумулятор нагрелся лишь до 42 градусов, и итоговая производительность у него вышла на ~30% (29.45%, если уж хотите дое@аться) выше, чем у Pixel 6 Pro. Такая вот @уета.

Ещё пару недель назад хотел это тут запостить, ну да хер бы с ним, запощу сейчас. Мне стало интересно оценить то, насколько вообще эффективно в случае с пикселем повышение порога срабатывания троттлинга по батарее, и почему в играх по типу Genshin после нагрева мы никак не видим 60 FPS даже с ним. Мне не удалось у него повысить порог срабатывания троттлинга у самих ядер процессора по их же температуре (TJmax), но нахер это надо, учитывая, что там и так порог задран аж до 90 градусов. Замер температуры батареи проводил при помощи Simple System Monitor. Итак, к результатам троттлинг-теста. Скрин 1 - Pixel 6 Pro без Magisk-модуля. Батарея греется до 40 градусов и начинается троттлинг. Троттлит при этом всё. Вообще всё, даже слабые ядра A55, и троттлит аж в 1.5-2.5 раза. У мощных ядер X1 частота падает с 2.8 ГГц до 1.4 ГГц, у средних ядер A76 - с 2.25 ГГц до 1 ГГц, а у A55 ядер - с 1.8 ГГц до 1.2 ГГц. Учтите, что это троттлинг-тест одного лишь CPU, а в играх, где задействован ещё и GPU, троттлинг ещё жёсче. Оттого то в Genshin Impact FPS падает с 60 до 10-15 в некоторых сценах, и это независимо от настроек графики. Скрин 2 - Google Pixel 6 Pro с тем самым Magisk-модулем для "отсрочки" троттлинга по батарее. Но на Tjmax он не влияет и у X1 ядер всё ещё частота скидывается в 2 и более раз - с 2.8 ГГц до 1.27 ГГц. Также частота просела у A76 ядер на 20% - с 2.25 ГГц до 1.83 ГГц. С учётом "жёсткости" троттлинга у X1 ядер, предположу, что у X1 ядер он так силён из-за активации 2-й фаза троттлинга, которая активируется при нагреве до 94+ градусов у ядер. В таких играх, как Genshin, колоссальное значение имеет производительность производительность первых 2-4 ядер. Учитывая то, что с 4 ядрами производительность не сильно отличается от той, что с двумя, т.е. A76 ядра Google очень плохо задействуют в связке с ведущими X1 ядрами, а те самые ведущие ядра троттлят в 2+ раза, Думаю, теперь понятно, почему Pixel 6 Pro категорически не подходит для игр.

Из-за всей этой истории с плохим с аппаратурой части Google Pixel 6 Pro, подумываю себе в очередной раз Xiaomi/Poco взять и прошить на Pixel Experience / PixelOS. Как показала практика, лучше уж так сделать, чем взять оригинальный Google Pixel с его Pixel UI. Дождусь релиза Poco F5, а там видно будет. Его китайская версия под названием Redmi K60 уже была представлена и, вроде как, по аппаратурой части там всё ок. Ну, тут либо его брать, либо Asus Rog Phone 7. Будем посмотреть

Кое-что ещё не давало мне покоя. Почему Google Pixel 6 Pro так тормозит? Уж при обычном пролистывании телеги троттлинг не должен иметь места. Так в чём же дело? Зная, что Google Tensor G1 - это модифицированный Samsung Exynos 990, первое, что пришло мне на ум - это проблемы с бл@дским планировщиком задач. У Exynos эти проблемы были всегда. И так я решил это проверить: запустил Mobile Linpack на Pixel 6 Pro с Tensor G1 в 1/2/3/4/5/6/7/8 потоков. На Poco F3 я давно проводил этот тест на MIUI 12.5.3 (Android 11), ещё до приобретения его для себя, когда я занимался обзорами гаджетов. Результаты выше на скриншотах и на графиках. Скрин 1 - Pixel 6 Pro, скрин 2 - Poco F3. Вкратце по выводам: Pixel 6 Pro не понимает, какие ядра ему задействовать, когда задача падает на 3 потока. Как мне кажется, вместо того, чтобы использовать 2 жирных X1 ядра и 1 среднее A76 ядро, он использует 2 средних ядра A76 и 1 жирное ядро X1. А если же задача падает на 4 ядра, мы имеем +- ту же производительность, что с 2 ядрами. Почему? Походу, срабатывает защита от перегрева, т.к. X1 ядра и без того очень горячие, а тут ещё 2 A76 ядра с ними вместе работают. В итоге он с 4-мя ядрами ни разу не быстрее, чем с 2-мя. А если задача падает на 5+ потоков, планировщик не понимает, куда её пихнуть, и в итоге пихает её исключительно на энергоэффективные A55 ядра. И в результате у нас производительность АЖ В 1.5, СУКА, РАЗА, ниже, чем, когда её же мы пытаемся решать на одном ядре Cortex-X1. Поэтому, чем больше фоновых процессов, тем больше Pixel 6 Pro тормозит. В случае же с Poco F3, такой херни нет. Да, у Snapdragon 870 падает производительность, когда используются 5-6 ядер вместо 1-4, но когда потоков 8 и более, производительность уже приходит в норму. А в случае с Tensor любое число потоков, превышающее 4 (хоть 5, хоть 8), ведёт к колоссальному падению производительности. И вот так при большом количестве фоновых задач Pixel 6 Pro оказывается В 4 РАЗА ХУЖЕ чем Poco F3. Такая вот @уета. Позже будет ещё пара слов про троттлинг.

В начале прошлой недели я попробовал сдать обратно в магазин этот поганый Google Pixel 6 Pro. Вчера мне пришло СМС, чтобы я подъехал в магазин по результату своего обращения. Подкачу к ним на днях. Если не сделают возврат, продам на вторичке, потеряв часть его стоимости. @ули делать... Перед тем как вам поведать кое-что интересное про троттлинг, хотел бы затронуть один момент, касательно порога срабатывания троттлинга у Pixel 6 Pro. Нет, я говорю не про троттлинг по батарее. Меня сперва заинтересовал троттлинг процессора, который не зависит от температуры других компонентов, это троттлинг по его собственному пороговому значению (TJmax) срабатывания троттлинга. Я полез в телефон при помощи ADB, и увидел, что у Pixel 6 Pro TJmax с завода - 90 градусов. Вернее, у Cortex-X1 ядер он составляет 90 градусов (BIG кластер), у A76 ядер - 90 градусов (MID кластер), а у A55 ядер - 95 градусов (LITTLE кластер). Тут же на скрине видно, что у графического ускорителя тоже TJmax установлен в 90 градусов. Там несколько разных пороговых значений, т.е. чем выше температура, тем сильнее троттлинг, но вопрос в том, когда он в принципе начинается (90 градусов). Если верить сообщениям пользователей на форуме XDA, у Pixel 7 Pro TJMax ещё выше - бл@дские 100 градусов. Т.е. вся разница в производительности между Pixel 7 Pro достигнута всего 2 факторами: повышение порога срабатывания троттлинга (по процессору и по батарее) и апгрейд среднего кластера ядер с A76 на A78. Всё. Если у вас Pixel 7, имейте в виду, что быстрее он потому, что сдохнет раньше. Ну, живите как-то с этим и не напрягайте его особо. Корпус же греется не сильно, разве что рамка горячая что 3.14здец (и то только если воспользоваться Magisk-модулем для повышения порога троттлинга по батарее). Но оно и понятно почему: Google очень @уёво отводит тепло от процессора на другие компоненты. Потому корпус чуть тёплый, когда внутри просто адское пекло. P.S. 3.14здец, конечно, бл@дь, 100 градусов в телефоне, я е@ал. Конченные, бл@дь.

Прошил я этот persist раздел. И.... Ни@уя не поменялось. Wi-Fi как не работал, так и не работает. Понятно, короче, помер товарищ физически. Нахожусь я сейчас там, где толковых недорогих мастерских, обслуживающих этот телефон - нема. Ищем другой, @ули делать.....

Мне тут в комментариях к предыдущему посту товарищ M E16 отписал, что можно попробовать прошить раздел persist. Сперва шьёмся на MIUI, затем шьём пустой раздел persist, который отвечает за Wi-Fi, Bluetooth и некоторые датчики. Там суть в том, что, если прошить пустой раздел persist, MIUI сама восстановит его, заполнит необходимыми данными. Ну, чо, проверим вечером. Авось, Poco нормально заработает. Если оживёт Wi-Fi, я его всё е@ал, на@уй никакие другие смартфоны вообще рассматривать не буду. Меня устраивает он на 85-90%, ну и всё, е@ал я в рот из-за 10-15% себе голову ломать и телефон менять. Позже сегодня закину сюда результаты троттлинг-теста. То, как тест с замером времени кадра в приложениях проводить, напишу уже завтра тогда (мне будет чем заняться вечером, а время у меня ограничено).