Slashdot Mirror
John Carmack on Coding a Linux IP Stack & Winmodem
An anonymous reader pointed us to an interesting article over at Shugashack talking about John Carmack wanting to
rewrite the Linux IP stack and write a software Winmodem driver for Linux. He wants to squeeze the latency out of both of these components to try to kick MS into gear to write better stuff on their side. If it turns out true, it could be pretty cool for gamers on both platforms. Don't put any stock in it, its just a rumor, but its interesting.
http://www.linmodems.org/
^-- This group has been working on the winmodem drivers for linux for quite a while. There are even plenty of goodies to download.
Eh...
The /. post doesn't begin to explain what this is about, so here you go:
From a Gamespot write-up on PowerPlay:
PowerPlay, a set of standards and protocols that will apply to both game developers and Internet service providers (ISPs). By working on both sides of the problem, PowerPlay promises to bring LAN-like gameplay to a modem near you. If you think that sounds like something that is well beyond the range of a single company, you are right--and that's why Newell got Cisco Systems involved.
Newell is Gabe Newell of Valve, makers of Half-Life. The reason Carmack's doing this is to contibute to the PowerPlay project.
John...wants to take a stab at rewriting the Linux IP stack and a soft modem driver to see how much latency he can remove, and use that to pressure Microsoft into cleaning up the Windows stack. That would be really useful data to have.
And here's the official PowerPlay website.
Pablo Nevares, "the freshmaker".
Pablo Nevares, "the freshmaker".
It seems they're very afraid of him for two reasons. One has been touched on several times here already; if he chooses to support some sort of gaming api that they didn't develop (graphics, sound, what have you), it makes it nearly impossible for them to gain a stranglehold on that aspect of the system.
Their real fear, though, is apparently that his gaming engines are damn near operating systems unto themselves, and should he decide to turn them into a 3d operating environment, he'd eat their lunch with it.
The report that the guy returned to them basically said it remained to be seen if Carmack was interested in such a thing, but that should he decide to do so he would pretty much own that arena. So I'd say that should he do something with the specific intention of making them pay attention, pay attention they would.
I'm in Hawaii right now and don't have my login info, so you can take this or leave it on sort of John-Carmack-Turing-Test terms.
No way do I intend to rewrite the linux TCP/IP stack.
I had mentioned to Yahn that it would be an interesting experiment to yank all the networking code (TCP/IP + PPP + serial driver) into user space so some cross-boundary optimization experiments can be made. I doubt there is any apreciable latency in the TCP/IP stack, but there might be some scheduling losses somewhere through PPP and the serial driver. Even if a send packet call goes syncronously all the way to the serial ring buffer, giving no real potential for latency reduction, there are still lots of possible experiments with making decisions based on normally hidden data.
Just like the GLX driver work is Good For Me as a graphics programmer, going through all the guts of the networking stack would be Good For Me as a netowrking programmer. I may pursue this, and I may collect some interesting data, but I seriously doubt it would be any contribution to the standard network stacks.
I had a long talk with a couple people from Valve about the PowerPlay initiative, but they couldn't give me enough specific technical details for me to endorse it. I'm all for improvements in networking infrastructure, but at this point, there isn't anything actually there, just an intention to improve gaming. They need to tell me SPECIFICALLY what I am supposed to be endorsing. At some point, bits have to go into packets and routers need to make decisions on them. Changes at that level is what I want to hear about, not strategic company relationships.
Some networking things that could be real improvements:
UDP header compression. I am still surprised this isn't a standard.
An ioctl to set modems to a realtime mode that makes different tradeoffs in modulation, error correction and compression. I'm not sure if the modem standards allow things to be renegotiated dynamically or not.
Making routers actually pay attention to QoS bits, and defining specific queuing behavior for them. A "realtime" packet should never be added to a queue if there is another one from the same connection that is already in the queue. Multiple queuings just add latency that can't be controlled at the application level. Jump-to-head-of-queue would sure be nice, but that's probably too much to ask for in the name of "games".
I have commented in the past that software modems have the (unrealized) potential to reduce latency over conventional modems. There is some savings by just avoiding a serial FIFO, but more savings could be had be integrating more knowledge from higher levels of the communication stack. Specifically breaking modem comrpession/error correction packets at PPP boundaries (or avoiding them altogether when apropriate), for instance.
John Carmack
Making routers actually pay attention to QoS bits, and defining specific queuing behavior for them.
This is happening, largely as a result of an IETF standards effort called DiffServ, which is defining building blocks from which the network behaviour required by a particular application can be provided, even in the presence of network congestion. Most routers today can interpret 8 priority levels (IP Precedence) of which 6 are user accessible - unfortunately they are not set up to do this because it is a configuration nightmare. The good news is that my company and others are going to take out the configuration hassle and make it easy for ISPs to configure their routers for DiffServ (we make network management software to configure this).
Most twitch games will want priority queuing, or at the least some guaranteed access to bandwidth for critical packets. Unfortunately this is exactly what Voice over IP (VoIP) requires, which is probably much more lucrative for the ISPs since it can be charged by the minute... Dedicated gaming networks may well be able to set priorities that make sense for gamers, though.
A "realtime" packet should never be added to a queue if there is another one from the same connection that is already in the queue. Multiple queuings just add latency that can't be controlled at the application level. Jump-to-head-of-queue would sure be nice, but that's probably too much to ask for in the name of "games".
This is like many multimedia applications, e.g. VoIP and videoconferencing, where if a packet is delayed it is no use so it might as well be dropped. One approach to this is for the application to become adaptive (or maybe the IP stack or linmodem code, given some hints from the application), i.e. to not send packets so frequently in times of congestion. At least then the offered load to the network is reduced, which is important in the non-DiffServ case.
The other approach is to use DiffServ to implement a low latency service, in which every suitably marked packet goes right to the top priority queue. Through careful limiting of what traffic gets into the network with that packet marking, the idea is that the top priority queue is almost always empty so low latency packets go right through every router with minimal queuing delay.
It's worth noting that if the queuing is working properly, the 2nd packet should never run into the first packet anyway, so it's probably easier just to throw DiffServ at the problem. This also avoids the need to keep track of things on a per-flow basis - when there are 1000s of real-time sessions going through a larger router, you really don't want to have to keep track of sessions (aka flows in QoS speak).
The Linux host sending the packets could implement the 'dump earlier packet' behaviour in its queuing mechanisms, but it would have to be per-flow, and the same arguments apply - it's better to reduce host, modem and router latency so that the packets go right through and have no chance to bump into earlier packets.
If you're interested, the Linux-DiffServ project is based on the 2.2 kernel - they've done a pretty flexible and complete implementation. More general links on QoS including DiffServ can be found here, under the Links button.
DiffServ technology is coming, and in fact exists in basic form in every Cisco router. The big issue for gaming is getting ISPs to implement DiffServ, and to charge for it in a sensible way so it's accessible to gamers.
A better way to do this is to have the modem accept blocks from the networking software and send packet-sized blocks as blocks. Get rid of the serial port emulation entirely; it's an anachronism and a bottleneck. We'd then have an IP modem. No more PPP byte-stuffing and control character translation.
The hardware interface for a Winmodem potentially makes this possible with existing hardware. So it's feasible to do this in software alone. Both ends of the wire have to talk the new protocol, so the ISP end has to be updated too. But many of those systems have a T1 in one side, an Ethernet out the other, and a DSP in the middle, so they're reprogrammable.
Good move. Go for it.