Willkommen

Dies ist meine persönliche Homepage. Sie ist ziemlich zweisprachig und deshalb hängt es von meiner Stimmung und Ihrem Glück ab, in welcher Sprache Sie hier die Dinge finden können.

Nachfolgend sehen Sie die letzten News. Um alle News in der gewünschten Sprache anzuzeigen, nutzen Sie bitte die Navigationsleiste links.

Welcome

This is my personal homepage. It is quite bilingual and thus it depends on my mood and on your luck which stuff you will find in which language here.

Below you will see the latest news. To view all news in the desired language please use the navigation bar on the left side.


E-Auto Frust07.08.2019

Jaja,
wir sollen alle E-Autos kaufen. Und dann? Wenn es denn tatsächlich Ladesäulen gibt, werden schlappe 60 Cent je Kilowattstunde verlangt. Hat der Bundesbenzinkanister etwa Anteile gekauft? Und da es ja E-Autos gibt, die an diesen Ladesäulen mehrere Stunden zum Aufladen brauchen (man sehe sich mal z.B. die Ladezeit eines Renault Kangoo Z.E. an), muß man wohl für jedes Aufladen einen Urlaubstag oder besser gleich eine ganze Urlaubswoche einkalkulieren und einen Wohnwagen mitbringen, um die Wartezeit zu überstehen, bis man beim Laden dran ist. Gut wenn man eine Garage hat, dann kann man ja da laden... - allerdings gibt es genügend Menschen ohne Garage, genügend Garagen ohne Stromanschluss und genügend Garagenstromanschlüsse ohne ausreichende Leistung. Ich muss da bloß die hauseigene Garagenanlage betrachten. Eine mit 16A abgesicherte Steckdose je Garage. Das ist zwar "schon viel", aber: für ein E-Auto werden zum Aufladen in akzeptabler Geschwindigkeit 10KW oder aber 3x16A benötigt. Das je Garage. In meinem Fall wären das also bei drei Garagen 3x48A. Das Haus ist aber typisch versorgt, somit gibt es eine Absicherung mit 3x50A. Verbleiben also für Hausstrom und drei Wohnungen 1380 Watt verfügbare Leistung. Anders ausgedrückt muß also in den meisten Fällen die Zuleitung zum Gebäude und die Hausabsicherung auf mindestens die doppelte Leistung ausgelegt werden, bevor man überhaupt an die Leitungsverlegung in Richtung Garage denken kann. Schöne Grüße an den lokalen Netzbetreiber und die nach eigenen Angaben eh schon überlasteten Tiefbauunternehmen. Dies zuzüglich der juristischen Probleme, die es bei Gebäuden mit mehreren Eigentümern gibt, wenn die anderen Eigentümer nicht mitziehen - Goodbye Ladestation, Goodbye E-Auto.

Laut Bundesbenzinkanister also auf-auf zum Plugin-Hybrid. Oder anders ausgedrückt: 500kg totes Extragewicht, das von einem viel zu kleinen E-Motor nebst ebenfalls viel zu kleinen Akku bewegt werden muss, dafür aber doppelt so komplexe Technik und mal eben fast doppelt so teuer. Unsinn, der nur auf dem Mist unfähiger alter Politiker und Manager wachsen kann (ja, ich habe auch dieses Alter, aber im Unterschied zu denen kann ich noch klar denken). CNG oder gar Wasserstoff sind auch nicht besser. Da mutiert dann der Kombi zu Cabrio, weil der Rest des Platzes von den Gastanks benötigt wird, über deren Gewicht wir besser erst gar nicht reden wollen.

Dabei gibt es durchaus eine Lösung, die einen Übergang für die nächsten 20-30 Jahre, in denen die Infrastruktur für reine E-Autos aufgebaut wird, darstellt. Es müssen E-Autos mit einer Leistung und Akkugröße gebaut werden, für die 1x16A ausreichen, um das Fahrzeug über Nacht aufzuladen - plus einem klassischen Generator, der 10-20KW liefern kann, als Range Extender. Solche Generatoren haben ein Trockengewicht von etwa 100kg, das im Fall eines größeren Akkus ebenfalls spazieren gefahren würde. Ein Tank von 10-20 Litern wäre bezogen auf das vorhandene Tankstellennetz ausreichend. Es ist schon ein Unterschied, ob ein Fahrzeug 5 order 50 Liter Treibstoff im Monat verbraucht. Ein Reduktion des Treibstoffverbrauchs um 90% bei etwa 50% der Fahrzeuge klingt doch für eine Übergangszeit absolut nicht absurd. Und die Technik muss dann ja nicht entsorgt werden. Es wird auch in Zukunft genügend Fälle geben, in denen ein Range Extender zwingend erforderlich sein wird - oder aber als fiktive Schlagzeile: "Der verunfallte Patient ist auf dem Weg in das Krankenhaus verstorben, da die Battereien des Rettungswagens leer waren und die Aufladung 60 Minuten benötigte, nachdem sich der Fahrer zuerst noch die geeignete Aufladekarte erbetteln musste, da der Vertrag der Rettungswache nur die Aufladung beim günstigsten Betreiber nach VOB vorsieht".

Ich kann mich nur wiederholen und hoffen, dass die berliner Berufs-Altzheimer-Patienten es sich doch irgendwann merken. Elektromobilität funktioniert für die nächsten Wahlperioden nur in Verbindung mit einem Range Extender, egal welche Lobbyisten etwas anderes behaupten. Und wer diese Technik, sowie heimische Ladeinfrastruktur nicht gezielt fördert, sollte sich lieber schon mal einen Stammplatz in der nächsten Sargeteriea sichern, da gehört er oder sie nämlich hin. Und das ohne üppige Bezüge.

Mir jedenfalls bleibt nichts anderes übrig, als mir wieder einen Verbrenner kaufen zu müssen. Mit "Sicherheit", so wie es die regierenden Parteien ja so gerne propagieren. Totale Überwachung ist eben wichtiger als sinnvolle Förderung, gelle?


The sad state of eBPF15.05.2019

 eBPF could be cute. Really cute. One could do smart in-kernel network packet processing. Except that there's really huge roadblocks.

First of all there is no usable documentation. One has to collect bits and pieces from all over the internet. Then LLVM compiled stuff quite often does not fit the bill as efficient eBPF code needs to be runtime modifiable before it is loaded into the kernel. Now how one does this with compiler output in ELF format? Arrrghhh!

So I did write a little eBPF to C assembler (find it here). And things look great again. 11 registers, let's start developing - until the in-kernel verifier kills register usage. It looses track of r1 to r5 even on simple conditional branches. So 5 registers are so volatile that they are merely unusable. This still leaves 6 registers. Not quite so. r0 is quite often implicit soure or destination, so it is only half usable. r6 is expected to contain the context pointer you do need to be able to access the packet data. And r10 is the frame pointer that one needs to be able to call helper functions. So only r7 to r9 are left that one can actually use. Compared to cBPF which does have an accumulator and an index register (which I do count as a half register) you have 1.5 cBPF registers versus 3.5 eBPF registers. Not much improvement here.

Then you want to access packet meta data, e.g. the source address, from an eBPF program that is attached to a UDP socket. The data is there. But you are not allowed to access it. Doh.

Now you look at the helper functions and get the idea, it would be nice to move certain received packets to another socket. Could save userspace complexity. Go, try. EINVAL. Not only that one has to read through a pile of kernel code to find out that related code requires additional kernel configuration to be compiled in, the gods of eBPF added extra insult to injury by allowing packet transfer only for TCP. Why, only why??? Isn't UDP or raw packets even simpler than TCP? And what about SCTP? Did somebody pay to prevent socket transfer for raw and UDP sockets?

Then you don't want to enable the eBPF JIT system wide but only for "proven" eBPF code whereas code under development should be interpreted. To no avail. There's a huge slew of parameters to the bpf system call but there is no way to do a system wide "use JIT if told so" configuration option as well an no "I want JIT" bpf call option. Who designed that?!? Now, if JIT fails to work properly for a single eBPF program one has to disable eBPF JIT system wide. As Stephen King wrote: "new and improved" (Tommyknockers).

And then such stuff like eBPF cgroup programs. Oh, not programs, a single program per cgroup. You are allowed do more in a cgroup program. Except that cgroups are (ab)used by distros and it is not so easy just to create a cgroup here, a cgroup there, ... - without overall concept you will create a mess of your system and one really doesn't want an application to create cgroups on the fly, especially as there's no one there to clean up afterwards.

In the end it boils down that from an application point of view only socket filtering makes sense. And this is artificially so restricted that writing eBPF code for this purpose is not much fun. The only reason to do so is the dreadfull slowness of [e]poll.

All other network related eBPF use cases seem to be custom tailored for expensive and specialized big iron. So after all for the more common use case eBPF is sadly nothing more than a helper to workaround kernel slowness.


[e]poll bottleneck15.05.2019

 [e]poll on Linux is slow. Very slow. To be more precise: slow as a dead horse. 45us on a system where a clock_getttime syscall (yes, the syscall, not the vDSO) takes 335ns and a read call via library takes 4us. This is on a i7-7500U CPU @ 2.70GHz (not fast but not that slow).

So lets do some quick calculation for a process receiving a UDP packet and answering with another UDP packet: 45us epoll + 10us recvmsg + 35us sendmsg + 10us userspace data processing. So every single packet received and replied to takes 100us and only 10% of this time is actual packet processing. 50% of the remaining 90% is consumed by a single [e]poll call. And, yes, 100us means no more than 10000 packets per second and core which in case of 1K packet size resorts to a network throughput of only 80Mbit/s for a single core. This is horrible.

And there is no workaround, recvmmsg is more often than not unusable for an application as usually signalled data from [e]poll means a single received packet is pending. And if only a single packet has to be sent sendmmsg is unusable, too.

And this is why one should learn a little eBPF assembler (no, not LLVM compiled stuff, handcrafted code). Especially if the application in question may be attacked. The basic data checks need to be processed in-kernel as the epoll+recvmsg overhead is so huge.

Hopefully the responsible kernel developers will one day understand that [e]poll is a fast path and requires a race horse, not a dead one.


The sad state of smartcards on Linux22.12.2018

Well,
the idea is simple: use a smartcard reader or a CCID compliant USB token and get rid of passwords. Simple, isn't it? That's, until it comes to practice. First of all, many smartcard vendors are still going the vendor lock-in way and even with smartcards or tokens one can configure under Linux there are roadbocks:

There's a stack, consisting of the smartcard driver, e.g. CCID, then there's PCSC-Lite, then OpenSC, followed by libp11 and finally OpenSSL. All different developer groups, seemingly no real communication resulting more often than not in broken interworking or sudden parameter changes. Documentation is sparse at best, users are left alone in the dark, developers need to use trial and error. Furthermore certain functionality is missing with no easy way to push required code upstream.

Take for example the CCID driver. Suddenly smartcard names are changed. Nobody cares if this could make problems.

OpenSC developers don't take patches in unified format, one shall make a master degree in git usage first instead, bah! I still have to investigate why 0.19 does seemingly break libp11 and thus my applications.

As for libp11 there was once another library to be used instead which was abandoned - no information that libp11 was to be used instead. Then there's missing functionality, e.g. the 'door opener' slot of a smartcard doesn't need and doesn't want a pin, so let's patch...

OpenSSL engine documentation is, well, horrible as well as non existing. Reading the sources is not the way it should be.

Having to use library pathnames to configure the stack doesn't really help portability at all.

It's bad for developers and nearly impossible to use for end users.