Category: Geeks & Co.

Dienstag vormittag erfuhr ich von dem Gerücht, die Telekom würde die Bandbreite zum YouTube-beherbergenden Netz nicht bedarfsgerecht aufstocken, weshalb YouTube von (DSL-) Anschlüssen des Rosa Riesen aus mehr häufiger denn nicht »unspaßig« sei.
Nun, wie schon geschrieben, falls dem so wäre – und im Jahre 2011 hätte ich derlei von einem so großen wie wichtigen Anbieter einfach nicht mehr erwartet – würde es ein Phänomen erklären, was schon zu 85% per Hardwareupgrade zu lösen beschlossen war: Auf dem Familien-/Wohnzimmer-Netbook, erste Generation, sei YouTube immer ein Geduldsspiel. Nun, ich habe dessen Minderperformance vor einem Jahr schon thematisiert — allerdings routete ich seinerzeit noch anders, sodaß das die fehlende Bandbreite bei der Telekom hier nicht zum Tragen gekommen sein dürfte.
Ein Problem bei YouTube ist natürlich die Meßmethode — wie mein alter Physik- und E-Technik-Pauker nicht müde wurde zu betonen: wer viel mißt, mißt Mist. Klick im Browser fällt also flach; das geht ohne Meßirritation auch nicht via Remote.
Aber zum Glück gibt es ja youtube-dl. Als Referenzmessung damit schon einmal der Download des Raabschen Auftritts beim ESC, hier aus Berlin (16 MBit/sec ADSL2-Link (13 MBit/sec derzeit nur noch lt. Fritzbox) von Alice, also Hansenet-/Telefónica-Backbone – allerdings geht das über einen OpenVPN-Tunnel nach Gütersloh, d. h. der Internetzugangsprovider hier ist mein PI im Telefónica-Netz):

wusel@berlin:~$ youtube-dl http://www.youtube.com/watch?v=grMLUCkbcrY
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 1.02M/s ETA 00:00 

Da parallel die Doctor Who-Folge vom Samstag mit 2,5 MBit/sec aus Gütersloh auf meinen VDR hier in Berlin kopiert wurde, ist das wohl erst einmal recht nah am »Linespeed«. Vergleichsmessung mit bis auf Grundrauschen leerer Alice-Leitung:

[download] 100.0% of 210.70M at 1.15M/s ETA 00:00

Also kein Einzelfall :-)
In Gütersloh nutze ich ein geteiltes Setup; interne und Geräte wie Telefone, Tablets, Windows arbeiten in einen RFC1918-Addressraum, der auf dem Router dann auf die T-VDSL-Public-IP genatttet wird. Linux-Laptops, Server u. dgl. haben eine Adresse aus meinen PI-Netzen, die über die T-VDSL-Anbindung ebenfalls ins RZ Gütersloh getunnelt und dort dann ins Netz geht — mit der Wirkung, daß ich zwar innerhalb Deutschlands das Telekom-Netz nutze (strenggenommen nur VDSL-GT bis Übergabepunkt zu Telefonica (dem Trace nach meistens Berlin oder Düsseldorf) und ab da dann schon nur noch Telefonica). Allerdings endet der VDSL-Tunnel im RZ noch auf einem Dual-P3 1,4 GHz in einer VM, die Anbindung Berlin terminiert auf einem 2,x GHz-Xeon-System, ohne VM-Overhead. Außerdem ich die Anbindung in GT mit einer Grundlast inbound von ca. 4-5 MBit belegt, die Werte müssen daher nicht zwingend soo viel besser sein als in Berlin :-)
Messung also aus Gütersloh, Internet-Übergang Telefonica:

[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 889.08k/s ETA 00:00

Hernach habe ich 74.125.0.0/16, den Bereich, in dem sich derzeit YouTube-Server für mich befinden, auf das direkte NAT zur Telekom umgeroutet, mit diesem Ergebnis:

GT_via_T-VDSL:~$ ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 272.53M at 784.04k/s ETA 00:00 

Spannende Frage: warum ist die Datei für T-Kunden größer als für den Rest? Und warum bei der Vergleichsmessung über Telekom wieder nicht mehr‽

GT_via_T-VDSL:~$ ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 682.19k/s ETA 00:00

Um zu zeigen, daß hier wirklich auf die Anbindungsgeschwindigkeit abgestellt wird, ein Test direkt von einem mit 100 MBit/sec angebundem Server:

[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 7.35M/s ETA 00:00 

Und GBit sieht so aus:

[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 22.15M/s ETA 00:00

Hier schlägt übrigens auch die Anbindung nach Berlin auf.
Da dies lastabhängig ist und gegen Mitternacht das Gros der T-Kunden schon schlummern dürfte, werde ich das mal tagsüber verifizieren …
Ein anderer lustiger Aspekt: per Proxy geht’s besser als direkt:

GT_via_T-VDSL:~$ http_proxy=http://www-proxy.t-online.de ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 1.29M/s ETA 00:00

Im Vergleich zu …

GT_via_T-VDSL:~$ ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 819.63k/s ETA 00:00 

Spiegel Online hat grade schier unglaubliches festgestellt: zu bekannten Accesspoints baut Android automatisch eine Verbindung auf.
Ich weiß ja nicht, was sie getrunken haben, aber: das montierte Verhalten ist auch so Usus, wenn man sich an verschlüsselten Access Points anmeldet. Zwar ist der Verkehr zwischen Androiden und AP dann verschlüsselt, aber im Spiegel-Artikel übernimmt der Angreifer ja den Accesspoint. Und dagegen hilft dann nur noch End-zu-End-Verschlüsselung…

(Vorweg, dieser Cursor bei Android 2.3 ist eine verdammte gute Erfindung!)
So, per Twitter wurde ich über einen Beitrag von @caschy aufmerksam und kommentierte wie folgt:

Oh, das ist mal spannend und erklärt ein Phänomen zu Hause: meine Frau klagte jüngst über rottige YouTube-Performance auf ihrem Atom-Netbook. Ich konnte das nicht nachvollziehen, da anderer Flash-Kram gut läuft und bei mir unter Linux auch YouTube. Aber jetzt fallen die Schuppen tonnenweise aus den Haaren: das Windows-Netbook hängt im 1918er Subnetz, das direkt auf Telekom-VDSL genattet wird; mein Linux-Krempel hängt im Netz mit PI-Adressen, welches über Telefonica geroutet wird. Danke für den Hinweis, das wird später mal umgeroutet und dann mal hören, ob’s nun besser tubet …

 
Ich werde hier weiter berichten …

Kristian bebloggt den kommenden X11-Exitus und ich sehe das etwas anders.

Und es ist langsam. Wenn wir einen modernen Bildschirm mit X11 über das Netzwerk raus sharen, dann stirbt X11 den Latenztod – formal ist X11 netzwerktransparent, aber in Wirklichkeit ist nichts an dem Protokoll besonders geeignet oder schlau, wenn es darum geht, Daten über das Netzwerk zu schaufeln. Andere Protokolle sind inzwischen weitaus besser geeignet, Bildschirme über Netz zu exportieren: Selbst das halbtote VNC ist in der Regel schneller und besser als X11, RDP und NX sind sogar richtig gut da drin.

 
Naja; erst einmal: ‘xwatchwin’ klappte schon um 1995 ‘rum, da war VNC IIRC noch nicht mal ein feuchter Traum bei den Olivetti Research Labs. Und dann ist da ssh -Y my-gw-in-gt.uu.org xnetload vdsl; mag es auch höllisch ineffizient sein, ich habe jetzt ein ‘xnetload’ von meinem Router in Gütersloh hier auf meinem Laptop in Berlin. Ruckelt, zuckelt, aber tut; und es ruckelt primär, weil ein scp die läppischen 2,5 MBit/sec Upstream zu macht …
Ich mag Neues. Ich mag auch vnc. Und wenn ich zukünftig nach einen ‘ssh’ weiterhin X11-, aber dann auch Wayland-, Anwendungen nutzen kann, hat Wayland eine Chance. Genau dann.

In Teil I habe ich ja schon darauf hingewiesen, daß man dieses WiFi-only (kein GPS, kein WWAN) Tablet mit einem Stückchen Software und einem GPS-Empfänger per Bluetooth GPS-fähig machen kann.
Auf den besonderen Wunsch eines Einzelnen hin, habe ich am Dienstag noch ein paar andere USB-Geräte ausprobiert — vorweg: ohne Erfolg. Es funktionieren also nicht: USB-2-Serial Adapter (weder ‘echte’ noch USB-3G-Sticks), USB-Ethernet-Adapter (zumindest nicht das Belkin GBit-Teilchen, was ich grade zur Hand hatte, ein F5D5055). Beides dürfte an fehlenden Modulen liegen (daß UVC-Cams tun, liegt wohl an der Nutzung von UVC-Video als Kameratreiberbasis) — womit wir zum Thema Modding kommen. Denn mein Tegra2-Mobii ist nur einer mehrerer Handelsnamen gleicher oder sehr ähnlicher Tablets:

Ich hatte mich schon im Vorfeld über die Möglichkeiten den Nvidia Tegra2 Chips zu flashen erkundigt und habe dabei herausgefunden das das

POV Mobii Tegra2
Advent Vega
und das
Malata ZPadT2
die selben Tablets sind.

 
Das ist insofern von Interesse, da Tegra2 einerseits eine potente Plattform darstellt, auf die auch das so gehypte Xoom setzt, andererseits man von »Herstellern« wie POV, Advent und Co. kaum mehr Produktpflege erwarten kann als sie große Namen schon nicht leisten (Stichwort FroYo oder gar Gingerbread für das Motorola Milestone; Stichwort SD-Support beim Motorola Xoom) — und ohne die »Community« gäbe es kein OpenWRT, und ohne OpenWRT, was würde z. B. auf den Foneras laufen? Ok, ich drifte ins Philosophische …;)
Wenngleich ich nicht denke, daß 250,– EUR, die ich für’s POV gezahlt habe, der wahre Preis der Hardware sind (dazu ist z. B. das LCD zu »schlecht«; sprich: es ist nicht spürbar besser oder auch nur, gefühlt, anders als beim MSI Wind seinerzeit, der vor >2 Jahren schon 299,– EUR kostete (Tablets müßten also deutlich unter 200,– EUR herstellbar sein), aber mit mehr RAM, einem Atom-Herz sowie Keyboard & Festplatte), so viel Marge dürfte gar nicht übrig bleiben. daß 2.3 oder 3.0 nachzuliefern wirtschaftlich wäre …
… und damit bleiben dann mehrere Kameras (ok, nur eine ist eingebaut, aber eine weitere wäre ja per USB ‘nachrüstbar’) oder auch ‘nur’ Videochat per Google auf der Strecke. Es sei denn, »die Community« liefert das nach, und dazu braucht man Hardware, die »Mainstream« ist — das wissen Motorola Milestone-Nutzer nur zu gut; das Droid in USA ist bei Moddern sehr beliebt, sein europäischer Cousin Milestone hingegen ist mehr so das fünfte Rad am Wagen.
Aber zurück zum POV-Tegra2: Es gibt Berichte, daß »offizielles« 3.0 aka Honeycomb kommen soll wie auch Aussagen, derlei käme nicht. Aber das schöne an verbreiteten, baugleichen Geräten ist ja, daß man nicht mehr auf den eigenen Hersteller warten muß: Horden von Entwicklern/begnateten Fricklern kümmern sich darum. Wobei man sich natürlich die Frage stellen muß als Anwender – Google als treibende Kraft hinter Android noch viel mehr –, ob man eigentlich sich Honeycomb wirklich antun will:

@gbrockhaus Na, ja. Einige Apps, die nicht für Honeycomb “optimiert” wurden (für 2.x gebaut wurden) neigen öfters zum Force Close. Leider.

Quelle: @_refugee_ auf twitter

 
Derzeit scheint mir 3.0, und nicht nur wegen der Nullerversion, wenig attraktiv; Eye-candy, toll — aber was ist mit Funktion vs. Bedienbarkeit? Klar, 3.0 ist ein großer Schritt in die richtige Richtung; vom bislang einzig erhältlichen Tablet mit dieser Version hört man aber nach initialer Begeisterung überwiegend Negatives :-(

Der Market ist über Umwege zugänglich, aber eher leer …

Erste Eindrücke vom Tablet: nifty. Und: heavy. Denn das Tablet, was dem Vega Advent sehr ähnlich sein soll, wiegt schwer. In der Hand, linkshändiges Halten ist nicht so spaßig. Aber, wie man hier hoffentlich erahnen kann, endlich ein Tablet mit funktionaler Texteingabe, auch wenn meine Finger sich noch nicht so ganz dran gewöhnt haben und Umlaute richtig nerven – letzteres ist aber ein allgemeines Problem zwischen mir und Android.
Kurz die Highlights: Market über Community-Package installierbar, aber viele Programme werden als inkompatibel angezeigt, über Umweg Market > Milestone > APK > Tablet ist vieles installierbar, insbesondere GPS-Anwendungen aber zieren sich: foursquare, My Tracks, … Und das leider, obwohl z. B. Google Maps schnieke mit einem BT-GPS arbeitet, ‘Bluetooth GPS Provider’ sei Dank. Auch cool – Linux Unterbau eben -: uvcvideo-kompatible Cams lassen sich per USB anschließen und statt dem eingebauten Rauschwunder verwenden; statt, denn Android 2.2 kennt ja nur 1 Camera (warum auch immer dann die mit höchster Devicenummer genommen wird; nettes Gimmick jedenfalls, gäbe es Videochat denn für FroYo schon).
Mehr, auch zu Flash auf dem Gerät, später …

Maximaler Füllstand erreicht – Zeit für den 2. »MiFi«

Wie hier schon zu lesen war, Mittwoch war Sushi-Tag beim lokalen »Sushi-Man« in Gütersloh, zusammen mit @_refugee_ @ifranz war ich ( @wusel wer das noch nicht mitbekommen haben sollte) also mal wieder bei unserem »Lieblings-Sushi-Macher« in GT; @BlackAlien stieß diesmal später noch hinzu.
Bei dieser Gelegenheit hatte mein »mobiler Hotspot«, ein Huawei E5830, seinen ersten großen »Auslauf«, denn ich gab’ natürlich Alex’ iPad (non-3G) gerne darüber Zugang. Zu diesem Zeitpunkt versorgte mein »E5« schon meine vier Smartphones (2 davon Androiden, da ich meinem o2-Milestone mit inoffiziellem FroYo (Motorola kam ja nicht in die Puschen) D2 nicht mehr antun will – mit der D2-SIM sind Abstürze an der Tagesordnung, mit o2- oder Tchibo-SIM hingegen läuft es hinreichend problemlos). Des Rätsels Lösung – der Tweet mit dem Bild von 5 »angeschlossenen« Geräten sorgte für überraschte Nachfrage – lautet also: 4 eigene Geräte benutzen schon meinen Hotspot, nur eines der fünf versorgten war wirklich ein Gast.
Dafür, und für das durch die eingesetzte SIM bestimmte Netz, hat mein »E5« seine Sache, denke ich, recht gut gemacht. Nachdem @elburro mich jüngst auf eine Android-App aufmerksam machte, die die letzten Geheimnisse dem Androiden entlockt – die Verbindungsgüte auf Mibilfunkebene –, werde ich damit wohl in Zukunft noch etwas rumspielen, insbesondere, wenn der E5 nicht zu performen scheint ;)

Morgens …

Wie ja schon in Space-Age-Tachometer angedeutet, habe ich mein kleines »Bluetooth-Display«, das SE »LiveView« wieder hervorgekramt und, nachdem etwas Zeit ins Land gegangen ist, gibt es auch ein paar neue Plugins hierzu.
Wirklich zufriedenstellend funktioniert aus meiner Sicht keines, das »Camera«-Plugin startet zwar die Kamera-Anwendung auf dem Milestone und gelegentlich gelingt auch eine Fernauslösung, aber das Foto wird nicht – miniaturisiert, denn LiveView hat ja nur irgendwas bei 100×100 Pixel – übertragen;

… und abends

»MicroTracks« startet leider nicht »My Tracks« auf dem Mobiltelefon, sondern schreibt nur »Waiting for “Record track” in My Tracks app« auf den Mini-Bildschirm — also heißt es doch: Milestone rauskramen, »My Tracks« starten, »Track aufzeichnen« antippen, Milestone wieder so wegpacken, daß der GPS-Empfang gesichert ist …
Komfort ist anders. Aber diese Kombination gibt einen netten »Fahrradtacho« ab, einen, der im Anschluß an die Fahrt auch noch nette Graphen (auf dem Androiden natürlich ;-)) ausspucken kann – und jetzt wird mir auch klar, warum, ganz anders als psychologisch ja erwartet, es mir abends immer so anstrengend vorkommt, nach Hause zu radeln: das geht wirklich überwiegend bergauf dann …

An sich sollte ja nur der Empfang öffentlich-rechtlicher Kanäle per PC am Alice-DSL-Anschluß möglich sein, wie es auch bei T-Entertain der Fall ist.

Hmm, auch die Privatsender werde bei Alice vlc-tauglich übertragen? Cool!

Nachdem ich mit einigen Kilmmzügen meine »Fritz!Box 7170« (in Wirklichkeit ein »gefritzter« Speedport W900V) Alice-IPTV-tauglich gemacht habe, stand nun der Test an; und nachdem in den Playlisten auch RTL auftauchte, dachte ich mir, ich probiere das mal — von den Dekodierungsproblemen aufgrund mangelnder GPU-Unterstützung abgesehen, scheint mir Alice nicht nur den öffentliche-rechtlichen Kram, sondern auch die Privatsender per IPTV unverschlüsselt zu

ÖR sollte gehen, RTL Group/P7S1 nicht …

Das halte ich insofern für konsequent, da ich die Bereitschaft in Deutschland für etwas, was »frei« vom Himmel kommt (öffentlich-rechtliche als auch private Sender), bei DSL, Kabel & Co. zusätzlich zu zahlen, für gering einschätze. Jeder Hauptschüler dürfte die Frage, ob einmalig 99,– mehr sind als 12x 9,95, korrekt zugunsten der SAT-Schüssel beantworten, warum sollte ich also einem Kabel- oder DSL-Anbieter monatlich auf ein Jahr gerechnet mehr zahlen, als mich die olle Sat-Schüssel kostet? Zumal ja die TV-Bandbreite von meiner gebuchten Kapazität abgezogen wird (zaubern können auch die DSL-Anbieter nicht), ich bei TV-Nutzung also weniger IP-Bandbreite zur Verfügung haben als »bezahlt« …

Erfolg: Begrenzung der Bandbreite per Fritzbox

Seit Herbst letzten Jahres versorge ich einen (mittlerweile Ex-) Kollegen im Appartment nebenan internetmäßig mit. Anfänglich hatte ich eine Fonera mit OpenWRT verwendet, um einen Accesspoint für ihn zu stellen, der Traffic sollte über einen eigenen OpenVPN-Tunnel laufen und darüber reguläre IPv4-PI-Adressen aus einem meiner Blöcke, im whois korrekt auf meinen Kollegen eigetragen, benutzt werden — sollte er darüber Bockmist bauen, gibt es kein Vertun hinsichtlich der (rechtlichen) Zuordnung … Eigentlich bin ich ja auch ein Fan von OpenWRT und der Fonera, aber leider habe ich mit aktuellen Versionen hier nur Streß;

Änderung von 16000/1000 auf 6000/300: Yeah!

nicht nur, daß kein Bridging WLAN-Ethernet möglich ist, meine Foneras schmieren auch regelmäßig ab, wenn ich versuche, per opkg Software nachzuinstallieren.
Nachdem beim Versuch, ‘nen Trafficshaper nachzuinstallieren, die Fonera wieder einmal aufmuckte, diesmal aber nicht nur bis zum Reset hing, sondern final nicht mehr hochkommt, habe ich die bekiffte Fonera durch einen gefritzten Speedport (W900V aka 7150 aka 7170 plus DECT) ersetzt, auf der ja auch bequem ein OpenVPN-Server an den Start gebracht werden kann.

Den OpenVPN-Tunnel als »Hintergrundanwendung« klassifiziert: nur die halbe Miete

Auslöser des Ganzen war letztlich der Wunsch, die Nutzung über jenen Accesspoint zu begrenzen, denn es fiel zufällig auf, daß, obwohl ich keinen nennenswerten Traffic erzeuge, die Verbindung laggy war. Da ich auch über diesen Link auf meine Musiksammlung zugreife und es hier zu Aussetzern kam, war Abhilfe zu suchen.
Ein erster Schritt war dann die »Abwertung« der Verbindung des OpenVPN-Servers auf der Fonera auf der DSL-Fritzbox, sodaß dieser Traffic nun von lokal erzeugtem verdrängt würde. Aber hundertprozentig erschien mir diese Lösung nicht, daher wollte ich eigentlich schon auf der Fonera den ausgehenden Traffic begrenzen — beim Versuch beging die Fonera Selbstmord …
Wie sich später herausstellte, nachdem ich die Fonera durch eine Fritzbox ersetzte und auch den OpenVPN-Tunnel wieder oben hatte, beeinflußt die eingestellte Bandbreite einer Fritzbox im »Internet über LAN A«-Betrieb die Menge an Daten, die die Fritzbox in Richtung Internet durchläßt — sweet!