Re: Steaming Videos
> But ... but... doesn't Systemd do this already?
Yes, all that and more. But it was Linux they were talking about, not systemd (which is something entirely different, and totally incompatible with Linux).
Back in September, The Register's networking desk chatted to a company called Teclo about the limitations of TCP performance in the Linux stack. That work, described here, included moving TCP/IP processing off to user-space to avoid the complex processing that the kernel has accumulated over the years. It's no surprise, then …
With "VM" now the Kernel, the OS (e.g.Linux) is now in "tool-space" . Next logical step is to have direct user-space Docker-space calls for high performance operations.
(My last real coding work was using a <1Mb Unix sys5 kernel, which looks and feels like a VM container to me!) and with a 4MHz 68000 you NEVER copied when you could pass pointers!)
If my grey cells haven't gone too grey then I think HP-UX implemented zero copy network stacks about 18 years ago. I suspect that it was just zero copy inside the kernel but still copied in and out of user space from the system call entry/exit functions. HP-UX wasn't the only one. The 2007 implementation of sendfile should allow sharing of the buffers between user space and kernel space using page aliasing. I don't know the intricacies of the x86 MMU but I guess it isn't using a global VAS and so this should be easier.
She's told me, when I asked, they don't have the resources to do a Linux version of iPlayer, yet from this article they clearly have in-house Linux skills. Liar, liar, knickers on fire, Aunty!
Ah well, I'll just keep on using get-iplayer (which I know Aunty Beeb doesn;t like) until Aunty Beeb decides to pull her finger out and create a proper iPlayer for us Linux users, then!
I don't understand why the network drivers were written that way in the first place. Ethernet has always used some form of layered protocol, and the most efficient way to build the layers is to add each header to the front of the existing payload, not to create a whole new buffer and copy the payload from one buffer to the next. It just means that whatever creates the initial buffer must leave space at the front for the largest possible combined header size. I've written several LAN stacks for small, slow 8-bit CPUs, and if the payload had to be copied from one area of RAM to another 2 or three times per packet the performance hit would have made the device unusable. Even the Rx buffers were set up to have a lot of free space at the start in case the data was going to be retransmitted, in which case the appropriate Tx headers could be prepended and the Rx buffer used as the Tx buffer.
I would have thought that such a specialised application would be best built from scratch rather than running under a general-purpose OS. By all means use off-the-shelf PC motherboard and components, but boot straight into your bespoke code. GUI controls and other stuff that is not time critical can be implemented on a completely different machine running any standard OS, and the raw directives & variables fed to the custom machine via a link (e.g. another LAN port, USB, infrared, even serial etc.)
For me it would be very interesting to observe how Linux developers will be trying to grind this problem.
Seems that kind of issues needs to be solved by major re-architecture. Something which is complete opposite of how Linux is progressing on dealing with some issues by trying to change state from A to B by series of small modifications.
Seems at least Linux clashed with something enough big which cannot be solved using Linux TraditionalWay(tm).
Biting the hand that feeds IT © 1998–2019