A OnePlus magyarázza, hogy miért fojtja vissza a CPU-t számos alkalmazás esetén

Mobil, Tablet, Okosóra

A OnePlus-t azon kapták, hogy bizonyos alkalmazások futtatása esetén visszafojtja a CPU teljesítményt. A mobiltelefon gyártó hivatalosan reagált a vádra egy "Insight into OnePlus 9 series processor and app optimization" fórumbejegyzésben, aminek az a lényege, hogy karbantartanak egy alkalmazás-listát, listán szereplő alkalmazásokat pedig megpróbálják optimalizálni. Mivel véleményünk szerint ezeknek az alkalmazásoknak túl sok a Snapdragon 888 teljesítménye, az akku kímélése és a melegedés elkerülése érdekében ezen alkalmazások futtatásakor visszaveszik a chip teljesítményét:

The OnePlus R&D team also maintains a list of applications – based on the most popular Google Play Store apps – that we try to optimize, including some of the apps you know and love like Chrome, Twitter, Zoom, WhatsApp, Facebook, Instagram, Snapchat, YouTube, Discord, Microsoft Office plus our own apps. All of this optimization is only finalized after our testing team makes sure the actual user experience is not negatively affected.

Részletek itt és a fórumbejegyzésben.

( Addam2 | 2021. 07. 13., k – 11:54 )

az akku kímélése és a melegedés elkerülése érdekében

Miután az iPhone-okra kártérítést kellett fizetni ezért, ők is megcsinálják, ugyanarra hivatkozva. Érdekes.

Az nem úgy volt, hogy az akku öregedésével lassították a készüléket, mert a fáradt akku esetleg nem bírta volna kiszolgálni a terhelési csúcsokat, így a készülék instabillá válhatott? Itt látszólag másról van szó: bizonyos alkalmazásoknak nem engedik, hogy teljes mértékben kihasználják a CPU-t azért, hogy egy töltéssel hosszabb ideig üzemeljen a készülék. Pl. ha egy weboldalon van valami animáció, amivel a Chrome 100%-on pörgetné a CPU-t, akkor kivesznek alóla valamennyi CPU időt. Ettől az animáció még fut, csak mondjuk nem 60FPS-el, hanem 30-cal. Az eset akkor lenne hasonló, ha a felhasználói élményt rontanák a korlátozások, ezzel új, elvileg gyorsabb készülék vásárlására buzdítva. A közlemény szerint ilyesmi nem történik, de majd független tesztelők jól megmondják.

Tudtommal ezeket a Frankenstein CPU-kat pont így tervezik: a nagy teljesítményű magokon fut, aminek kell, a lightosabb dolgok meg mennek a gyengébb, de kisebb fogyasztású magokon. Szerintem soha senki nem titkolta. Ettől még a funkciót akár ki is vezethetnék a GUI-ra, mondjuk az akku használatot mutató felületen egy apponkénti csúszkaként, amivel beállíthatod, hogy egy-egy app spórolós vagy gyors legyen. De ezt is csak azért, hogy utána az Apple-nek két iOS verzióval később legyen mit új featureként az ujjongó közönség elé vinni ;)

értelmezhetetlen a hozzászólásod. segítek:

A OnePlus-t azon kapták, hogy bizonyos alkalmazások futtatása esetén visszafojtja a CPU teljesítményt. A mobiltelefon gyártó hivatalosan reagált a vádra egy "Insight into OnePlus 9 series processor and app optimization" fórumbejegyzésben, aminek az a lényege, hogy karbantartanak egy alkalmazás-listát, listán szereplő alkalmazásokat pedig megpróbálják optimalizálni. Mivel véleményünk szerint ezeknek az alkalmazásoknak túl sok a Snapdragon 888 teljesítménye, az akku kímélése és a melegedés elkerülése érdekében ezen alkalmazások futtatásakor visszaveszik a chip teljesítményét:

szerintem ez nem egyenlő a big.LITTLE koncepciójával.

én csak azon csodálkozom, eddig azt szajkózta itt minden apple hater, hogy androidon legalább ezeket lehet tudni, meg van MINDENRE IS egy kapcsoló és a felhasználó dönthet mindenről is. most akkor mégse? :( na pasztmeg. ezek se jobbak mint a rothadt megrágott almás cég.

értelmezhetetlen, hogy mit nem értesz.

Az oneplus karbantart egy listát, amikhez gyors a snapdragon 888, és feleslegesen számoltatja a magokat maximumon, valószínűleg a felhasználói élmény nem lesz tőle jobb. 

ezt nem beszántani, hanem fejleszteni, esetleg szerkeszthetővé kellene tenni. van olyan, hogy egy program sokat eszik. Mondjuk a google play services, meg ilyenek.

Nem. Az EU-nak lépéseket kellene tennie a forgalomba kerülő termékek dokumentálásáért. Akkor is, ha emiatt az EU lemaradna a korszerű és értelmetlen sietségben*. Kezdetnek megfelelő lenne, ha a gyártóknak elérhetővé kellene tenni az alkatrészlistát robbantott ábrával, és a listában egy normál metrikus anyára nem hivatkozhatnának csak gyári cikkszámmal és "anya" elnevezéssel, hanem az iparban használatos tulajdonságait is fel kellene tüntetni (metrikus méret, szakítószilárdság, alapanyag, stb., ill. ha különleges szerepe van, pár szóban fel kellene hívni rá a figyelmet). Szoftvereknél a jogszabály hatálybalépése után tíz évet adnék a teljes dokumentáltság elérésére. Az EU által meghatározott szabványos formában dokumentálni kellene a működést (beleértve a használt fájlformátumokat és protokollokat), a funkciókat és a változásokat, és a gyártó mellett az EU is hosztolná ezeket. Természetesen csak olyan szoftverek (beleértve a libeket) esetén, amelyek önállóan vagy termék részeként kereskedelmi forgalomba kerülnek az EU-ban, vagy az EU területén a közszférában használják, vagy az EU területén (ingoványos) olyan szolgáltatást nyújtanak a segítségével, amiért pénzt kérnek és/vagy ami során személyes adatokat kezelnek. Azelőtt kellene valami hasonlót lépni, mielőtt egy sima alsógatya is az IoT része lesz.

* ™ :)

:)

Ez nagyon jó lenne. Pluszban felvetném a right to repairt is, hogy legyen lehetőségem megjavítani a termékemet. 

Pl a 2 éves oneplus 7 telefonom tökéletes, de már support az év végétől nem lesz hozzá. Csak azért nem fogok új telefont venni, mert mindenki ezt teszi.

Volt egy 15 éves TDK hangszóróm, ami elromlott. Szétszedtük és elromlott a tápja. Írtam a TDK-nak ahol a sales csávó csodálkozott, hogy ők gyártottak ilyet anno (1996-ban), de nem tudott segíteni, hogy milyet is kellene venni bele. Van egy fanatikus kollégám, aki ennek ellenére megcsinálta ( a tápegységen olyan számok szerepeltek, amit semmihez sem tudtam kötni.

A hangszóró azóta is működik.

Akkor is, ha emiatt az EU lemaradna a korszerű és értelmetlen sietségben*.

Tech-ben az EU már most sem versenyképes, igazából sokat nem veszítenénk. Kis szerencsével az EU lehetne az új Japán, a megbízható, tartós tech-cikkekkel. A gyakorlatban azért inkább arra fogadnék, hogy a semmihez sem értő, az állam csöcsén lógó hadseregnyi bürokrata ezt nem tudná lemenedzselni.

Konkurrens, időosztásos rendszereknél, azért a kernelnek elég sok beleszólása van, hogy az egyes programok mennyi processzoridőt kapnak. Párhuzamos rendszereknél meg hogy mennyi processzormagot. Azért jellemzően több futó alkalmazás van, mint mag.

És igen, ha egy dekóder 60 fps-t tud, de elég 30fps is nekunk, akkor lehet egy-két percnyi videót előre dekódolni és cache-elni, vagy csak várni, és hagyni mást dolgozni.

És ez mi, van benne felesleges (for int i=0; i< 1000000; i++) {} sor?

Majdnem. Mondjuk egy while(true) { if(event.occured()) { do_something() }; } majdhogynem ekvivalens a fentivel.

Tudok par ilyen alert management szolgaltatot, aminel ha megnyitod a status oldalt, akkor kb fel perc mulva notebookban felporognek maxra a ventilatorok es ugymaradnak. A telefon, meg par perc utan olyan forro lett, hogy alig birtad kezbentartani. Pl VictorOps volt ilyen egy idoben, amiota a Splunk atvette es rebrandelte ugy tunik kijavitottak. Az app-juk szerencsere normalisan volt megirva.

Régóta vágyok én, az androidok mezonkincsére már!

"na pasztmeg. ezek se jobbak mint a rothadt megrágott almás cég."

Ezzel az állítással nem vitatkozom. A feature szerintem jó, de legalább a power user közösség felé kommunikálni kellett volna, hogy van ilyen, hiba volt hallgatni róla. Az átlag felhasználót viszont szvsz felesleges ezzel terhelni.

"szerintem ez nem egyenlő a big.LITTLE koncepciójával"

Akkor szerinted hogyan kellene implementálni? A rendszer saját komponenseivel, amit a gyártó kézben tart viszonylag egyszerű a helyzet, de random alkalmazásokat nem lehet ész nélkül visszafogni, ellenőrzést igényel, hogy minek mi a hatása. Szvsz pont ezért van a lista, mert kézzel finomhangolják, hogy melyik app melyik funkcióját mennyire lehet megvágni, mielőtt az rontaná a felhasználói élményt (itt meg már belép, hogy ez erősen szubjektív, esetleg az app készítőjének üzleti érdekeit sérti, stb...)

Szerintem mikor ezt megláttad felderült az arcod "Lám lám ez az olcsó másolóvállalat is csal, ezek az androidos csókák mernek beszélni!?" 

Aztán rögtön rádörrentetted ezt, látszólag el se olvasva mi a szituáció, ezért felállítottad a párhuzamot. Pedig ugye ellentétben az Apple-el nem az a gond, hogy nem hagyják kihasználni a hardvert maradéktalanul, hanem az hogy bizonyos applikációkat optimizálnak. Azaz, attól te még úgy hajtod szét a telefonodat ahogy akarod. Nincs elvéve tőled "az 1000EUR telefon hardvere" (segítek: nem úgy ám mint az apple aki a telefont lassította le, talán azért is picit, hátha megfontolod veszel e újabbat) 

Mégis mi a baj valójában ezzel? Az, hogy egy listát készít az Oneplus amit optimizál amivel előfordulhat hogy konkurens appok közt okozhat élménybeli különbséget ezzel a gyorsabb app felé tolva a felhasználót. Ez a baj.  Tök mindegy, hogy valóban volt ilyen cél vagy a kommunikált jó szándék vezérelte, ha tart ilyen listát az publikálni kell és lehetőleg kikapcsolhatóvá tenni. 

Ne aggódj, nem vártam mást mint zsigeri reakciót..

Ettől az animáció még fut, csak mondjuk nem 60FPS-el, hanem 30-cal. Az eset akkor lenne hasonló, ha a felhasználói élményt rontanák a korlátozások

Másik topikban vérre menő vita ment a 120 Hz-en, a 30 fps már bőven érzékelhetően rosszabb felhasználói élmény az átlag usernek is. Más a két eset, de azért sok a hasonlóság szerintem, az indoklás meg ugyanúgy az akkukímélés.

Jó, akkor legyen 120 helyett 60, ha ettől jobb :) Csak egy példát mondtam.

Mint írtam, az Apple készülékeknél nem az akku kímélése volt az indok. A rövid ideig tartó nagy CPU terhelések nagy áramfelvétel lökésekkel járnak. Ettől egy elöregedett, megnövekedett belső ellenállású akku esetében a feszültség olyan mértékben leeshet, hogy attól a készülék kikapcsol, újraindul. Az Apple ezt akarta elkerülni a throttlinggal. A megoldás mellékhatása volt, hogy a készülék az új állapothoz képest folyamatosan lassult, aminek kellemes mellékhatása, hogy a frusztrált felhasználó egy "4 évig kurva jó volt ez a telefon, de már megöregedett, veszek egyet a mostani generációból" felkiáltással ment az almás bolt elé sátorozni. A OnePlus megoldásánál a dobozból kibontás pillanatától állandó, de mesterségesen korlátozott a teljesítmény.

4 évig kurva jó volt ez a telefon, de már megöregedett, veszek egyet a mostani generációból" felkiáltással ment az almás bolt elé sátorozni.

Mondjuk én ezt úgy oldottam meg hogy bementem a westendbe és fél óra alatt 8k-ért kicserélték az aksit. Leadtam, elcsászkáltam a media markt-ba aztán átvettem a telefont és mentem haza.

Ne keverjük már össze ha valaki technikailag nem érti a dolgot az idióta fanatikussal. Utóbbiból amúgy van mindkét oldalon, de szerencsére ők csak egy hangos kisebbség.

Ezt a műveletet megcsináltam az 5S-el és az SE-vel is. Az SE-nél tudtam róla, az 5S-nél csak simán érezhetően gáz volt az üzemidő de alapvetően a telefonnal elégedett voltam, ezért cseréltettem.

Amúgy alapvetően az SE-vel se volt teljesítményproblémám, az akksi állapotánál azt írta hogy le tudja adni a csúcsteljesítményt, szóval nem ez volt a csere oka, ott is az üzemidő volt a fő szempont.

Így van. A fenti nem összekeverendő az Apple témájával, ahol is az alultervezett / öregedő akkuk miatti random iPhone kikapcsolásokat akarták szépségtapaszolni. Az Apple esetében bírósági ítélet mondta ki, hogy ezt ne.

De, aki nem hiszi, nyugodtan indíthat pert a OnePlus ellen. Majd a bíróság eldönti, hogy ez pont ugyanaz-e vagy teljesen más.

trey @ gépház

Ebben egyetértünk. Ellenben azért sem állna meg egy per a OnePlus ellen, mert ők nem egy hardveres defektet akartak elfedni, tehát a következő vagy akár soron kívüli OTA frissítéssel visszaállítják az eredeti állapotot. Akár arra is hivatkozhatnak, hogy csak egy regresszió volt. Az Apple ellenben nem tudta volna visszacsinálni a throttling-ot, mert akkor megint kikapcsolgattak volna az érintett iPhone-ok. Az Apple esetében muszáj volt akkucsere programot hirdetni, illetve, mivel ily módon akart csalni, jogos a bírság kiszabása is a bíróságok részéről feléjük.

A két eset összehasonlítása almát a körtével.

trey @ gépház

( harlequin | 2021. 07. 13., k – 15:11 )

Faszán lehet egy ilyen funkcióval régebbi telefonokat lassítani :)

“Any book worth banning is a book worth reading.”

( dyra | 2021. 07. 13., k – 20:44 )

Nocsak nocsak, hasonlóért az Alma perkált rendesen.

Így van, a 1- esetén is jár a bünti. Azt nem értik meg ezek a nagy techmultik, hogy itt nem a visszafojtással magával van baj, hanem ezt a user háta mögött teszik, sunyi módon, ez az eldöntjük titokban helyette, hogy neki mi a jobb, hiszen ezt mi jobban tudjuk, mint ő. A sunyisággal van baj. Ha ez csak egy extra, opcionális feature lenne, ami tájékoztatná a felhasználót, hogy hol tudja be/kikapcsolni, szabályozni, akkor teljesen oké lenne, akinek fontos lenne az akkudidő, bekapcsolná, akit a lassítás zavarna, kikapcsolná. Erről kéne az összes cégnek leszokni, hogy minden usert teljesen hülyének néznek, kivesznek minden beleszólást a kezéből. Valóban vannak egyébként nagyon antitalentum userek, nekik meg elég meghagyni valami basic setup módot, ott eldönthetik helyette, hogy mi a jobb neki, de mindig meg kéne hagyni egy expert setup vagy hasonló testreszabási lehetőséget.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( YleGreg | 2021. 07. 14., sze – 11:27 )

Nem ertem a problemat.

Aszondja, hogy karbantartanak egy listat. Ez a lista.txt a telefonon van, hiszen ott nezi meg az OS, hogy mi fut.

vim lista.txt

problem solved :-)

( asch v | 2021. 07. 14., sze – 12:17 )

Én vagyok az egyetlen, aki szerint ez a feature hasznos? Abban egyetértek, hogy kommunikálni kellett volna ezt, de alapból a feature hasznos, hogy a pazarló oldalakat visszafogjuk.

Egyébként ha már szóba került, tudjátok, hogy ha egy weboldal éppen nem látható a telefonos böngészőben, de nincsen becsukva, akkor a benne futó JS-sel mi történik? Futogat valami a háttérben, vagy meg van fagyasztva? Mikor újra az adott oldalra lépek, akkor onnan folytatja ahol állt, vagy újra van indítva?

bongeszotol fugg.

 

Eleve ami nincs eloterben azt lassitja (halozatban is), masreszt egy ido utan hibernalja azt a fulet. Ha orakig nem nezek ra, akkor frankon ujratolti az oldalt, amikor ujra megnyitod.

 

(ez mobil firefox)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem is hasznos. De szerintem hasznos volt az Apple lassító megoldása is, ha választani kell a lassabb, stabilabb működés és a gyorsabb, bizonytalan közt, én a stabilra szavazok. A megoldással elsősorban az volt a probléma, hogy nem kommunikálták. Ha valahol a használati feltételek sokadik oldalán megteszik, nagyjából ugyanúgy a kutya sem olvasta volna, de lehetne rá mutogatni, hogy szóltunk.

( dejo v | 2021. 07. 14., sze – 15:32 )

Ez számomra teljesen elfogadható.
Túl sok irreálisan sok erőforrást zabáló alkalmazás van!

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox