Moto Droid @ 800 MHZ (up to 1.1 Ghz!!!)

Ich weiß nicht ob das hier auch funktionieren würde, aber aus anderen Bereichen kenn ich das so:
Das Programm tut nicht alles was man will, also wird es um Funktionen ergänzt.
So kann man bei Windows .exe-Dateien zum Beispiel .dll-Files attachen, die dann bestimmte Anfragen abfangen (Hook), dort ihre Magie einsetzen, und das gewünschte Ergebnis zurückgeben.
Sofern Source-Code vorhanden ist wird das sogar deutlich einfacher.

Also mein Ansatz.
Könnte man den Bootloader nicht um eine Funktion erweitern die erkennt, wenn die Signatur gefordert wird und dann den richtigen (fest vorgegebenen) Wert zurückgibt.
Zur Not müsste man alle Programme der Boot-Chain so abändern/ergänzen.
Ich bin da jetzt nicht so in der Materie drin um das definitiv sagen zu können.
Keine Ahnung ob das so beim Milestone und Android möglich ist, aber ich dachte ich schlag's mal vor...

Für die CPU und den SoC an sich stellen 800Mhz kein Problem dar denn auch das Package von 3430 und 3440 ist identisch. Von dieser Seite her kann es im schlimmsten Fall nur instabil werden (bei SoCs die 800Mhz bei der gelieferten Versorgungsspannung nicht schaffen). Womit die Taktrate soweit reduziert werden muss bis ein stabiler Betrieb möglich ist. An der Lebensdauer des SoCs ändert sich damit nichts.
Der Grund dafür ist das die Spannung nicht angetastet wird. Zu hohe Spannungen sind der Todfeind des Halbleiters und je kleiner die Fertigungsstrukturen desto geringer der Spielraum für diese

Worst Case für einen Omap 3440 bei 800Mhz sind 750mW (Seite 6).
:: DatasheetPro :: Download OMAP3430 datasheet PDF download :: Texas Instruments :: IntroductionMobile Internet Devices (MIDs) are an

Für den Omap 3430 gibt es meines Wissens nach keine offiziellen Zahlen. Dumm heruntergerechnet wären es (bei gleicher Spannung) 560mw. Allerdings bezieht sich die Leistungsaufnahme eben auf den ganzen SoC und nicht nur auf den ARM Kern. Da andere Komponenten durch die Taktfrequenz des ARM Kerns kaum beeinflusst werden ist diese Zahl in jedem Fall zu gering. Praktisch werden es wohl um die 620mW sein.

Diese Zahlen sind Worst Case - also fast nur unter Laborbedingungen zu erreichen und dienen hauptsächlich dazu um die Spannungsversorgung und Kühlung ausreichend zu dimensionieren.

Deshalb sollten die 800Mhz auch dauerhaft auf den meisten Geräten möglich sein. Garantieren kann es aber keiner und das Risiko trägt jeder für sich selbst. Mir war hier wichtig eine halbwegs brauchbare technische Grundlage zu schaffen. Leider fehlt es aktuell beim Milestone an der passenden Software.

sorry wie komme ich denn auf Spannung (wahrscheinlich weil du Spannung geschrieben hattest - was bei deinem Fall in deinem Post auch richtig war...) ich meine natürlich Strom, denn der erhöht sich sehr wohl bei Erhöhung der Taktrate.

Wie gesagt es wird nicht so sein dass das Handy nach 5 Minute tot ist weil man auf 800MHz getaktet hat, es wird sicher auch locker den Erstbesitzer überleben... aber es hat definitiv Auswirkung auf die Lebensdauer... das sollte sich einfach jeder bewusst sein das übertaktet... wie gesagt ein Raucher raucht auch obwohl er weiß dass es ungesund ist... er stirbt ja auch nicht nach 5 Minuten...

Das die Package von 3430 und 3440 gleich sind, damit hast du sicherlich recht - aber wie du auch sagtest werden die "besten" CPUs für die 3440er genutzt und nicht für die 3430 - du sagtest zwar auch, dass die Nachfrage der 3440 so gering ist dass viele als 3430 verkauft werden, obwohl sie nach internen Kriterien als 3440 verkaufbar wären.

Aber bei einen 3440 CPU ist man sich eben zu 99,9% sicher dass er die Leistung locker verträgt, bei dem 3430 hat man eben auch Sonntagsmodelle dabei, die schnell ihre "Lebensenergie" verlieren.

No Risk no fun!
Denke das Risiko ist vertretbar. Nach 5 Jahren spätestens habe ich eh wieder ein anderes Handy. Habe noch nie gehört, dass einem der Prozi abgeraucht ist...

bingo5 schrieb:

sorry wie komme ich denn auf Spannung (wahrscheinlich weil du Spannung geschrieben hattest - was bei deinem Fall in deinem Post auch richtig war...) ich meine natürlich Strom, denn der erhöht sich sehr wohl bei Erhöhung der Taktrate.

Zum Vergrößern anklicken....

Der erhöhte Stromfluss kann bei nicht ausreichend dimensionierten Spannungswandlern zu defekten führen. Im Bereich von 800Mhz ist das aber eher unwahrscheinlich und dürfte nur auftreten wenn die theoretische maximale Last über längere Zeit anliegt. Im Normalbetrieb, auch bei GPS Navigation usw. tritt diese nicht auf. Wäre das der Fall würde der Akku in unter 3 Stunden sein Kapazität entleert haben. Dazu kommt noch das der ARM Kern durch das Power Management die meiste Zeit bei weit geringeren Taktraten betrieben wird.

bingo5 schrieb:

Aber bei einen 3440 CPU ist man sich eben zu 99,9% sicher dass er die Leistung locker verträgt, bei dem 3430 hat man eben auch Sonntagsmodelle dabei, die schnell ihre "Lebensenergie" verlieren.

Zum Vergrößern anklicken....

Die Stromstärke ist zwar bei Halbleitern (bezogen auf Mikrochips) ebenfalls ein Faktor, aber weniger kritisch als die anliegende Spannung.
Zu hohe Spannungen führen extrem schnell zur Schädigung bzw. Zerstörung von einzelnen Transistoren. (Aufbau von größeren, ungewollten Kapazitäten im Transistor, Defekte an Isolationsschichten etc.)
Hier wird beim übertakten oft das Wort Elektromigration gebraucht. Also wenn die CPU bei starkem (oder falsch ausgeführtem) übertakten nach einer kurzen bis mittleren Zeit entweder nur noch auf geringeren Taktraten funktioniert oder komplett zerstört ist.
Im Gegensatz dazu führt ein erhöhter Stromfluss in erster Linie zu einem Anstieg der Leistungsaufnahme und Abgabe. Wobei die Abgabe (da im herkömmlichen Sinn keine Arbeit verrichtet wird) in Wärmeenergie stattfindet.

Mir ist kein Fall bekannt in denen ein Mikrochip nur aufgrund zu hoher Taktraten beschädigt wurde. Im Regelfall ist es eine zu hohe Spannung und eher selten eine zu hohe Leistungsaufnahme (und damit Abgabe) bei zu geringer Kühlung.

@Barnd Genau so meinte ich dass auch
@moppelg Es geht ja nicht nur um den CPU, außerdem wie viel Handybesitzer kennst du, die vor 5 Jahren ihr Handy übertaktet haben und es immer noch nutzen?

@Barnd

Sehr interessant zu lesen!

Allerdings bezweifel ich deine einschaetzung, dass x86 sich bald in diesem segment verbreitet. Nicht nur, dass es zurzeit viele schaetzungen gibt, dass ARM bis 2013 fast 50% des mobilen marktes uebernehmen koennte, sondern auch, dass x86 einfach (selbst bei SOC) wesentlich mehr strom fuer die gleiche leistung benoetigt!

Wer braucht denn auch den ganzen ballast, der bei x86 mitgeschleppt wird :S ... wenn ueberhaupt, bedarf es eines neuen CISC ansatzes, der nicht mit kompatibilitaet aus der steinzeit aufwartet - die software fuer mobilgeraete sollte/wird ja auch eh neu gedacht und gemacht (Ausnahme: Symbian ;D)

(Bei dem, was ich hier verzapfe, garantiere ich keine korrektheit - interessiere mich zum teil sehr fuer dieses gebiet, allerdings wird das in meinem studium ITM nur leicht angekratzt und mein wissen beziehe ich zumteil noch aus verschiedensten quellen)

bingo5 schrieb:

@Barnd Genau so meinte ich dass auch
@moppelg Es geht ja nicht nur um den CPU, außerdem wie viel Handybesitzer kennst du, die vor 5 Jahren ihr Handy übertaktet haben und es immer noch nutzen?

Zum Vergrößern anklicken....

Ich hatte einen HTC Prophet, der war ca 2 Jahre lang übertaktet, bis ich ihn Ende letzen Jahres beim flashen gebrickt hab.
Er hatte einen TI OMAP 850 mit 201 MHz und war immer auf mindestens 266MHz übertaktet.
Teilweise lief er auch tagelang stabil mit 299MHz, wobei mehr als 299MHz regelmäßig einen Absturz oder Einfrieren lieferten.

bingo5 schrieb:

@Barnd Genau so meinte ich dass auch
@moppelg Es geht ja nicht nur um den CPU, außerdem wie viel Handybesitzer kennst du, die vor 5 Jahren ihr Handy übertaktet haben und es immer noch nutzen?

Zum Vergrößern anklicken....

Dann sind wir uns ja einig, der kritische Punkt bleibt die Spannungsversorgung und deshalb kann man von Taktraten im 1Ghz Bereich nur abraten.

Keija schrieb:

@Barnd

Sehr interessant zu lesen!

Allerdings bezweifel ich deine einschaetzung, dass x86 sich bald in diesem segment verbreitet. Nicht nur, dass es zurzeit viele schaetzungen gibt, dass ARM bis 2013 fast 50% des mobilen marktes uebernehmen koennte, sondern auch, dass x86 einfach (selbst bei SOC) wesentlich mehr strom fuer die gleiche leistung benoetigt!

Wer braucht denn auch den ganzen ballast, der bei x86 mitgeschleppt wird :S ... wenn ueberhaupt, bedarf es eines neuen CISC ansatzes, der nicht mit kompatibilitaet aus der steinzeit aufwartet - die software fuer mobilgeraete sollte/wird ja auch eh neu gedacht und gemacht (Ausnahme: Symbian ;D)

Zum Vergrößern anklicken....

Die ARM Architektur hat ein großes Problem und das ist die Kompatibilität gegenüber Standardsoftware (x86). Die ist nicht vorhanden und führt in der Entwicklung zu Mehraufwand. Der Vorteil ist natürlich ganz klar die höhere Effizienz (Rechenleistung/Energiebedarf).

Oft wird als Argument vorgebracht das typische x86 Anwendungen für den Mobilbereich weniger geeignet sind. Das ist aber zum einen abhängig vom Geräteformat (und damit der Displaygröße) und zum anderen nur eine Frage der graphischen Programmoberfläche. Diese lässt sich mit geringen Aufwand anpassen.

Je kleiner die Fertigungsstrukturen sind in denen gefertigt wird desto nebensächlicher werden die paar Millionen Transistoren die den Ballast der x86 Architektur bilden. Weiter (wie mit Cortex A9) steigt gleichzeitig die Komplexität der ARM Architektur. Das ist zwingend nötig denn ARM ist zwar hocheffizient aber im Vergleich zu den x86 Lösungen weniger performant. Gerade für Netbooks und Tabletts also (noch) an der unteren Leistungsgrenze.

Es gibt deshalb im Vergleich der beiden Architekturen unter Einbeziehung kommender Fertigungsverfahren einen sogenannten Sweet Spot bei dem sich beide Architekturen was Leistung und Effizienz betreffen überschneiden.

Genau das ist der Grundgedanke hinter Intels Atom Serie. Diese wird mit jeder Generation weiter konsequent auf diesen Markt ausgerichtet. Mokeups und Prototypen im MID und Smartphoneformaten geistern bei Intel schon seit Jahren über diverse Messen. Der letzte und wohl ausschlaggebende Faktor ist die Marktdominanz von Intel (und Microsoft ist x86 sicher nicht abgeneigt).
Spontan ein paar Beispiele:
http://www.engadget.com/2008/01/07/hands-on-with-intels-mid-platform/
http://www.netbooknews.de/12545/ces-2010-aava-smartphone-mit-intel-moorestown-wird-vorgestellt/

Anmerkung, was die Software (ARM) im Mobilbereich angeht wird zwar aktuell viel entwickelt, meist geht es aber kaum über das Niveau von Widgets und Kleinstapplikationen hinaus. Das mag für MIDs und Smartphones großteils ausreichend sein, für Tabletts und Netbooks ist es aber bei weitem zu wenig.

@Barnd

Wirklich interessante Ausführung, die ich zum Größten auch teile!!! Der "Krieg" im Mobilitysegment zwischen Intel mit Moorestown und ARM mit Snapdragon, wird vllt in der ersten Runde durch den Erfolg oder Miserfolg der bald kommenden Books vs Atom Netbooks entschieden!!!
Eine große Frage für die Masse wird das OS bleiben!? ARM mit Android hat mitlerweile ein wenig Akzeptanz bekommen, aber einem großem Publikum ist sein Windows mit "lahmer" CPU immernoch lieber!!!
Die ARM 9 Architektur sieht sehr vielversprechend aus und könnte in Smartbooks eingesetzt vllt eine starker Gegner sein, aber bis zu dem Zeitpunkt dürfte vllt auch Intel seine Strategie überdenken, um den Atomnachfolgern ein bissel mehr Leistung zu gönnen!!!
Dazu gab es glaube ich einen Video bei Youtube, bei dem ein ARM 9 Dualcore mit 500 Mhz nen Atom mit 1.6 GHz schon sehr extrem parolle bieten konnte!!!
Man möge auch nicht die SoC Lösung wie Tegra2 etc... nicht vergessen, die ich doch eher als starken Konkurenten zu Intel sehe!!!
Intel hat dagegen mit Moorestown einen wirklich netten Chip für MID bzw große Smartphones, aber da bleibt es auch ne Frage wie der Markt einem neuen Konkurenten gegenüber der "gewohnten" Handytechnik reagieren wird!?
Beide versuchen in die Domäne des Anderen zu gelangen, aber obs ARM+Android oder doch Intel+Microsoft wird,ist nicht so leicht abzusehen!!!
Letztere sind wirklich eine extreme Markmacht, dass selbst ARM+Android wie kleine Fische aussehen lässt, aber vllt schafts ja die Underdougtechnik!!!

Also ich bin von dem Asus Book mit ARM extrem beeindruckt...
Der Atom ist mir schon lange ein Dorn im Auge nur unter Ubuntu ist er einigermaßen schnell und 90% der Netbooks sind doch immer das selbe. Nicht mal YoutubeHD bringt der Atom was der Arm bei deutlich weniger Verlustleistung schafft. Selbst 1080p schluckt der ARM Kern.

Ich plädiere für einen schönes Tabletsmartbook 10-12" mit Snapdragon und großem Akku inklusive Android...müsste sogar für das gleiche geld wie ein Netbook zu haben sein!

Woah! Sind wir Offtopic

Der eigentliche ARM Kern ist für die HD Wiedergabe und Flash noch weniger geeignet als ein Atom.

Die (En)Decodierung von Videos (und auch Flash) übernimmt ein separater Prozessor auf dem SoC.
(Deshalb gibt es meist auch nur youtube apps. Eine richtige Flash Version für den Browser mit Hardwarebeschleunigung ist noch nicht fertig).
Mit Flash 10.1 wird in naher Zukunft auch auf der x86 Platform eine Beschleunigung (per GPU) vorhanden sein und damit ist dieses Problem aus der Welt.

1080p ist übrigens mit US15W (PowerVR) durchaus möglich, hier übernimmt ebenfalls die GPU einen großen Teil der CPU Last. Atom+GMA 3150 (PINE Trail) schafft aktuell 720p. Es gibt allerdings auch Lösungen die per PCIe x1 einen dedizierten Decoderchip angebunden haben (für 1080p).

Wobei mir ehrlich gesagt der Sinn hinter 1080p auf einem Netbook oder Smartphone verschlossen bleibt. Natürlich nett für die externe Ausgabe aber praktisch sind 720p ausreichend und ein guter Fernseher kann ins Netzwerk eingebunden werden...benötigt also keine decodierte Zuspielung.

Barnd schrieb:

Der eigentliche ARM Kern ist für die HD Wiedergabe und Flash noch weniger geeignet als ein Atom.

Die (En)Decodierung von Videos (und auch Flash) übernimmt ein separater Prozessor auf dem SoC.
(Deshalb gibt es meist auch nur youtube apps. Eine richtige Flash Version für den Browser mit Hardwarebeschleunigung ist noch nicht fertig).
Mit Flash 10.1 wird in naher Zukunft auch auf der x86 Platform eine Beschleunigung (per GPU) vorhanden sein und damit ist dieses Problem aus der Welt.

1080p ist übrigens mit US15W (PowerVR) durchaus möglich, hier übernimmt ebenfalls die GPU einen großen Teil der CPU Last. Atom+GMA 3150 (PINE Trail) schafft aktuell 720p. Es gibt allerdings auch Lösungen die per PCIe x1 einen dedizierten Decoderchip angebunden haben (für 1080p).

Wobei mir ehrlich gesagt der Sinn hinter 1080p auf einem Netbook oder Smartphone verschlossen bleibt. Natürlich nett für die externe Ausgabe aber praktisch sind 720p ausreichend und ein guter Fernseher kann ins Netzwerk eingebunden werden...benötigt also keine decodierte externe Zuspielung.

Zum Vergrößern anklicken....

Schon klar, aber zeigt was bei klugen SoC lösungen alles möglich ist!

Ich habe nie behauptet, dass der Atom 1080p können sollte klar dass das eine GPU machen muss. Und für den Snapdragon gilt das auch. interessant ist beim Atom, dass der lahme chipsatz mehr strom frist wie der prozessor selber. Die nächste Generation des Atom soll ja sogar den chipsatz im chip haben. Also ein Atom SoC

Für mich war die bisher schlechte Umsetzung von Flash und Videodecodierung auf der Atomplatform der Hauptgrund kein Netbook zu kaufen. Ist mir ehrlich gesagt auch nicht verständlich warum Intel bei der kompletten ersten Generation Resteverwertung betrieben hat (uralte Chipsätze) und der eigentlich gute USW15 mit PowerVR lange Zeit dank grottigster Treiber klein gehalten wurde. Wobei es mir persönlich nur um die Flashbeschleunigung geht, ohne diese ist intensives Surfen aufgrund des häufigen Einsatzes von Flashwerbung zu holprig.

Ja. Pine Trail hat einen Großteil des Chipsatzes auf dem Trägermaterial, ist aber kein echter SoC denn es sind zwei Dies nebeneinander (also nicht monolithisch) und es wird zusätzlich noch eine Southbridge (für I/O, also USB, SATA etc.) benötigt. Ein richtiger SoC kommt 2011 mit Cedar Trail. In 22nm sollte dieser auch ungefähr auf Augenhöhe mit den ARM basierten Produkten liegen.

Was die Multimedialeistung angeht (also En/Decoding) ist der Scorpion (ARM Kern+Mediaengine des Snapdragon, modifizierter Cortex A8) aktuell die schnellste ARM Umsetzung. Leider hat das Gesamtpaket Snapdragon aber eine etwas gealterte und lahme GPU abbekommen. Ansonsten wäre es mit Abstand das beste verfügbare Paket.

So halbwegs ordentlich funktioniert das ganze bei mir mit nem Acer 1810 - Dualcore CPU mit GMA4500HD - HD ist nicht so das Problem und auch alle anderen Dinge laufen zufriedenstellend! Aber ich hab mich schon in den Itab verguckt....

sorry aber kann mir einer sagen wie das Programm heißt zum Oc en?

natas77 schrieb:

sorry aber kann mir einer sagen wie das Programm heißt zum Oc en?

Zum Vergrößern anklicken....

heisst nicht, gibts nicht. und schon gar nicht im moment auf dem milestone. wenn dann nur droid ... problem: der kernel wurde angepasst. und das ist beim milestone aufgrund der signierung (hoffentlich noch) nicht möglich ...

die Signierung kann man also noch nicht umgehen!

danke aber schade hätte es schon gerne mal getestet.

Danke noma

na nicht ganz sooo vor eilig... Die Clockrate kann man schon mit div. Programmen verändern (glaube OC Widget z.B. bin mir aber beim Namen nicht sicher...) - das Problem ist bloß dass im Moment das übertakten noch nicht geht, das untertakten geht aber schon

Hat eigentlich jemand mal seinen Milestone ein paar Tage lang underclockt? Also sagen wir mal permanent auf max. 250 Mhz laufen lassen.
Macht sich das signifikant an der Akkulaufzeit bemerkbar?
Ne sinnvolle Anwendung fürs Underclocken wäre zb. wenn man den Stein zum Tracking benutzt. Dabei hat man ihn für gewöhnlich mehrere Stunden in der Tasche und er zeichnet permanent GPS-Koordinaten auf. Der Bildschirm ist dabei aus, es läuft nur der Prozessor und das GPS-Modul. Fänd ich cool, wenn man damit das eine oder andere Stündchen länger tracken könnte.

Gruß
Jarny