Software - Ecke

[Buntes Kleinpferd]

Ich bin kein Experte, aber ich bin sicher, dass Android eher langsam ist liegt sicher nicht am Kernel. Ein Echtzeitkernel ist auch nicht per se schneller als ein "herkömmlicher" Multitaskingkernel, er führt bloß zeitkritische prozesse mit geringerer Verzögerung aus. Der Unterschied ist der, dass wenn beim Echtzeitkernel ein Prozess mit entsprechend hoher Priorität sagt: "Ich will jetzt ausgeführt werden!" das auch sofort passiert, und alles andere temporär zurückgestellt wird.

Wie gesagt, ich bin kein Experte, aber dass Android so vergleichsweise lahm ist, schiebe ich einfach mal auf Java.

[Andromachus]

(27.07.2014)Buntes Kleinpferd schrieb:  Ich bin kein Experte, aber ich bin sicher, dass Android eher langsam ist liegt sicher nicht am Kernel. Ein Echtzeitkernel ist auch nicht per se schneller als ein "herkömmlicher" Multitaskingkernel, er führt bloß zeitkritische prozesse mit geringerer Verzögerung aus. Der Unterschied ist der, dass wenn beim Echtzeitkernel ein Prozess mit entsprechend hoher Priorität sagt: "Ich will jetzt ausgeführt werden!" das auch sofort passiert, und alles andere temporär zurückgestellt wird.

Eben, und das ist wichtig, wenn Tastatureingaben (nicht umsonst gibts/gabs am PC dafür ne IRQ Leitung) bzw. Touchscreen-Klicks kommen, wenn Calls kommen etc., dann ists völlig egal ob der Browser grad ne Seite rendert, eine App installiet wird oder die Media Library indiziert wird, es gibt einfach Tasks die sofort ausgeführt werden müssen.

Zitat:Wie gesagt, ich bin kein Experte, aber dass Android so vergleichsweise lahm ist, schiebe ich einfach mal auf Java.

Ja, das auch. Aber die absolute Performance ist eher weniger, denn für ein bissl Texten, SSH etc. reicht jedes Smartphone von der Performance völlig aus. Ging ja früher auch, damals z.B. mit dem Psion Serie 5 mit 36Mhz ARM CPU und 24MB shared RAM. Dort konnte man noch besser E-Mails schreiben als bei Android, einfach weil die Software besser war.

(26.07.2014)Buntes Kleinpferd schrieb:  aber damit man einen Anruf nicht mehr annehmen kann, weil das Telefon ausgelastet ist, muss man sein Android wahrscheinlich schon ziemlich verbasteln.

Was bitte will man da verbasteln? Die Telefon App ist genauso eine App wie alle andere auch. Wenns ausgelastte ist, dauert es halt 20 bis 30s im Worst Case bis das Ding startet.

Eben darum Echtzeitsystem, wie oben beschrieben. Das funktioniert dann auch.

Apropos, Bei Android stürzen Apps auch dauernd ab, gerade wenn sie im Hintergrund laufen. Das ist extrem übel wenn man dort z.B. schon Text geschrieben oder z.B. ein Formular halb ausgefüllt hat. Bei BB ist das nicht der Fall, hier kann man tatsächlich multitasken.

Zitat:Es gibt ja durchaus auch Android Geräte mit Tastatur. Möglich ist das also, nur die Nachfrage scheint nicht im ausreichenden Maße zu bestehen.

Gibts, aber hier gabs in der Vergangenheit immer Probleme weil der Tastaturbuffer überlief, weil der Nicht-Echtzeitkernel oft genug zu lange brauchte um ihn zu leeren und zu verarbeiten (gerade wenn Last auf dem System war). Zudem sind die Apps miserabel designed, viele blenden völlig unsinnigerweise ein Softkeyboard an. Weiterhin drehen viele den Bildschirm um 90 Grad, weil die Developer das irgendwie lustig finden.

Hier wirkt es sich nachteilig aus, daß Google die Softwarequalität der Apps in keinster Weise überprüft.

Und ja, theoretisch kann man den Linux-Kernel bedingt echtzeitfähig machen. Dazu fehlt google aber anscheinend das Knowhow, der Linux Unterbau kann fast gar nichts verglichen mit dem, was auf dem Desktop möglich ist.

Ich denke auch daß Linux langfristig erfolg haben wird auf den Mobiles, aber sicher nicht in Form von Android. Ggf. werden wir auch einen BSD Kernel sehen. Der Rest der Software und Toolchains ist ja ohnehin recht unabhängig vom Kernel. Dazu wärs aber wichtig, daß wir offene Plattformen haben, aber das wird auch kommen.

[404compliant]

(27.07.2014)Andromachus schrieb:  Was bitte will man da verbasteln? Die Telefon App ist genauso eine App wie alle andere auch. Wenns ausgelastte ist, dauert es halt 20 bis 30s im Worst Case bis das Ding startet.

Eben darum Echtzeitsystem, wie oben beschrieben. Das funktioniert dann auch.

Um hier mal etwas Licht ins Dunkel zu bringen: Von einem Echtzeit-System redet man, wenn ein Hardware-Ereignis oder ein zeitlich vorgeplantes Ereignis vom System mit einer zeitlichen Toleranz im Bereich 1ms - 1µs (0.001s - 0.000001s) genau ausgeführt wird. Gebraucht wird sowas für präzise Maschinensteuerungen, bei denen eine größere Verzögerung fatale Folgen hätte.

Kein Desktop-Betriebssystem ist Echtzeitfähig. Muss es auch nicht sein, Menschen sterben normalerweise nicht, wenn ein Tastendruck 1-2ms später verarbeitet wird. Außerdem hat harte Echtzeit technisch bedingt deutliche Auswirkungen auf Performance und Energieverbrauch des Computers, umsonst kriegt man die halt auch nicht.

Es gibt Linux-Varianten mit Echtzeit-Option, sogar für Windows gibt es das, aber das sind dann spezielle Industrie-PCs mit spezieller Echtzeit-Software für Steuerungen, keine Benutzeranwendungen.

[Laser Gurke]

hmm, also ne echtzeit funktion, bezogen auf das telefon wäre schon nett für android

[DrDerrek]

(26.07.2014)Adama schrieb:  Ich wurd bei niedrigen butget zu Windows phone greifen!

Kein unter 100€ android handy kann mit nem l530 mithalten, zumindestens bei der hardware.

Das kann sein. Aber du wirst auch kein Windows Phone Handy für 30 € finden. Ich habe mir bei Smartkauf mal für 29,99 € das Samsung Galaxy Y geholt, als Festivalhandy. DAS ist echtes Low-Budget. Geht sogar noch Android 4.2 drauf. Daher habe ich Windows Phone lieber im mittleren Budget angesiedelt.
Man kann es auch so verstehen, dass Microsoft bewusst ein Mindestmaß an Hardware voraussetzt, um dem User ein möglichst großes Usability-Erlebnis zu garantieren. Aber die "Ich brauch uuunbdingt ein Smartphone obwohl ich nur telefoniere damit"-User fallen dann unter den Tisch.

[Laser Gurke]

ja, die user kenne ich^^

F: du hast ein Smartphone?

A: ja, klar!

F: Was hast du für spiele/Apps drauf?

A:gar keine, ich will nur sms und telefonieren...
F: wollen wir tauschen? *Altes S/W Nokia hinnhalt*

A: Nein, das ist ja schlechter

F: Aber es kann das, was du willst


Noch fragen?

[Adama]

Das 530 wird real am ende wohl 70€ kosten...

Dafur top verarbeitung und top flussikeit...

Aber klar... Manchen ist selbst das zuviel...

[DrDerrek]

(29.07.2014)Lasergurke schrieb:  ja, die user kenne ich^^

F: du hast ein Smartphone?

A: ja, klar!

F: Was hast du für spiele/Apps drauf?

A:gar keine, ich will nur sms und telefonieren...
F: wollen wir tauschen? *Altes S/W Nokia hinnhalt*

A: Nein, das ist ja schlechter

F: Aber es kann das, was du willst


Noch fragen?

F: Hast du eine Internet-Flat?

A: Nein, wozu das denn? Brauch ich nicht.

[Laser Gurke]

Ja, is so...ich kann es nicht verstehen...

[Andromachus]

(27.07.2014)404compliant schrieb:  Um hier mal etwas Licht ins Dunkel zu bringen: Von einem Echtzeit-System redet man, wenn ein Hardware-Ereignis oder ein zeitlich vorgeplantes Ereignis vom System mit einer zeitlichen Toleranz im Bereich 1ms - 1µs (0.001s - 0.000001s) genau ausgeführt wird. Gebraucht wird sowas für präzise Maschinensteuerungen, bei denen eine größere Verzögerung fatale Folgen hätte.

Richtig. Bei einem Mobile OS ist das aber essenziell, damit wichtige Dinge verarbeitet werden können, da nicht nur die Hardwareressourcen knapper sind, sondern die einfachsten Programme nicht aus compiliertem C-Code bestehen, sondern komplexe, javaähnliche anwendungen sind.

Zitat:Kein Desktop-Betriebssystem ist Echtzeitfähig. Muss es auch nicht sein, Menschen sterben normalerweise nicht, wenn ein Tastendruck 1-2ms später verarbeitet wird. Außerdem hat harte Echtzeit technisch bedingt deutliche Auswirkungen auf Performance und Energieverbrauch des Computers, umsonst kriegt man die halt auch nicht.

Ähh, du verstehst hoffentlich schon daß es hier nicht um Millisekunden geht. Echtzeit bedeutet ja, daß gewisse Tasks in einer bestimmten Zeit GARANTIERT ablaufen, wie schnell oder langsam oder granular ist erstmal der Implementation überlassen.

Tatsächlich kommts bei Android z.B. vor, daß der Tastatureingabepuffer nicht rechtzeitig geleert wird, bevor er überläuft, oder eben daß die Telefonannahme-Äpp erst dann ausreichend Rechenzeit bekommt, wenn der Anrufer schon wieder aufgelegt hat.

Dies ist natürlich für den Enduser nicht akzeptabel.

Ein weiteres Problem ist die GUI lastigkeit der Smartphones. Während man auf der CLI durchaus asynchron arbeiten kann (ich kann weitertippen etc. selbst wenn ich kein feedback erhalte oder während ich feedback erhalte), ist die GUI zwingend synchron. Ich kann nicht auf Dinge tippen die ich erst in 1 oder 2 sekunden sehen werde, oder popup fenster lesen in die ich gerade hineintippe um etwas anderes zu machen.

Tatsächlich hat Windows (vor SSD und ausreichend RAM) aufgrund der Nicht-Echtzeitfähigkeit dieses Bedienproblem gehabt wie ein Standarddesktoplinux mit eingeschaltetem Swap das tatsächlich benutzt wird (z.B. wenn dann der Mauszeiger nur alle paar Sekunden refreshed wird).

Mittlerweile sind nicht nur verschiedene Flaschenhälse beseitigt, sondern die Scheduler der Desktop-OS dahingehend getuned, daß man auch ohne hartes Echtzeitverhalten akzeptabel mit GUIs arbeiten kann. Aber das war lange Zeit eben nicht so.

Zitat:Es gibt Linux-Varianten mit Echtzeit-Option, sogar für Windows gibt es das, aber das sind dann spezielle Industrie-PCs mit spezieller Echtzeit-Software für Steuerungen, keine Benutzeranwendungen.

Richtig, sowas könnte man dann z.B. ins Rennen gegen BB10/QNX schicken. Mich wunderts daß Google das nicht direkt getan hat. Aber wenn ich dann sehe was bei Android alles fehlt, das ich überall sonst in Linux habe, wundert es mich dann auch wieder nicht. Wer sein Ökosystem verkrüppelt, weil er nicht sieht was man damit anfangen könnte, dem traue ich auch nicht zu daß er custom kernels kompiliert mit echtzeitfähigem scheduler und dies auch noch hinreichend engineered.

[404compliant]

(30.07.2014)Andromachus schrieb:  Echtzeit bedeutet ja, daß gewisse Tasks in einer bestimmten Zeit GARANTIERT ablaufen, wie schnell oder langsam oder granular ist erstmal der Implementation überlassen.

Tatsächlich kommts bei Android z.B. vor, daß der Tastatureingabepuffer nicht rechtzeitig geleert wird, bevor er überläuft, oder eben daß die Telefonannahme-Äpp erst dann ausreichend Rechenzeit bekommt, wenn der Anrufer schon wieder aufgelegt hat.

Aber genau das ist der Punkt: Tastaturhandler sind NIEMALS Echtzeit. Echtzeit zu programmieren heißt, keine Zugriffe auf Datenträger/Flash-Speicher, keine RAM-Speicherverwaltung, allen Programmcode, Daten und Bibliotheken gegen Swappen absichern, und generell nichts benutzen, was nicht ausdrücklich garantiert in einer maximalen Zeitspanne erledigt ist. Denn all diese gebräuchlichen, und so gut wie alle anderen Funktionen eines Betriebssystems sind halt nicht echtzeitfähig, weil man nicht garantieren kann, dass sie in einer festgelegten Zeit garantiert abgearbeitet sind.

Tastaturhandler sollen Eingaben verarbeiten, sind damit also erst erledigt, wenn das Anwendungsprogramm sie abgearbeitet hat. Echtzeitfähige Tastatureingaben würden bedeuten, alle Programme müssten ihrerseits echtzeitfähige Tastaturhandler implementieren. Wenn ich einen Speichern-Button drücke, ist die Aufgabe erst erledigt, wenn die Daten geschrieben sind, und wer weiß, ob es nicht durch Schreibprobleme zu Verzögerungen kommt... Das heißt Echtzeit.

Was du willst, sind Programme, die flüssig reagieren. Dazu muss das System über genug Ressourcen verfügen, um die Eingaben verarbeiten zu können, ohne erst mal Programmteile aus dem Flash zurück zu holen, und genügend Leistung, damit die Arbeitsschritte erledigt sind, bevor der nächste Tastendruck erfolgt. Das hat aber nichts mit Echtzeit zu tun.

[Laser Gurke]

Kann Mann nicht einfach das Telefon, also die Anwendung, die Echtzeit machen sollte nicht einfach wie bei Windows einer höheren Priorität zuordnen?

[Dominik]

Öhm... Entschuldige mich mal... Was isn damit?
https://www.mozilla.org/de/firefox/os/


Und selbst normale Handys haben ein Operating System... Das Samsung Star zum Beispiel hat Symbio, wenn ich mich recht erinnere.

[404compliant]

(30.07.2014)Lasergurke schrieb:  Kann Mann nicht einfach das Telefon, also die Anwendung, die Echtzeit machen sollte nicht einfach wie bei Windows einer höheren Priorität zuordnen?

Echtzeit ist quasi die höchste Priorität, bei Windows-Echtzeitsystemen hat die Echtzeit sogar normalerweise höhere Priorität als der gesamte Windows-Kernel.

Einfach nur die Priorität erhöhen reicht aber nicht, denn Echtzeit heißt garantierte Zeit. Selbst ein Programm höchster Priorität kann unerwartet ausgebremst werden. Echtzeitsysteme garantieren, dass keine blockierende Systemoperation länger als z.B. 10µs dauert. In der Regel verbietet es sich dadurch z.B. schon, den Prozessor in den Energiesparmodus zu versetzen, da er gar nicht schnell genug aufwachen, bzw. seinen Takt wieder erhöhen kann.

[Andromachus]

(30.07.2014)404compliant schrieb:  Aber genau das ist der Punkt: Tastaturhandler sind NIEMALS Echtzeit. Echtzeit zu programmieren heißt, keine Zugriffe auf Datenträger/Flash-Speicher, keine RAM-Speicherverwaltung, allen Programmcode, Daten und Bibliotheken gegen Swappen absichern, und generell nichts benutzen, was nicht ausdrücklich garantiert in einer maximalen Zeitspanne erledigt ist. Denn all diese gebräuchlichen, und so gut wie alle anderen Funktionen eines Betriebssystems sind halt nicht echtzeitfähig, weil man nicht garantieren kann, dass sie in einer festgelegten Zeit garantiert abgearbeitet sind.

öhh, ja? Und was willst du uns damit sagen?

Früher gabs bei Tastaturdruck einen IRQ, da hat die CPU ihr aktuelles Programm unterbrochen um den Tastaturinput entgegenzunehmen. Deswegen kann man mit einer 16bit 12Mhz CPU unter DOS auch vernünftig tippen und mit einem 1Ghz ARM Prozessor unter Android halt nicht.

Zitat:Tastaturhandler sollen Eingaben verarbeiten, sind damit also erst erledigt, wenn das Anwendungsprogramm sie abgearbeitet hat.

Nein, die Tastatureingabe wird verarbeitet und in den input buffer der applikation geschrieben, die gerade den Fokus hat (übrigens ein Problem bei Desktopanwendungen, da bisher kaum ein Desktop es schafft vernünftig focus stealing to preventen). Danach kann die Applikation damit machen was sie möchte.

Heißt also: Ich tippe, das OS nimmts entgegen und übergibts der Applikation. Die mag ausgelastet sein und vielleicht erst nach ner Sekunde dazu kommen auf meinen input zu reagieren. IdR sollte dort aber tatsächlich ein separater Thread laufen um auf UI Input zu reagieren, das Problem hat z.B. Thunderbird ganz extrem, wo das Programm synchron zur Tastatureingabe und Bildschirmausgabe (ganz lustig bei langsamen Remote X11 verbindungen, wenn man dann tausende mails verschiebt) arbeitet.

Zitat: Echtzeitfähige Tastatureingaben würden bedeuten, alle Programme müssten ihrerseits echtzeitfähige Tastaturhandler implementieren. Wenn ich einen Speichern-Button drücke, ist die Aufgabe erst erledigt, wenn die Daten geschrieben sind, und wer weiß, ob es nicht durch Schreibprobleme zu Verzögerungen kommt... Das heißt Echtzeit.

Siehe oben: Wenn ich auf Speichern drücke, muß der Speicher request direkt ans Programm geschickt werden. Das heißt noch nicht daß die aufgabe erledigt ist.

Zitat:Was du willst, sind Programme, die flüssig reagieren. Dazu muss das System über genug Ressourcen verfügen, um die Eingaben verarbeiten zu können, ohne erst mal Programmteile aus dem Flash zurück zu holen, und genügend Leistung, damit die Arbeitsschritte erledigt sind, bevor der nächste Tastendruck erfolgt. Das hat aber nichts mit Echtzeit zu tun.

Nein. Ich glaube du hast das Problem nicht verstanden. Du versuchst Probleme mit Hardware zu erschlagen, die ein vernünftiges Scheduling voraussetzen, das üblicherweise in Echtzeit geschieht im embedded Bereich.

Die Frage ist: Wozu willst du das tun? Android und iOS zeigen ja gerade, daß dies der falsche Weg ist.

Wir haben ja schon seit Jahrzehnten Computer, die Programme aus dem Flash ausführen (mit RAM) und blitzschnell reagieren können auf User Input. Wenn du denkst dazu wär ne Octo-Core CPU, 4GB Memory und ne 1500x SD Ultra Karte notwendig, liegst du verkehrt.

Und nochmal: Es geht nichts ums "Eingaben verarbeiten" sondern "Auf Eingaben reagieren". Also der Teil der passiert lange bevor die "App" an die Daten kommt. Ich muß auch bei 100% Last und Tasks, die möglicherweise Stunden dauern mit dem System vernünftig interagieren können.

Edit: Ach ja, ein weiteres Problem bei Android sind die ständig abstürzenden Applikationen, besonders wenn sie im Hintergrund laufen.

[Leon]

Btw: Vergleichst du die Android (Bildschrim-)Tastatur mit einer herkömmlichen Tastatur z.B. an einem Windows-PC? Ich denke dieser Vergleich ist etwas sinnlos.
Bei Android arbeitet so weit ich weiß bei der Standardtastatur wesentlich mehr im Hintergrund, da diese auch die Eingaben mit einem Wörterbuch abgleicht, um Korrekturen vorzuschlagen oder das Wort vorherzusagen. Dass die Android-Tastatur allein dadurch potentiell langsamer sein wird, klingt doch schon fast logisch.

Btw #2: Auf meinem Tablet (mit Android/Cyanogenmod (zu faul nachzusehen, welche Version)) stürzen Apps "von sich aus" praktisch nie ab, wenn ich es nicht gerade provoziere, indem ich z.B. im Browser massenweise Tabs mit Videos aufmache.

[Laser Gurke]

(04.08.2014)Leon schrieb:  Btw: Vergleichst du die Android (Bildschrim-)Tastatur mit einer herkömmlichen Tastatur z.B. an einem Windows-PC? Ich denke dieser Vergleich ist etwas sinnlos.
Bei Android arbeitet so weit ich weiß bei der Standardtastatur wesentlich mehr im Hintergrund, da diese auch die Eingaben mit einem Wörterbuch abgleicht, um Korrekturen vorzuschlagen oder das Wort vorherzusagen. Dass die Android-Tastatur allein dadurch potentiell langsamer sein wird, klingt doch schon fast logisch.

Das ist, meiner meinung nach, sogar komplett logisch, aber es wäre wünschenswert, auch dieses eher auf schelligkeit zu trimmen...

jeder der schonmal swift key benutzt hat, weiss, das dieses ,,ich weiss, welches wort du als nächstes tippen willst'' sowiso nicht funktioniert....undwortvervollständigung ist eher nervig, anstatt hilfreich-....-

[Laser Gurke]

bitte verteilt das http://business.chip.de/news/Nach-Russen...00145.html

es geht um 1, 2 millarden konten von ebay, facebook und wo man sich halt überall anmelden kann


KEIN SCHERZ

der erste link war putt, sorry

[DrDerrek]

(07.08.2014)Lasergurke schrieb:  bitte verteilt das http://business.chip.de/news/Nach-Russen...00145.html

es geht um 1, 2 millarden konten von ebay, facebook und wo man sich halt überall anmelden kann


KEIN SCHERZ

Dein Link ist leider kaputt. Aber ich habs auch schon gehört... Immer und immer wieder passierts.

Edit:
Das scheint wohl der korrekte Link zu sein: http://business.chip.de/news/Nach-Russen...00145.html

[Laser Gurke]

habs schon repariert, danke