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".
[disclaimer: I may have no idea what I'm talking about]
I believe part of Carmack's goal in rewriting the stack and working with softmodems is to specifically allow game optimizations. (duh)
One limiting factor in Quake's internet performance is the lag time created by poor modem implementations. Many modems are excessively stringent about enforcing buffering, with the effect that my ultimate last ditch blaster shot is delayed because the 'modem' wanted to fill its buffer.
In theory, rewriting the stack and modem support while stress testing it with a busy quake connection will allow inefficiencies to be eliminated.
I doubt that there is anything 'wrong' with current linux implementations - they are just naturally focused on http/ftp designs.
Zephyr
Alfredo
Carmack wields a lot of power in the PC world. When he publicly came out saying that id would develop games for the MacOS, Apple's prestige rose significantly. When Carmack said he liked MacOS X, Apple's prestige again rose. One of the major barriers to leaving Windows has been the superior gaming support. Tied in with Carmack's OpenGL coding, he is working hard to make Linux a viable gaming platform. When a programmer as respected and as good as Carmack says that something is flawed and he is going to fix it, people like Microsoft listen. They may not do anything, but they certainly listen. If Microsoft were to lose a chunk of the gaming market to Linux (and many gamers have the technical and 'Net experience to jump ship to Linux pretty easily), they would definitely feel it.
Of course *real* modems have their advantages, especially for people who want the least CPU utilization and lowest ping times, especially gamers or for dial-in servers. But there isn't anything inherently evil about software-based modems that require us to stamp them from the earth. Remember the big trend a couple years ago towards multipurpose DSP's that could drive your modem and your sound card (for instance, MWave)? They're great ideas... IF the companies that designed and built them allowed others to tap into the power and support other platforms.
--bdj
I guess he wouldn't mind John's input but the statement in the linked article seems to imply that John thinks the Linux IP stack is flawed.
If you think it's not flawed, you have a serious misconception about Linux.
If you think Alan Cox would be perturbed by someone wanting to fix it, you have a serious misconception (or, more probably, a series of them) about Alan.
Now, is it fatally flawed? No, of course not.
BTW, although Alan did the initial work, there's an awful lot of other people's code in there. I don't hang out on the kernel lists, but I don't believe Alan would have a claim on it as "his code", even if he were inclined to make such a claim.
It's moot, however, because the GPL makes it our code.
Usually, when John Carmack says that he's going to do something, he sets about doing it, and he already has plenty of experience with network optimization coding (e.g. Quakeworld). I would give this a bit more credit than a 'rumor'.
Blue's News went into a bit more detail about why this quote means what it means. Yesterday, Cisco, Valve, and others mentioned a new concept called PowerPlay which is something that will involve ISPs, equipment, and software code. Epic is already coding PowerPlay information into the Unreal Tournament engine so that they and others will be able to take advantage of it. Basically, PowerPlay is a ISP-side enhancement to improve the quality of dial-up gameplay.
The reason Carmack is quoted here is because id wasn't on the list of companies officially supporting PowerPlay. As you can well guess, this raised many eyebrows in the gaming world, and the reason is simply that Carmack didn't want to be involved with the implementation of it. No doubt, id will put code in their upcoming products, but Carmack himself doesn't want to do work. Why? Other projects.
Also, Gabe Newell is pretty well respected in the gaming community, so these words probably aren't meant to give rise to any rumor mills. They're probably the truth.
So as a 'rumor', it's a very well-founded one. Carmack is familiar with Linux program, so I'm sure the concerns about Carmack possibly interfering with the work of others will turn out to be baseless. It'll all work itself, and if we get any code out of Carmack, it's bound to be very good code.
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.
A software modem could be a huge win. First off, you are no longer pushing your data through a 16 byte fifo buffer, that is costing you over 300 interupts a second at 53k, and that boils down to a lot of cpu time. Second, the modem hardware is good for at least 60ms of your latency, acording to the guy behind an old popular macintosh network game Bolo, which was writen to studdy networking issues.
So a software modem that knew ip could help a lot, and be much nicer than an old style hardware modem
Plato seems wrong to me today
This would also have some interesting implications not only with Microsoft, but say, Apple, in that both vendors would be challenged to improve TCP/IP performance in order to keep pace with Linux
I don't quite get this argument that if Linux improves its TCP/IP stack, the Microsofts and Apples of the world will begin shaking, suddenly stop what they are doing to completely rewrite a critical piece of their respective OSs that have been through years of debugging. I mean, Oracle makes a hell of a better database with many more features, but did that stop them from releasing Sql 7.0; this software is basically a buggy piece of shit and after one service pack there is still this fucking lame trusted connection bug that affects every single one of our users every single day AND THEY STILL don't have a fix for it yet!!! So I guess you will be waiting a LONG time for your newly rewritten TCP/IP stack. And it's probably just as well, anyway. That's what makes Linux so alluring, so attractive. Bugs get stomped out right away, and the ones that don't at least you can fix yourself!
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
I think its a computer
LetterRip
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.
I probably shouldn't respond to this obvious flamebait, but...
Jesus Christ, it seems like about every technology is in a "this is being fixed" or "it's planned for release soon" stage on Linux.
Uh, and this is different from other OSes how? Microsoft is always saying the same sorts of things. Otherwise everyone who was using NT 3.5 would have just stayed there and not upgraded to 4.0, and the people on 4.0 wouldn't be at all interested in 2000. Even the commercial UNIXes have areas they are working on improving. This is something that is industry wide.
Now do you see why people who've been computing for years (read: grown up since the HaX0r days, actually work with modern OSes)
How about someone who is in their mid 30's, and works every day with Solaris, works occasionally with AIX and IRIX, and has the occasional misfortune of having to deal with Windows NT? I've tried the *BSDs as well.
just might think Linux is a piece of shit toy OS?
Actually, I think only people who have some sort of ulterior motive or are incredibly stupid would think that. For most people and most purposes, Linux is pretty good already. Is Linux perfect? No. Is any OS perfect? No. There are areas where Linux is better than the *BSD's and areas where the *BSDs may be better than Linux. There are areas where the commercial *nixes are better than Linux, and areas where Linux is better than the commercial *nixes. In my opinion, Linux is better than NT in just about every way that matters, other people may not agree. Sure, you can come up with wacky configurations and benchmarks to prove whatever you want, but those things matter little in the real world. Let me set up the parameters for the test, and I can prove that a Geo Metro can outperform a Lamborghini Diablo (one answer below).
Have fun waiting around for it.
As slow as Microsoft is, I think I will have less time to wait to get important things with Linux than I would have to if I used NT.
Now for the answer to the Metro vs. Diablo: Give each of them only 5 gallons of gas and a 200 mile course. The Metro wins as the Diablo would have to be pushed more than half way.
Buffering is the main problem. You have to look at the end-to-end system and find all of the places that data is being buffered. Examine hardware and software, add up all the bits and bytes of buffering.
Packet/frame size should be kept small. If it is too large, break it up into a sequence of smaller packets. Transmit four 128 byte packets instead of one 512 byte packet.
If possible, build the packet as it is being transmitted, a word at a time, rather than building a complete packet and transmitting it.
On the receiving side, you can process the data in a packet as it is being received, you don't have to wait for the last byte in the packet.
Error detection/correction hardware and software can add large amounts of latency.
Watch out for FIFOs in the transmitter and receiver. They can add substantial amounts of latency.
The ideal situation is to take a sample of a parameter and immediately put it on the wire. The receiver then processes the sample as soon as it receives the last bit of the sample.
A slower modem speed may actually reduce latency if it enables you to avoid the use of error correction. A dumb modem is the ideal.
Mea navis aericumbens anguillis abundat
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.