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.
Anyone have any more information on this? Also, does anyone know if the winmodem driver will be opensource?
I thought we already get a new stack with the 2.4 kernel? Or is the new IP stack so bad it needs a rewrite even before it's out?
-- Remove 'ABC' for real email address.
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...
I'd argue that gamers aren't the only ones interested in having a better TCP stack, but how about sysadmin's and anyone using the net with Linux. 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'm sure the job will be easier for Apple with OS X, since it's based on BSD.
"In individuals, insanity is rare, but in groups, parties, nations, and epochs it is the rule." -Nietzsche
What are you talking about? Are you saying that Carmack want's to sell windmodems? Or that he is going to start charging for his Linux Inovations?
Hmmm... let's look at what he's done, release quality games for Linux, released source code to some excellent games, done some great stuff for openGl. John Carmack is the man!!
/* CDM */
what Alan Cox thinks about John Carmack thinking about rewriting the Linux stack. I thought Alan Cox was the man in that area? 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.
Hates people who have stupid little sigs
I applaud Carmack for his work, if he is in fact going to rewrite the IP stack. However, does he, or anyone else for that matter, think this will "pressure Microsoft" to modify their implementation? Hasn't Microsoft operated with this air of "We'l do what we want, when we want?" Why should this change that now?
mr.nobody
--Don't you wanna go where nobody knows your name?
Nevermind that the intent of writing winmodem drivers for linux is to UN-stifle the poor people who are stuck with a winmodem they can't get to work under a decent, law abiding operating system? I mean, c'mon, how many of us DON'T know someone who got bitten by the "it's a modem for only $30 at Frys" bug???
http://linmodems.org is the place to go for Linux winmodem support.
-russ
Don't piss off The Angry Economist
OK, so I admit that one of the most common complaints that new Linux users have is that they can't get their winmodem to work in Linux. Most of them go out and buy real modems and are then happy. Allowing them to use winmodems in linux however will keep them from ever buying a full modem and seeing that it is remarkably better. Also people will no longer make sure the new system they are getting does NOT have a winmodem. This has one major disadvantage, the companies that make the winmodems will get more and more buisness. Thus the already difficult task of finding a modem that isn't a winmodem will become significanlty MORE difficult. (See your high school economics textbook)
On another note: has anyone figured out how to make an external winmodem yet?
Little Brother, watching the watchers
So, if I'm reading the story right, this means that one person is going to rewrite the IP stack for support for Winmodem drivers. Linux needs more driver support, so I think this is a step in the right direction, but perhaps this should wait for the new version? It's kind of bad for someone to spend the effort on doing this and then have it be obsolete in a matter of weeks.
Phyrkrakr
"God doesn't play dice"-Einstein
Psychic spies from China try to steal your mind's elation.
We can stop this entire thread right now. By saying that JC wants to rewrite the Linux "IP Stack" they're implying that someone as network knowledgable as he is would infer that latency is an artifact of it.
Bzzzzzzt.
Latency is caused by a ton of factors - and the IP stack, unless you're talking about running thousands of clients on a single, multi-processor machine, aint really one of them.
Chalk it up to the rumor mill.
--
Blue
i browse at -1 because they're funnier than you are.
You know, Carmack has posted on Slashdot before:
o hn+Carmack
http://slashdot.org/users.pl?op=userinfo&nick=J
maybe he'd like to comment?
Paolo Wrote:
both vendors would be challenged to improve TCP/IP Performance in order to keep pace with Linux
Ok, you might be right about Apple, but I doubt Microsoft would try to improve their tcp/ip stack. Microsoft would instead realease anther FUD saying that it (Microsoft) has a better overall performance or even better stack for some obscure reason other than standard benchmarks or tests.
Those who don't study history will repeat its errors.
Those who don't will find new ways to error.
-author unknown
Little Brother, watching the watchers
I can't believe this message is anything but a troll. Are there really people out there who would criticize someone for doing what they want to do? Especially someone who has contributed so much to enjoyment in their lives?
:)
If you've never played any of his games of never benefitted from any of his work, then why would you even care what he does?
If you have benefitted from his many years of work, then get over yourself and let the guy do whatever he wants to do. He's earned it!
John's just a man, but it amazes me how many people demand that he keep slaving away at making more games for them, like he's some sort of indentured servant or something.
Of course I know I've just wasted my time talking to someone who probably hasn't done a thing for anyone but himself.
The IP stack of Linux and Windows98 already are pretty good latency wise. More tweaking or even rewriting most likely wont give any significant advantage.
Tweaking a winmodem driver however might result to some reasonable gain (connect with sub-max but reliable speed, switch off compression, tweak modem protocol). But this doesnt change anything on the ISPs side. And doesnt help anyone with an external modem. Or ISDN/ADSL/Cable.
Valves PowerPlay looks much more promising: router-priorization of game packets (less ping, less packet loss), UDP header compression, bandwidth guarantees, later a special modem real-time protocol. And some more stuff like multicast for voice etc.
I really dislike software modems. If you want to decrease latency attributable to modems, the way to do it is optimize the modem firmware ala USR.
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
If the Linux community ever wants to see Linux catch on for the general public, Linux will have to address the needs of the general public. One of those needs is that we'd like our winmodems to work under it. If the Linux community banded together and decided that they didn't want winmodems supported, it could only hurt the OS's chances of winning over "average" users.
If you're to have Linux as the OS of the elite, that's one thing. But if you're looking to see Linux catch on, this is a step that I think needs to be taken.
I haven't spent the hours required to understand all the details, but it sounds like every network stack I've ever worked with. It has a bunch of extraneous implementation details thrown into the claims to make exact matches of prior art unlikely, but that's probably just to drive up the cost of litigation.
I say "go on you silly patenters". It will take a large mass of ludicrous examples to motivate enough voters to overcome the industry lobbyists.
A winmodem is like a video card without the accelerator.
An external winmodem? The closest thing I have seen is from the Sound-HOWTO about using the sound card to impliment 9600 bps FSK methods. This method is more useful for hams, but I'd imagine you could use a modemless laptop coupled to a payphone handset in a jiffy.
But what makes a WinModem bad? Is it the modem itself or is it the code that handles it? I tend to think that it's more of the code than the actual parts themselves. There are definitely benefits to owning a real modem, but if the code is significantly improved, who says a WinModem can't work as well as a real modem?
And I never have a problem finding a real modem now. What problems are you having finding a real modem? Almost any computer parts dealer, online or not, carries regular modems in plenty of stock.
Well, if anyone can "squeeze the latency out of both of these components" it would be Carmack. We still do need a multitasking IP stack, right?
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
Nearly all of the latency present in modems (be they winmodems or high performance dsp based modems) is inherent in the signal processing and reliable link protocols. I'm finding this rumour of dubious value at best.
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.
I have to admit I bought a WinModem for my in-laws over Christmas (a replacement for a "real" modem) as an experiment since performance is foremost in her mind. It actually works surprisingly well. I haven't noticed any real performance problems, although browsing tends to be modem limited rather than CPU limited (well, if your using IE it is. If your using Netscape, the latest Cray isn't enough.)
---
"Don't put any stock in it, its just a rumor, but its interesting."
/. posted a rumor story as fact and other sites grabbed the headline as being true.
Glad to see you are taking some editorial responsibility. When rumors are posted, they should be marked as such. I can remember a several times when
Maybe stories should have a rumor flag on them, so that anyone who wants only serious news can filter? Just a thought.
This sig is false.
oops... I should have said "not foremost in her mind".
---
just how many years to come do you think people will be using modems ?? I think that broadband services will grow faster and faster, because the more broadband owners there are, the more services, like movies on demand will there be, and that will create more people wanting broadband. Also, people not living in houses, but dorms, appartments in cities... will team up and buy a big internet line together. ion++
I find it curious why he would want to tweak the IP stack. I'm sure you might be able to squeeze a bit more efficiency out of it, but I can't imagine shaving off more than a 0.5ms (much less?) versus the 100-150ms the modem introduces.
---
Sounds like jealousy to me.
1. Nobody is forcing anyone to purchase Quake or any other game.
2. His changes would be _free_.
3. I assume his changes would help others, not just Quake customers, right.
4. So what if a person enjoys nice cars? I know I do. More power to him.
5. Don't be an asshole. He's pry brought more enjoyment to people than you ever will.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
For LAN games TCP/IP is way too slow. I use UDP myself, it has very low overhead, and I use only good hardware so there is little collision if any.
Why bother with old technlogy, you won't go many ms under 100 whatever you do.
why not focus on getting broadband to the public instead, I got my switched ethernet connection a couple of months ago, and I havent seen >5ms since.
The serial driver (more specifically, the PPP line discipline code) ia a bigger bottleneck than the IP code ever will be. There is plenty of work that can be done in this area. The biggest gain will be in flushing the completed frame as soon as it is available, rather than processing the entire TTY buffer, or even the entire UART buffer, for that matter.
However, you really don't want to have the PPP code in the serial interrupt handler, which is where it would have to live if one were watching each byte as it comes from the UART.
the growth in cynicism and rebellion has not been without cause
And this is different than who? Linus? RMS?
Any other coder would be very happy to have any form of recognition (this is not a 'bad thing'). Just because someone has attained it means nothing, other than a combination of luck and skill. What's wrong with that? In the end, he ends up with a little publicity, and Linux ends up with some useful code - for free.
I'm amazed you know Carmack so well. How are you so damned certain what he wants and doesn't want? It seems to me that this is a Good Thing for all involved.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
It looks like something that's coded into the games, and the ISPs route that traffic differently, which is why a dedicated dial-up service for PowerPlay 1.0 is set to be introduced in a couple of months.
Carmack isn't working specifically on the PowerPlay standard, but it'll obviously be in the games he codes in the future.
Pablo Nevares, "the freshmaker".
Pablo Nevares, "the freshmaker".
Besides, the whole idea of Linux pressuring MS to improve ought to bring a smile to the face of every consumer on earth -- this is that whole "competition" thing we've been missing throughout most of the 1990's.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
---
In the great scheme of things, that ranks right above winning a farting contest.
---
Oh, I see. You're in competition. That makes things more clear.
Anyhow, coding a 3d game like Quake isn't exactly trivial. If it is, please supply a link to your own code and we'll talk.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
Until you can prove that something is right, assume it's wrong. Until you can prove that there are NO flaws, assume at least one exists.
I hope they do find a way to use winmodems, then I can get a fully functional 56k modem for less than $30. All the of the winmodems I have seen get full speed with no problem.
Only the State obtains its revenue by coercion. - Murray Rothbard
I hate MS as much as everyone else, but one thing you say is, no offense, retarded. No one's gonna go out and buy a $90-$200 OS just so they can use a WinModem which they could replace with a real modem for $50. Pretty much anyone who would buy a Winmodem is also the kind of person who would buy an already-assembled, Windows-installed computer. If they later become interested in running a real OS, then they'll benefit from Linmodem support.
Switch the . and the @ to email me.
If you live in the middle of nowhere, where the telcos don't give two shits about the customers because the market is too small, you are going to have a modem for a long time. The cable company sounds sort of puzzled when you ask about cable modems, and DSL is out of the question because of how far the switches are spaced out around here.
---
UDP is a form of TCP/IP packet.
While the Internet Protocol suite has become commonly known as "TCP/IP" and thus this statement is marginally semantically accurate, to imply that UDP is a subset of TCP is just wrong.
Now, I know that John Carmack is 'Da Man (tm) when it comes to 3D game graphics... and he is obviously knowledgable about writing certain kinds of network games..
Does all of that skill necessarily imply that Carmack can necessarily write a stack for Linux, that is truly better for games? I mean, it'd have to be able to handle all sorts of hardware, all sorts of circumstances, SMP, etc. etc. And, we must remember that kernel development is pretty different from app development in many other ways, too..
The article, after all, phrases it as "take a stab at" the project. Maybe he'll just flick a few bills off his megawad of cash, and fund some development, should he not eke out enough milliseconds to bug MS. heh heh
If it weren't for games, Linux would not be in the place it is now. Hear me out first. What made x86 hardware even in the same ballpark as Suns and SGIs? Games. Games continued to push x86 hardware until one day, someone realized, "Hey I can run a server of this!" No x86 servers, no Linux. Hell, no x86 servers and the small guys would never make it onto the internet.
A deep unwavering belief is a sure sign you're missing something...
For the record, IP (Internet Protocol) is a lower-level protocol that routes generic packets on the internet or equivalent. TCP (Transport Connection Protocol), UDP (User/Unix Datagram Protocol), ICMP (Dunno, used for ping and traceroute and such), IGMP (fairly obscure), and several other higher-level protocols sit on top of IP.
While TCP is the most common type of packet using IP, it's certainly not the only one. UDP is also quite common at least in the real world, and almost everybody supports ICMP. Alternatives to IP are things like Unix domain sockets.
For most developers the decision revolves around TCP vs UDP (IP is a given in today's networks), and the primary difference is that TCP is connection-oriented (ie data is guaranteed to arrive in the order it was sent, and if the next packet in line isn't at the reader yet, it blocks or returns EAGAIN) while UDP is connectionless (ie data is sent in datagrams which can arrive in any order, and readers do not block as long as any datagram is available to read).
From this sumamry you can probably see why UDP is fundamentally better for things requiring near-realtime transport across flaky networks like the Internet - TCP is indeed quite slow for these purposes, since packets that get lost in the shuffle must be resent, and later packets have to wait for that one to get through before they can be read. Naturally there are things one can do with TCP to work around this limitation but UDP is still better. Of course, in real applications both types are used. A typical package will use TCP for control and UDP for data. If Carmack really wanted a better game development platform from Microsoft, he should pressure them to provide (better) support for UDP. Out of generosity they could even call it User Datagram Protocol instead of the more correct Unix Datagram Protocol, since anything Unix must be bad.
No one is forcing you to buy a winmodem. The only reason your computer came with one was the price. My friend has a 56k winmodem on his 486/50 (no fpu even) and it works great, 5.5k/sec downloads with no real cpu usage.
Only the State obtains its revenue by coercion. - Murray Rothbard
Make me aerodynamic in the evening air
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
And the rumour be carried around the world (thanks /.) and someone at Redmond will be tasked with the job.
Winmodems are made by companies like 3com and Diamond. Windows is made by Microsoft. How would MS have anything to do with whether or not a modem has drivers for linux? If you want to file a law suit for this it'd be against the modem companies, not Microsoft.
A minor correction, ICMP is an integral part of IP. If you draw a diagram of a networking stack, IP and ICMP are at the same level, UDP and TCP are one level higher.
Mea navis aericumbens anguillis abundat
I think you are spendnig too much time humoring the trolls...
if you ignore them, they'll go away.
mmm
Amazing magic tricks
Really - who? Carmack is one of the best programmers in the world, IMO. The proof is in the pudding. Look at Q3A. The network code is so tight in that game that I actually get He designed his own SMP implementation, for chrissake. Microsoft and their army of engineers hasn't been able to do this for Windows for 5 years. Carmack is a really, really smart guy and I have no doubt that any contributions he makes will be definite improvements on what was there before.
--
I think there is a world market for maybe five personal web logs.
Um, I can't believe I'm reading some of these replies! After all that John Carmack has contributed to the entire computer industry, we have the gall to lash back at him in this manner... He is one heck of a programmer, not to mention one heck of a nice guy! If he wants to "take a stab" at reworking the Linux IP stack, then the Linux community should welcome him with open arms, not this "are you sure he can do it"/"he's a greedy basta'd" crap. As it has been said before, he has much experience with network optimization (think QuakeWorld, people, not to mention that Q3A plays *wonderfully* on my seriously lagged 28.8!); why shouldn't he be able to hack out (and I mean that in the most respectful manner) something that will ultimately benefit all Internet users?
;-). PowerPlay is definitely a good step in the correct direction.
Btw, the issue of latency is *huge*. I constantly play on a 28.8 in contrast to my school Ethernet connection, and latency sure kicks my rear on that 28.8 (not to mention that I'm a sorry Quake player, too!
TCP/IP has been standard nomenclature since long before Windows had it. UDP is a thin veneer on IP, but TCP is a very significant component of the protocol suite.
There is one really really big and important difference between TCP and UDP: TCP does flow control and congestion control, but UDP does not, unless you layer it on in your application, which most people don't.
Without TCP congestion control, the Internet would collapse in a flaming heap tomorrow. This would also happen if everyone decided to switch to UDP for everything.
For whoever doesn't know what congestion control is --- it's a scheme that slows down your transmission rate when you detect that your data's being lost in the network, presumably because of congestion. The idea is to avoid overloading the network so everyone can get a useful share. It works very well, having been studied and tuned for decades. Anyone who tries to reimplement it in their own UDP-based protocol is very unlikely to get it right first time.
Nor does any human being believe they are, unless they're delusional.
Feh. What's the point in trying to have any kind of reasonable conclusion with someone who may or may not exist. For all I know, "Anonymous Coward" could be a scriptbot looking for posts to make nonsensical replies to.
This coming from an anonymous coward with poor writing skills?
You know, troll, you need to learn to read before you can write.
Ooh, 'fag'. That's cute. 5th grade level insults really show off your intelligence. Not only am I speaking to an idiot, but a homophobe
The above comments were all given a default rating of 2, showing that just having a lot of karma doesn't necessarily mean you deserve the +1 bonus. *sigh*. It's time to raise my reading threshold to 3.
Was it Groucho Marx who said "Any club that would have me as a member, I don't want to belong to"?
Yes, moderate this down too, and none ofthis ever happened right?
Life's a bitch but somebody's gotta do it.
Even if YOU think UT is better, keep in mind that Quake has been the series of games that all other games strive to beat. Without Carmack, UT wouldn't be have the game it is today. IMO both UT and Q3 rock, it doesn't matter which one is better ...
Just an FYI, all IP stacks MUST support ICMP. IIRC TCP requires ICMP for initiating connections, and it is used to signal a broken connection and all sorts of things. Also, ICMP = Internet Controll Message Protocol, and IGMP = Internet Group Message Protocol. And one final thing, windows supports UDP just fine.
-matt
Whatever. Mike Abrash went from Microsoft to idSoftware for a single game, and then went back to Microsoft. The last time I spoke with Mike Abrash (over email), he said he was working on Natural Language Processing, anyway.
--Joe--
Program Intellivision!
...he also came out a while back to lead a bunch of game developers in supporting OpenGL over Direct3D. They sent an open letter to M$ about their opinion (I'm not sure of the exact outcome, but I still play a bunch of games with OpGL). Quake was also one of the first accelerated games, so his significance basically comes down to, When Carmack talks, people listen, even Micro$oft (hence this whole story).
+&x
Carmack's name can no longer be enhanced. He has been my god since I got Doom II for my 486.
--Have a Johsonville brat.
The modem companies therefore, cannot release drivers for Linux. Winmodems are manufactured on the initiative of Microsoft [tm], and not on the initiative of the modem companies.
You're probably right.
:>
Then again, the same could be said for natural selection, but look how THAT turned out. In theory, these trolls shouldn't even exist.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
Okay, there are probably better coders. I wouldn't doubt it, actually.
What of it?
If he contributes something where it is needed, it's still a good thing. If one of these phantom 'better coders' comes in and improves on his code, even better.
Doesn't mean you should rail against the guy. You're not being forced to play his games, and if his changes are less than desirable, I assume Linus wouldn't include them. It's a win-win situation. Why the anomosity then?
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
Does rewriting the TCP/IP stack have much chance of reducing latency? Ping times on ethernet are under 0.1 ms, so if the stack is delaying packets, it's not very much compared to the 150ms round trip time on most modems.
As I understand, Linux supports the ToS bits. Using the "minimize delay" bit together with an ioctl to REDUCE the size of the modem driver's outgoing buffer would probably have more impact than just about anything else one could hope to do, at the kernel level. Is there really some other aspect of the kernel that causes latency that I am not aware of??
At the modem level (winmodem driver), I could imagine again reducing the buffering, so that multiple packets without the ToS minimize delay bit don't get buffered in front of time critical packets. Turning off V42, V42bis, etc would help latency considerably, but when the errors occur, you're stuck with retransmitting, and you're stuck behind buffers before your retransmitted packet can get sent, so latency with errors is even worse without error modem-level mgt. Maybe a new modem-level protocol using Reed-Solomon (or similar) error correcting codes, with feedback (as low urgency packets) to adjust the number of error correcting bits added, so that there would be a very low likelyhood of ever retransmitting a packet...
It's hard to imagine they'll go after the actual modulation itself or clock recovery. There is latency involved in a Vertibi decoder, but my (limited) understanding is that it's usually only a handful of bits.
So if you've read all my babble, what do you think could really be done in the kernel and/or modem itself to lower the latency. What do you think the powerplay folks will really manage to do before March?
...AC, I know, should really get a slash account someday
paul@pjrc.com
ICMP (Dunno, used for ping and traceroute and such)
Internet
Control
Message
Protocol
UDP is a form of TCP/IP packet.
UDP and TCP are different protocols sitting on top of IP.
TCP is session based. You have overhead in setting up and tearing down sessions, but it does error correction and packet ordering/acknowledge automatically.
UDP is shoot-and-pray. No checking for lost packets and if you transfer more than one datagram of data the receiving program has to reorder the packets. Much less overhead than TCP, though.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
Personally I think the person who came up with the idea of softmodems should be stripped of his degrees and forced to go through a college CS course. I don't know about these days but one of the first things we learned in Hardware 101 is that you buy cheap UARTS so that your expensive processor doesn't have to dick around with serial. Of course, modems are passe' and no one will be using them in a couple of years anyway, but it's the principle of the thing...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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
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...
What you are describing are deficiencies in the standard PC UART (based on National Semiconductor P/N 16550A). It has been known for over a decade that the 16550A is unsuitable for anything like modern, multitasking systems. Unfortunately, like so much of the PC, we are tied to a legacy standard choosen twenty years ago for completely obsolete reasons.
If you want to improve modem efficiency, use a better serial interface and larger buffers. USB would be a good start, as there is already a standard. Make the interface tunable, so you can use larger buffers with fewer interrupts and higher latency (good for web browsing, downloading, etc.) or smaller buffers and more interrupts to reduce latency for gaming.
However, none of this has anything to do with the modem itself. Moving the modem DSP functions off the modem card and onto the system bus and CPU increase overhead and latency, without a significant savings in hardware costs. As near as I can tell, they are popular only because the current commodity market makes saving three bucks a unit significant when you are building a million of them.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
While the 2.2.x IP stack certainly requires a rewrite, the Linux kernel networking gurus have already thought of that, and since 2.3.15 (so in 2.4 final) the networking is fully multithreaded.
The really big problem is that much of the power/scalability gained by the multithreading (which in essence consists of eliminating global kernel locks) is not used because of the Linux core design (the bottom-half interrupt handlers are globally serialized).
Of course, there's a solution to this too: rewrite the interrupt handling core. This is already being done under the misterious "softnet" name (go here for details). This won't go probably into 2.4 because it involves too many fundamental changes.
Petru
You're probably right that any improvement in latency would have a negative effect on bandwidth.
But that doesn't mean it would automatically be rejected. Suppose it was option that could be compiled into the kernel but was disabled as a default. i.e. "Optimise TCP/IP stack for games?" as a question in the "make config".
A games focused distro could have this kernel provided with it as well as a pre-configured XFree 86 Utah-glx-Mesa setup for out of the box 3d support.
And I'm sure JC's quake code is ugly as all hell, but he's been contributing to the utah-glx project for a while now so I'm sure he is capable of writing "open-source" style well documentated code.
Uh, dude, I don't run Linux (full time, at least) and don't even play Quake. Of course, I've only said that 2 times already, so I wouldn't expect you to understand.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
You are correct of course. However, in the US a good portion of the upper middle class lives in low density suburban and exurban areas. In addition, people like to work from summer cottages and ski resort areas.
So, there's a big lucrative market to get broadband to areas where it isn't feasible to provide DSL or cable. I would expect to see wireless solutions that provide at least 100-200Kbps rolled out within the next few years. The cellular/PCS infrastructure is already there, and provides good coverage in all but the most remote areas. Considering how the cost of mobile phone service is dropping through the floor, I would imagine that the companies are very interested in any revenue-enhancing services.
So, I would tend to agree with Ion++, widespread broadband is going to be available by 2005 or so. (Which is not say that modems are going away -- I know a few people still happy 28.8K modems for simple things like mail access, even though 56K access is pretty much universal.)
--
Business. Numbers. Money. People. Computer World.
I recommend that you pick up a copy of W. Richard Stevens' "TCP/IP Illustrated volume 1" and read it. please.
Phew, I knew there was something wrong.
You seem to become the Alan Greespan of the home computer market and one wrong word at the false place can cause big hoopla.
Thanks very much for clarifying this and for your patience with the gamers/open source/slashdot/trolls communities.
Oh my, I expected a big flamefest on linux-kernel and linux-net, hope they get the message....
Microsoft has nothing to do with Winmodem "specifications". Perhaps you can argue that a communication API like TAPI makes winmodems possible, but I highly doubt that was Microsoft's original intent.
Face it -- the average PC buyer wants spend $800 and get a complete package including monitor, printer, modem, *and* a respectable Megahertz number. Because they can't include last year's CPU, the OEMs pretty much have to cut corners everywhere else. So they save $5 and package a winmodem -- no big conspiricy.
Since many Winmodems don't even work in Windows NT (or 2000?), I'm sure Microsoft isn't that happy about the situation either. It deprives them of some upgrade revenue. On the other hand, if you have the secret Bill Gates memo ordering Dell to ship winmodems to stop the evil 1% market share of Linux and OS/2 users, you'd better put up or shut up.
--
Business. Numbers. Money. People. Computer World.
quake3arena only supports SMP on operating systems that are SMP-capable, which is quite a bit different from your statment that carmack implemented SMP all by his lonesome.
John Carmack has been working on the GLX project for a few months.. And when Quake 3 shipped he said he wanted to take some time off to work on some free software projects, so there may be some truth to this. This seems like a John Carmackey thing to do.
If linmodmes.org or Carmack produce a good winmodem driver, we'd then have to call them Software Modmes, wouldn't we?
If the "win" implies Windows, but the modem can run on other operating systems, that'd warrant a change in name, "softmodems" or something similar.
And if either party produced a driver that could run the software modem just as well as a legacy modem, I'd prefer to buy the software modem, because they're about half the price.
-kidlinux.
I do believe that it is quite within the world of Microsoft to have dedicated modems, DSL or otherwise, that require Windows software to operate, with integration similar to the WinModem. Such a thought distresses me, on several levels, and my wish is for choice.
this new winsock dll greatly reduces latency with networktraffic over tcp/ip on win9x systems. Afaik it was released last week or the week before that. Saw it on voodooextreme, someone should search it back there if he/she feels up to it :)
Never underestimate the relief of true separation of Religion and State.
> software can never outperform pure hardware implementation.
Bullshit. Why all the craze over DSPs? Besides, it is easier to upgrade software.
Ryan
I agree, however the rollout of these technologies is depressingly slow. Some companies like Lucent have been hit in their stock prices partly due to slower than expected movement by the phone companies to get this stuff out.
I know it all too well. I live in the middle of the most densely populated state in the country (NJ) and can't get either a cable modem or consumer DSL services. I could get business DSL if I was willing to pay $100+ month.
..on what you mean by outperform. For my analysis code flexibility of the software solution vastly outperforms lower latency of a possible hardware implementation.
In the case of modems (of which I have no knowledge) adaptible code maybe (possibly) be better than rigid hardware solution.. Though I would guess that it is done anyway - just by a chip on the modem board - not by central CPU - that's where Winmodems suck, not because pure hardware/software difference..
<^>_<(ô ô)>_<^>
By definition, an external Winmodem is impossible. A Winmodem does not have a UART and the function of the missing UART is performed by your main CPU.
External serial ports are driven by UARTs, so it is impossible to have an external modem that doesn't use a UART.
If the IP stack caused significant lag then ethernet games would blow too. Modems suck. Cable/DSL sucks less. Ethernet is quite nifty. The softmodem driver would probably help lag much more than tweaking the stack. Most of the serious gamers probably have cable/dsl by now though.
Ryan
Quite a few research and production-quality versions of Linux have addressed the issue of hard real time and more importantly QoS-oriented soft real time CPU scheduling. This is normally intended for multimedia but should also help a lot with games by guaranteeing a certain amount of CPU every N milliseconds. See Linux-SRT at http://www.cl.cam.ac.uk/~dmi1000/linux-srt/index.h tml - this has links at the bottom to QLinux, which has similar features but also covers disk and network scheduling (i.e. packet queuing). Also linked are RTLinux, which in 3.0 I think may have something similar, and KURT, another RT Linux.
One very encouraging thing about the two university projects is that they are doing cutting edge research on Linux rather than inventing a unique operating system - while the latter is sometimes necessary, Linux is often as good a testbed as any, and it makes it much easier to turn the research into open source that is of product quality.
I think what he meant is that Quake 3 plays really well on his 28.8 compared to other games, and of course Ethernet beats that hands down. We can all admit that Quake 3 has good netcode, but even the best netcode will be helped by a lower ping. Muerte
I think its a computer
LetterRip
Remember this is Linux with loadable modules. We can have more than one stack.
A full stack with all the stuff needed for all the different parts of TCP/IP and the kinds of buffering that is needed for all this different ways it will be used.
AND a striped down games stack that only talks to other stacks like itself. It would not need to respond to anything but gaming packets. You could also move part if not most of the stack to the ISP side of the wire. this could remove a lot of overhead. I mean what could be done in terms of NETBIOS type stack for local LAN (not routed) gaming. Who needs IP addresses if you are all on the same segment? heck.
The same kinds of things could be down with win modems (if we can figure out how to control them) no buffering low latency exect...
The point is that we can have choices we can do thing differently we don't have to be locked into a single stac
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.
You do make a good point and are correct when you say External serial ports are driven by UARTs. However, a friend of mine has a USB modem. Yes, it's a 100% Software-required winmodem.
--
steve
C-x i ~/.sig
I know it all too well. I live in the middle of the most densely populated state in the country (NJ) and can't get either a cable modem or consumer DSL services. I could get business DSL if I was willing to pay $100+ month.
That surprised me. I also live in NJ, and know many people throughout the state. About 1 in 20 people cannot get either a cable modem or DSL. I can actually get both, but I chose cable because of the price. (Although I am feeling the *neighborhood* start to slow the connection)
Hope you get something soon.
--
steve
C-x i ~/.sig
better TCPIP stack?
NT's TCP/IP stack seems to outperform linux farely substantially, because it's threaded, and generally BSD based.
NT keeping up with Linux's TCP/IP performace? Maybe on a 486, but not on a scaled SMP or even normal high end machines.
Linux lacks many of NT's optimization features (like IO completion ports), or evn sufficient use of any threading.
Also, lets not forget Windows 2000 currently holds the networking speed record.
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.
uh, TCP == Transfer Control Protocol.
A GPL'ed Carmack-written Winmodem driver would be a very good thing for free software and free hardware.
Currently, Winmodems are evil little beasts with shoddy drivers and no public specifications. John Carmack is one of the few people who could convince a modem manufacturer to disclose Winmodem specifications. A high performance open source driver, released under GPL or other sufficiently viral license would give a jolt to Open Hardware.
I agree with you that a closed-source vendor-supplied Linux winmodem driver, and apparently Lucent has done this, is bad for everyone.
And I thought that it was just to waste time and make the girl next to me in the lab (who was an awesome player) swear constantly!
:-( (OK, it got rewritten, but it was simply never the same.)
I remember that game. Whoo boy do I remember it! Too bad it didn't survive the PowerPC transition.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
There is a product from 3com called the "Gaming modem", (http://www.3com.com/client/pcd/products/prod-game mod5613-int.html) that is supposed to lower the ping. The homepage doesn't say anything interesting about the product (Why are almost all corporate homepages so uninformative?), but I remember reading a review claiming it was actually mostly a driverside improvement. Could this be done for all modems? Would it matter, or is this whole "Internet"-thing just a part of the Y2K-hype?
---
Try out fish, the friendly interactive shell.
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
Actually, no.
Some time back there was an interview on slashdot where the person getting interviewed got the "first post". and it got moderated up to 5!
(and moderated down, and up, and down...)
Gracias, Muerte2, you have clarified what I so brilliantly fux0r3d up. ;-)
Why will it be my downfall? I don't buy any of this crap, and the people that do generally don't ask me for my opinion.
--
Business. Numbers. Money. People. Computer World.
Ken said in a refent interview with IEE that Tom Christenson has posted here stated he fears about linux being used inn a firewall/router. He says some parts of linux are good but others are awefull and then he mentioned stability in doing things like firewalling on pc hardware. My guess is that Thompson hates the stack.
I think its speghetti code that pc magazine has shown that its not scalable. I assume its stable and that Thompson was wrong on this. Either way it needs to go. I looked at the code and was amazed at how clutered it was.
One thing that Carmack knows how to do is to come up with ideas on how to squeeze the last ounce of performance out of slow hardware. Quake is really its own operating system. It has its own i/o code, video buffering schemes and services and even its own custom networking code. I believe Carmack will blow the world away and I even regard him as good if not a better coder then linus. (Insert flame here)
Anyway I would a tcp/ip rewrite. The original stack was not designed to be high performance. I believe there is alot of old code left in the tcp/ip stack that needs to go increase stability and performance.
OK - this is less sarcastic: My post was an attempt to explain the situation, not justify it.
WinModems are a product of Microsoft's monopoly, not a cause. Or, consider them a "network effect", where the lack of OS competition allows vendors to cut corners and design/package only for one or more of Microsoft's OSes.
Back to the original post I was replying to -- there is no secret Microsoft winmodem specification. In fact, each different kind of "winmodem" is actually incompatible with each other. Most of these have had no specs released at all, or the Linux community would have written drivers. What Windows does have is the TAPI layer (sometimes called Unimodem), which presents a uniform interface to applications for different kinds of communication interfaces (regular modems, parallel port modems, ISDN TAs, winmodems, etc.). This solves the Windows 3.1 problem where each comm application supplied it's own driver, which was a support nightmare.
Many of the winmodems do not have Windows NT/2000 drivers yet, which is going to slow Win2000 adoption as much as it slows Linux adoption. Hope that pops the conspiricy bubble around here.
(Note, "WinModem" is actually a 3Com brand name - I'm talking about them in the generic sense.)
--
Business. Numbers. Money. People. Computer World.
Us folks with Cablevision are screwed as far as cablemodems go, and DSL hasn't made it to my area yet. It pisses me off to no end that Cablevision is trying to buy up sports teams here for $$$$$$$, and runs crappy MSG channels on their cable, but is still working it's way through NY and CT with their broadband internet services. Meanwhile Comcast has had cable internet access for a year or two in towns not 10 miles away.
DSL will probably be here in about 6-12 months, but I bet it will be crappy. Bell Atlantis does not have a good record so far. And they keep sending me notes in the mail - switch to us as your ISP. Yeah, right - at $20/mo for LIMITED service with reliability and service guaranteed to be lower than my nice local provider.
If this is how they think, this is a very bad sign.
Mainly, Adrian Carmack isn't John's brother. Just a coincidence that they have the same last name.
I think Brian Hook does deserve a bit more credit than you give him for the netcode and (I believe) some of the GL miniport. But it still can't be denied that JC has done a LOT for the gaming industry, and has recently been contributing quite a bit to Linux. (He's an active contributor to the driver project for Matrox boards, and probably contributes to a number of other GL drivers.)
The gaming industry (Well, at least FPS games) wouldn't be where it is without John Carmack. No one has been able to touch ID software in terms of their programming skills. (I will admit that Epic had some great ideas with UT - but their engine gets torched by Q3's. The mod coders won't take long to fix Q3's deficiencies. No mod coder can fix UT's network code.)
retrorocket.o not found, launch anyway?
Oh, that explains it. We have an Epic Games sock-puppet in Slashdot.
UT is a load of derivative, me-too bollocks. Maybe some day Epic will do something original, but that will have to be after Carmack retires.
"Be nice, veer left, and never stop thinking" Iain Banks - Walking On Glass
I agree...
USR Winmodems sell for around $100, real ones for $120.
Real modems from other mfrs (Zoom, especially) sell real modems for less. ($80-90 or less, and that was 2-3 years ago for a 56K)
retrorocket.o not found, launch anyway?
Just a note: I believe Lucent's hit in stock prices was due to a few things, but the primary thing was that the Optical Networking got nailed.
And it wasn't due to lack of demand. (Well, sort of) For one, they couldn't keep up with demand, and couldn't deliver. Second, they're apparently releasing a lot of new technologies this quarter that a lot of buyers have been holding off on their purchases to wait for.
It depends on your cable company. Some companies are stupid (TKR cable, which got bought by Cablevision I believe, equally stupid), and others are smart (Comcast in NJ and Time Warner in NY)
BA doesn't have DSL yet in my parents area, and I'm wary of them anyway.
Up at college, we have both RoadRunner from Time Warner and Light.Speed DSL from Telergy. (Ithaca, NY is Telergy's first market for DSL.)
retrorocket.o not found, launch anyway?
Carmak wrote Keen.
Infact, the game was the first implementation of a new EGA 2-d engine
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
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.
The Winmodems are not modems web page has posted a letter on how to work these babies.
By the way, get rid of the "exec" part if this is used in the rc.serial file and start with "setserial" and the rest of the settings.
--
So you are saying, that we are getting often files slower than we could on the same connection for some rason that is in stack? Then we gotto remove that stupid limit NOW. I want my modem work at it's fullest.
Then the Internet collapses as all the major backbones get saturated, and the world as we know it ends. Tragedy of the Commons, my friend.
DNA just wants to be free...
My personal hope is that the 56k modem is the last of the dial-up era. However, I also live in hope that DSL (et al.) never falls into the Microsoft dictated "software required" trap.
Well, you havn't got much to worry about, 56k is the maximum posible with the current phone system. The only way to get more would be to replace the phone system, witch is what DSL is...
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
Btw Congrats, John!
/joeyo
2^5
Stuart Cheshire, IP guru and author of Bolo, investigated these issues very thoroughly 4 years ago, and wrote it up as It's the Latency, Stupid , which you shoudl read. He also wrote a second paper Latency and the Quest for Interactivity , which is also well worth reading, but I'll quote the conclusion for those too lazy to click a link (remember this was written in 1996):
To improve the quality of computer network interaction, we need to do two things:
1. We need to aggressively eliminate all causes of unnecessary latency in our computer hardware and software.
2. For interactions with the other side of the planet, we can never beat the speed of light, so we need to develop latency-hiding techniques that give us the illusion of interactivity when true interactivity is not possible.
As long as customers think that what they want is more throughput, and they don't care about latency, modem makers will continue to make design decisions that trade off worse latency for better throughput.
Modems are not the only problem here. In the near future we can expect to see a big growth in areas such as ISDN, Cable TV modems, ADSL modems and even Wireless 'modems', all offering increases in bandwidth. If we don't also concentrate on improved latency, we're not going to get it.
One first step in this process would be for the industry to adopt a modem latency rating scheme. TEN, MPath, Catapult, Sandcastle and the other network gaming companies could collaborate to set this up. Modems that can achieve a round-trip delay below say, 100ms, could be authorized to place a sticker on the box saying "Gameplay approved" and the gaming companies could encourage their customers to buy only modems that are "Gameplay approved".
If we don't start caring about latency, we're going to find ourselves in a marketplace offering nothing but appallingly useless hardware.
I think that was abit too much praise... remember the reason for making quake world? Hes a good programmer, but dont give him too much credit.
Thanks to the ever-handy Google I quickly tracked down his home page with all sorts of things like his Latency rant. Lots of other reading material...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
An anonymous coward pointed me at Stuart Chesire's home page which has a lot of interesting rants, including a technical white-paper on latency that almost exactly matches what John Carmack just wrote.
(Lots of other good rants as well...)
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
-----------
"You can't shake the Devil's hand and say you're only kidding."
Guess I forgot about USB - you certainly can have an external Winmodem on the USB bus. And with USB I guess you could have it either way - winmodem or normal.
man what the heck is your problem? He just said that the stack was being rewritten for the next release. Unless you've written a network stack from scratch, please go to Hell. Thank you
---
I have seen several USB modems, and I would assume that they are winmodems...I think Creative has a USB Modem Blaster out, but I'm not sure.
That would be fun to work with in linux...a USB winmodem. Ye gods...
By the way, there is a Bolo for indows out now. Everyone needs to persuade John to port it to Linux/Unix. Get it at http://members.xoom.com/jamorrison/winbolo.html
The tracker is located at http://bolo.zoid.com:50001/
Have you checked out Zoid.com yet? Zoid.com
Cablemodems are set up by the cable company so that they only function on the node they were assigned to. Thus they can only be used inside the house of the person who ordered the cablemodem.
I don't know about dsl, but I wouldn't be supprised if a user can't log in to his ISP using DSL from areas other than where they ordered the service (can someone tell me about this?)
Why does this matter? Because not every computer user always uses his computer from home. Many have laptops, palmtops, or even occasionaly move their desktops. (I have an uncle who travels with his desktop computer).
Untill broadband access is mobile there will always be a place for the modem. A traveler can almost always find a phone outlet to plug the modem into. He can often find a local access number if he's chosen the right ISP.
Little Brother, watching the watchers
You can run x inside of a ggi window, and there's a program that allows you to run 6 ggi screens, each on the side of a cube, that on top of ggi in a console or svgalib in a console or something. (I think I'm getting this right) You can rotate the cube, and its really cool looking. I've never played with it personally, but a friend of mine did on his 233 (i think) mhz laptop, so its not too processor intensive. Its not nearly what you envision but its a pretty interesting environment.
Define sufficient; some parts of Linux are more threaded than others. Why rework something if it isn't a bottleneck?
The thing is it is. Almost everything is a bottleneck - especially on TCP/IP if it's not threaded - this is especially important too as linux becomes more GUIish.
For what? And if so, where are all the sites out there using it
Well, Microsoft.com and a few other sites out there are using IIS5 (microsoft.com is the world's largest commercial site).
And the speed record was set with the university of washington.
blah
Im sorry, I try not to do this .. but
lmfao...
Hehe.. good timing..
SB.
Um, I hate to burst your bubble, but wasnt Quakeworld released because the network code was poorly written? Is this the man that should take on a server OS networking code? He didnt have the foresight to realise that people were going to play quake on modems, and that not everyone had ethernet internet connections.
;)
Seems he likes pointing fingers and saying "do it MY way, I'm God" - Remember he insisted that Quake 3 would ONLY be ported to Mac IF they used OpenGL as their main API, *AND* they must release Rhapsody and implement that as their OS! Like thats up to a game developers whim. (so basically, Mac ported to Quake 3, not the other way around)
Oh, and he shunned 3dfx with the decision to not support glide in linux or windows, and to implement OpenGL in a way as to break Voodoo drivers that have been "fixed" to be "Quake 3 compatible" -- and in linux, it seems you cant run both {Quake1&2} and Quake 3 with the same X server, because of glide and OpenGl.
And then on to 3DNOW! support for Quake 2, he totally blew this one off and the only way you can get 3DNOW! support is through an unofficial, unsupported patch downloaded from AMD.
I dont want to sound like a troll, but this man codes his product, and pretty much ignores the environment his code will habitate, and blames that environments problems on the other developers who's code or hardware will share that environment, and puts it on *their* shoulders to ensure that their stuff is compliant to his code! Even if its something like the OPERATING SYSTEM!
This is NOT the man that should touch the stack, or he might tell us that (loose analogy here) You need to use a different OS, You cant use that protocol with my stack, I'm dropping support, and I dont CARE if its an industry standard, AMD supported, nope, call AMD and stop bugging me. Modems, hell this stack only works on LAN! who has modems? not me, John Carmack! Will it be portable to the Mac PPC linux? hmmm... I'll only do it if they make a "Quake 3 RED" iMac.
Now Tim Sweeney, thats ANOTHER story
--AROS is an Open Source AmigaOS clone, and source compatible with AmigaOS! Try the x86 build at http://www.aros.org
Nope. The "modem vendors releasing specs" is not what keeps there from being 'winmodem drivers' for Linux.
It would involve deep layer kernel hacking to put native DSP coding into Linux that would enable the kernel to emulate a modem. Because that's how Winmodems work. A modem emulator is not something you can just cram into a timesharing system without a hell of a lot more rewriting than is realistic.
Try again.
For some reason you people all seem to think that codeing a 3-D first person shooter game is the ultimate action in 3-D graphics programming.
Here's a clue for you: The under $60 shrink-wrapped software market is NOT the end all and be all of 3-D graphics programming. If it were, then the animation at movie theatres would, well.. all look like Quake.
Your worst dreams will come true in deathmatch hell with the coder who made the rules.
Ah, you're talking about the hacked 'open source' Quake binaries that are destroying what remains of Quake I net play. Yes, coders do "make all the rules" up there as they go along, don't they?
hrm... I dunno... I'd rather get cutting edge news and rumors then get a solid pile of day old stuff regularly. Who are you to say I can't? You have you're preference, I have mine. I like mine. Keep up the good work /., don't listen to this punk-monkey. And speaking of you, suggesting that /. goes out and creates false news intentionally seems pretty unconfirmed. I suppose you have no obligation to hold yourself to the standards that you're demanding tho... still. I dunno, you just sound like a turkey to me. A big turkey. With really big socks. Statements like "The people of Slashdot love to bad unconfirmed rumors around till they sound like the truth"... How arrogant can you get? Serriously, how do you know what they intended? You're prolly right tho... they must be out to get us. I mean, you say it with such confidence!!! You don't even have one of those "This is unconfirmed" disclaimers on your post, so it MUST be true, right? You prolly have hundreds of hours of phone recordings of them detailing their plans to snooker all of the /. reading community. You keep them stuffed in your matress, right? That is the kind of story validation that you're asking for, isn't it? I can hear them now, laughing, yes, LAUGHING at all the fools who believe their misbegotten LIES. It's a conspiracy man!! They're out to get me! The black hellicopters, EVERYWHERE!!! THEY'RE EVERYWHERE!!!! ARARARARGH!!!! If anyone asks, you last saw me heading south. You're the only one I can trust. This may be last you hear from me. Good night and good luck.
how much of the latency is actually caused by
current stack implementations, and how much we can
possibly hope to chop off?
Well, I can tell you that when I ping another machine on my LAN with thrice the rate a Quake connection would generate, it gets RTTs between 1.5 and 2 ms. So IMO latency in the IP stack is completely ignorable. What sucks is the next hop over the modem -> 70ms more, and that's not "the IP stack".
--
"The use of COBOL cripples the mind.
Its teaching, therefore, should be
YOu can get external usb winmodems - a friend bought one recently by mistake!!
any body tried that on a smp machine...last time I tried a 2.3 kernel (2.3.28), it would not compile for me...
has this been fixed yet?
I usually don't directly code IO completion ports cause I don't usually write high end 'enterprise' software, however I do benefit from them indirectly cause my ASP runs IIS, and many other NT software uses IO completion :)
Well, you are comparing a soon-to-be-available product from MS to the almost year old Linux kernel. I suggest that you examine the ( quite stable) development 2.3 series if you want a look at what will soon be the new stable series.
Mucho improved TCP/IP stack is one of the many revamped features. Thanks go to Mindcraft for exposing some linux flaws so Linus, Alan and many other talented coders could streamline the stack. I do enjoy the irony that MS funded the Mindcraft benchmarking that pointed to specific problems in the Linux networking code, and that has lead to greatly improved networking effeciency at the kernel level ( and a nifty kernel based web server for static pages)!
I also like your mention that the (completely unbiased?) Univ. of Washington has crowned MS as the network speed kings. I can only believe that their conclusion was drawn for a very limited sampling of the networking environments available to the business world. Maybe they limited themselves to benchmarking equipment they could purchase at Wal-mart.
I will believe that MS has improved their networking to the levels demanded by business environments when they are able to replace all of the Unix boxes that power hotmail.com with the same number of similar power servers running their W2K Server based OS. The tactic I imagine they would try would be to use something like the upcoming 8-way coppermine based Xeon processors to replace the same number of 2-way Unix boxes.
Cheers Dude!
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Its good to hear that there might be some improvments to the stack. At the moment the current TCP/IP developer has been concentrating towards features and general network use and not speed. Sooner or later its going to be unavoidable, the games are going to be developed for linux. I am a fan of the Linux ports of Quake and QuakeII and its good to see that Linux is being seen as a OS popular enough to port games to. If this is going to continue then further optimizations to any networking protocol will come as a bonus to the users.
Keep in mind that writing a full-blown IP stack that works well in many, many, *many* situations, on many pieces of hardware, for many wildly different programs, is very different from writing one set of I/O routines (or video routines, or whatever) for one single program that you have complete control over.
...).
I for one have never had any complaints about Linux's network performance, except that I've looked at the code before and it sure is ugly (alot of Linux code is horribly ugly though
"for Ziff-Davis and USA Today....Who really cares all that much about "winning" over "average" users anymore? This is the mistake that sank the Atari ST and Amiga and quite frankly is one that should be avoided at all costs. " I disagree. What killed the Atari/Amiga was lack of support for standard and cheap hardware, which made the machines power/price ratio poor, and so ruling themselves out of the market for gamers (there was no support for PCI/ISA/IDE devices, so "atari specific" devices were required). This was a bad example, dont you think, considering you are suggesting that cheap and common hardware not be actively supported?
This is wrong. You get them as fast as your connection can handle it. At least after the current max speed is found, a new TCP connection starts slow and then speeds up (sending one Megabyte in a second to a client that can handle only one Kilobyte per second will mean 1023kB of bandwidth wasted only to find out that it is in fact wasted). This is one of the reasons HTTP/1.1 adds persistant connections as opposed to one connection per file as in HTTP/1.0.
"Making routers actually pay attention to QoS bits, and defining specific queuing behavior for them"
It's fantasic that strides are being taken by the gaming development community to pound on the networking vendors to give gamers (specifically modem users) a "better" Internet. A lot of work has been done in this area in the past couple of years in light of VoIP, but I always envisioned the Diff-Serv/Int-Serv as a perfect app for online gaming =)
However, its not the vendors that are the problem, in this case. Most every router manufacturer has a current "QoS game" that is some adoption of the Diff-Serv approach. The problem lies with the network providers themselves. Rather, its the inter-peer handoff of packets from one provider to another that is the actual core of the problem at hand, as diff-serv "mappings" from one domain to another (ie. passing packets from SprintLink to UUNET) can vary greatly, not to mention the cost negotiations and political games at hand. It can be either really simple or really complex, and if it was simple, we'd probably already see something working =)
To compound this problem, the largely assymetrical nature of the Internet would require these mappings to be identical on both the forward AND reverse path. Its easy to map a packet from inside a network all the way to a peering point. Its a bit more difficult to appropriately map the return path FROM the peer point back to the internal recipient.
I'm not saying that its impossible. The packet marking approach would work great for a completely on-net connection (i.e., where a packet stays entirely within a single backbone provider). Its just right now the inter-domain marking support simply doesn't exist in production form on today's networks.
I think the current focus in high performance networking still relies on the characteristics of the peer-peer or client-server protocol that is used to exchange data. Much can be done at the application layer to realize current bandwidth availability and network characteristics (i.e. loss, delay variation, etc.).
Using a simplistic approach of having the user specify their local link rate is right on the mark in a LAN environment. It makes the protocol simple with few corner cases.
However, with on-line play, relying on the local link rate/capacity of the player's Internet connection does not take into account the many link variations that lie between the player and the server they connect to. It is this transitory network where the majority of bottlenecks occur. It is also where a smarter protocol that utilizes congestion avoidance, adaptive rate control and proper error recovery (at a network level, not a user-level data recovery standpoint) can GREATLY enhance overall user "goodput" (goodput = the users' perceived network throughput). Of course, this creates a more more complex protocol for more cases to consider, but this is actually what we want.
Take for instance TCP. By utilizing the SACK option on TCP connections, a user can achieve 20-50% increased goodput over a convential TCP connection on the same "noisy" Internet link. Of course gaming doesnt use TCP, but it *is* an example of a case where people said "stick a fork in it, its done" about a network protocol (TCP).
Again, I think it is extremely beneficial in examining everying to improve the quality of on-line play (especially for high latency, low bandwidth users). But I still believe that the most gains can be made in putting together a network savvy protocol that is aware and proactive on the connection with its peer. It's not necessarily the delay, but the delay variation thats the most aggrevating for online gameplay.
-Jason Keimig
Information and Telecommunication Technology Center
University of Kansas
Shhhh .....us gamers ....we really just shoot idiots on message boards.
[McP]SpAwN
"stupid games incite idiots to go around shooting people". -/.idiot
Ultima Underworld's 3d engine was say ahead of it's(and id's) time. The only thing holding it back was piss poor Cpu speeds, and no hardware 3d.
...
Over PPP, over a high quality link, TCP will be faster and have less latency than UDP, due to the wonders of header compression. The address and header information in a TCP packet that's part of an already established connection gets compressed down to a measly 6 bytes (this can be done because the PPP peers share state.)
Compression schemes could be used to provide similar header compression for UDP as it is used for games and such, and of course one could talk different but better suited to gaming protocols over IP (e.g. connection-based unreliable, unordered datagrams; connection-based reliable ordered datagrams.) The problem is of course that it's not so easy to go and rewrite the IP stacks of all these machines, or fiddle with their PPP code. This is where something like PowerPlay - with the backing of large companies - will be useful.
Hmm, there might actually be some way to do strange things with MS Winsock ver.2 to extend it to support other protocols dynamically - need to check the docs.
um, the point of standard protocols like PPP is to allow everyone to get onto this large network we call the Internet without having to write your own drivers and/or protocol stack. And if you are suggesting that game developers simply run their own servers, try playing any online game (except many older MUDs) without lag. The reason? Lots of people use the Internet, which congests routers and bogs down servers (I don't mention bandwidth because it would be hypocritical of me, since I am hogging some now with this post :)). The point is, if id software ran ALL the Q3A servers, we'd have to pay like 2 bajillion bucks for a copy of the game to subsidize the costs of the servers, etc AND we'd have to write custom drivers for our modems if they weren't 'popular' enough to warrant JC attending to it himself. And after all of that, the gaming experience would probably still suck due to lag, busy servers, et al.
Don't believe anything I say. I crash test crack pipes for a living.
2.4 gigabits per second wow thats fast hardware. So setting this record proves that windows 2000 has drivers for the hardware capable of this speed. What about the commercial unix's? What about NT4? What about linux and *bsd? Hmm so this isnt a Win-2-gay trophy per se, its just a marketing convenience that Win-2-gay was used.
Mindcraft: We Shall Never Forget
Lars -
I think this is a bit unfair. Johnc programs a game *engine*. Other people take the engine and produce those kind of games they think they can sell best.
The problem here is that the kind of games that require the most interesting engine are those that need collision detection and architecture seem from near. There is not much use of beauty in - say - a flight simulator's ground graphics. When you don't need the beauty, many of the most interesting programming tasks wouldn't be needed.
Hence the best engine hackers work on indoor/ground games where things fly and hit something. Commercially successful exploration of this technology usually requires that these objects represent projectiles.
Hi..
.1ms ping times on a 100Mbps network is not that far-fetched. (the initial lag for ping is probably due to the time required for ARPing.)
I'm not the original poster, but here is a test on my local lan:
PING omni (192.168.20.17): 56 data bytes
64 bytes from 192.168.20.17: icmp_seq=0 ttl=255 time=2.4 ms
64 bytes from 192.168.20.17: icmp_seq=1 ttl=255 time=0.9 ms
64 bytes from 192.168.20.17: icmp_seq=2 ttl=255 time=0.9 ms
64 bytes from 192.168.20.17: icmp_seq=3 ttl=255 time=0.9 ms
64 bytes from 192.168.20.17: icmp_seq=4 ttl=255 time=0.8 ms
This is a 10-BT network.
My local machine has an old WD NIC (not quite sure which one - it's ISA though, and utilizs the 8390 chipset) and the other machine has an SMC Ultra 16 (ISA and 8390 again.)
I tried it from another machine, this one with a PCI Intel EtherXpress 10/100 (operating at 10Mbps)
PING 192.168.20.17 (192.168.20.17): 56 data bytes
64 bytes from 192.168.20.17: icmp_seq=0 ttl=255 time=1.3 ms
64 bytes from 192.168.20.17: icmp_seq=1 ttl=255 time=0.6 ms
64 bytes from 192.168.20.17: icmp_seq=2 ttl=255 time=0.6 ms
64 bytes from 192.168.20.17: icmp_seq=3 ttl=255 time=0.6 ms
64 bytes from 192.168.20.17: icmp_seq=4 ttl=255 time=0.6 ms
So I'd guess that
Hope this helps you when you buy your next NIC.
Stuart Cheshire already patched Linux to improve modem latency 4 years ago, but it wasn't accepted into the distribution. It's on this webpage.
Quite right... I had forgotten that. Still, I thought it had happened once.
On another note, why was this moderated off topic, but mine wasn't?
Sheesh