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???
Carmack would be able to write linux software modem applications if the modem vendors released specs. He should apply pressure to them. But that requires too much work, I guess. Takes time away from him riding around town in his fancy, little cars.
Bare rumor? not much of a story.
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
Winmodems are evil. So is Carmack. They should both be rendered obsolete.
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".
Do you really think that Jon-Motherfucking-Carmack is underhandedly trying to increase his fame and popularity by writing some _winmodem_drivers_ for linux? What is he going to be remembered for, in the end? Not some drivers. It is idiotic of you to think he could be doing this for any type of personal gain. I bet he can even afford to by a real hardware modem, and doesn't even need these drivers to use the internet (well, I think he has a T-1, so it's not such a problem for him), so it'a gotta be purely altruistic.
Why don't you find a bridge to hide under and assault thoue who try to cross.
It is quite clear that Winmodems stiffles the competition in the OS market. People are going to be forced to by MS Windows [TM, Crashus Everytimus] just to use their modem. This is far more dangerous than releasing I.E., free with Win9x to kill Netscape.
Even performance-wise, Winmodems suck as much as windows, because the CPU and the operating system endup doing work the Modem can do itself. Therefore, the customer is not getting the best deal possible. So I believe customer protection groups have a case here.
And as Winmodems degrade the performance of the machine in question, Microsoft [TM, Killcompetitus Maximus] can not, in any sane way, claim that Winmodems are an advancement in technology. It is just another diabolical project by Microsoft Dirty-tricks Department [TM], to make sure that humanity shall forever be doomed by a substandard operating system.
Windows 95: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.
John Carmack has done nothing for anyone but himself. If he were interested in others he would think before speaking and putting his geeky foot in his mouth. I piss on John.
[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.
software can never outperform pure hardware implementation. software modems just allow new ways to handle applications.
Carmack is in this to enhance his name. nothing more, nothing less.
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.
John Carmack has done nothing for anyone but himself.
John would be more generous if he'd kick your ass.
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.
---
hardware modems are cheap as hell. whom do you think you're kidding? winmodems have always been about Microsoft roping in hardware vendors to support the windows platform to the exclusion of other platforms. You can continue to take it up the ass from Microsoft, but I won't be joining you.
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
Carmack is in this to enhance his name. nothing more, nothing less.
You mean that just because he has written some legendary software he is no longer entitled to an opinion? Many people here have become famous from their works, should that make them any less important than the rest of us? Carmack has a reputation for getting things done and making a statement with his works.
Back under your bridge troll before you get fragged.
Can you get more specific than that? Are these application layer protocols or will they replace something more fundamental?
John can't fight. he's a geek.
------
5. Don't be an asshole. He's pry brought more enjoyment to people than you ever will.
----
You've been talking to his girlfriend huh?
You can continue sucking his dick if you want to, I don't engage in that behavior. John Carmack doesn't impress me. He codes fucking games for Christ's sake. In the great scheme of things, that ranks right above winning a farting contest.
John can't fight. he's a geek.
You have no room to stand. Your anonymous.
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
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.
For LAN games TCP/IP is way too slow. I use UDP myself
UDP is a form of TCP/IP packet.
---
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.
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?
There are very set limits to how fast signal processing code can go, and it's not going to get much faster than it is - the inner loop for most signal processing tasks is a MAC - multiply and accumulate - that inner loop takes probably 90% of all the processing (the rest is mostly overhead). Without faster hardware, you're not going to improve that routine an significant amount. However, it does mean when you upgrade your CPU, it's like upgrading your modem too.
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
This is a pretty interesting approach to optimizing internet gameplay, but it would definately be a good thing if we could reduce the latency. Most hardcore gamers will go a long way to get even a slightly better ping, so we would have alot of new Linux users if there's a more efficient stack.
But how much optimization can actually be done? I realize that the current implementation has been designed with non-realtime protocols in mind, so there's certainly some room for improvement. If you could chop upwards of 5ms off of your ping, it's worth it, but is that even possible? I would think that any difference would be on the order of a fraction of a millisecond.
Can anyone with experience in this area comment on how much of the latency is actually caused by current stack implementations, and how much we can possibly hope to chop off?
You know what, why don't we . . .
Is it just me or is the air getting thick from the smell of inbred trolls from Redmond in here?
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.
Are you stupid? It's either UDP or TCP. They are both transport protocols.
This is exactly what I hate about slashdot. A bunch of dumb fucks running around after reading an intro to <insert anything> and thinking they know everything.
If you don't know what the fuck you're talking about, do some research you dumb bastards. it won't hurt to not have your stupid comment grace this website.
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.
I don't code 3d games. There are several people who do and who do it quite better than Carmack. Carmack had his 15 minutes of fame.
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.
Look, people, I'll agree that Carmack is a pretty sharp applications/games hacker but a lot of the networking code has been either written or tweaked by David S Miller, one of the most serious kernel speed freaks around. I'm not going to say there's no room for improvement - NEVER! - but Carmack's in for a rude surprise, especially when he learns that nobody will take his patches because they will almost certainly (if they exist) trade bandwidth for latency, a classic tradeoff. Plus, if his kernel code looks anything like his games code, Linus will puke his guts out while replying "NEVER WILL I ACCEPT THIS SHIT IN __MY__ KERNEL!!!" Go back to userspace, John, and write the GaMeZ for the lil kiddiez to use; it's easier to make money that way too.
--ac
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.
You sound like some punk who has never in his life spent any time outside the big cities. There are people who'se nearest neighbor is 10 miles away, and some of them are lucky to have voice telephone lines availible. High bandwidth will most likely never be availible for them, at least not until someone comes up with a consumer bidirectional satellite connection.
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.
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
Carmack's use of openGL for game programming forced Microsoft to start making Direct3D allot more useful. I will totally get all gitty if Carmack and other Linux peeps turn Linux, not only into the primo server and desktop workstation, but also the killer gaming platform. Everyone knows that a huge part of the Linux croud still keep a partition of windows95/98 around, just so they can play games ;-)
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!
There is already a reworked ip stack and I'm using it now. (kernel 2.3.36) The network code has been heavily modified in a move to much finer-grained locking, and removal of inefficient extra memory copies.
and this is not just theoretical stuff -
I'm here to tell you that the speedup in quake3 is very significant over the 2.2 kernel. Moving to 2.3 was just like getting a hardware upgrade for free - it's way faster than 2.2, even with Ingo Molnar's low latency patches.
I'll never go back to 2.2 again.
Lol... 15mins... lemme see... John Carmack, his brother and Romero (now working on Daikitana) do Wolf3d... First best 3d game.. (cant tell if Commander Keen was written with Carmack onboard) When everyone tries to copy Wolf3d, we get from ID Doom... now we dont walk on flat surfaces.. Then we get Quake, technically pushing new barriers, but Duke3d steals the light. Then we get Quake2... not fun to play, but boy the networking is the fun.. Now we have Quake3, gfx amazing... but prolly UT will steal the light again for more pleasant net gaming.. --- Carmack worked there and he wrote the core.. Quake engine is most oftenly used in other games (like Halflife). He releases old games that we know no one will play under gpl... Now what have you done to the scene? for the gamers? for the 3d market (heck he brought 3dfx to life by writting code to use their hardware accells in quake1 and 2).. He now is bringing OpenGL to us, so we dont haveto rely on clunky glide (which some say is nicer to program in than OpenGL).
...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.
your opinion isn't worth the breath it was uttered on. Carmack isn't shit. His networking code finally came about because everyone else was doing it right. Carmack can suck my dick.
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
In the next major release from Be Inc. BeOS users will have a brand new tcp/ip stack to play with. Knowing Be Inc. they wont settle for anything less than the same performance as BSD unix. With Apache on it's way and with php and perl BeOS should be a really good server choice for normal web services.
we're here to stick it to retards like you. you can resume praying at the Linux and John Carmack temple.
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
TCP/IP does not need a reliable link protocol.
In fact, the duplication is harmful.
UDP/IP doesn't need it either.
There seems to be one or two ac's running amok and posting messages that Mr. Carmack is shit, and that there is nothing that he can do to improve anything.
Annoying ac, you are an ass. Carmack is good at what he does (3d game engines), and has many years of experience coding. Could it be that *gasp* he can code other things as well? Perhaps even do a great job?
Besides, the article on the shack is a replay from an email that sCary sent to Gabe, who said that Yahn talked to John. That means that 1) John said something to Yahn 2)Yahn repeated that to Gabe 3)Gabe wrote a short reply to sCary's email 4)sCary posted it on the shack. Fourth hand information should not even be discussed in anything other than a passing conversation.
It is certainly nothing to argue about. Now enough posting, I'm off to play TFC. Look for me on the LinuxQuake.com TFC server, and remember, saying th3 Bl00 t34m 0wNz j00! in anything but a jest will result in at least 10 spies hunting your ass down for the whole game.
--Have a Johsonville brat.
So that post gave me an idea for a windowmanager:
The "root window" would be the inside surface of a sphere. The perspective would be the exact center of the sphere. Optimally, one would have a separate trackball to rotate the sphere, but alternatively a 2nd mouse would do. (And, of course, meta-shift-arrows as well)
The inner surface of the sphere could be divided into a grid of hexagons, each with a picture. Picture of what, you ask? Perhaps a choice between a view of a desktop or a custom pic. Bringing the appropriate hexagon to the centre of the screen and clicking would zoom into it to give you something akin to a regular desktop (unless you were running something which filled the screen).
Ah, if only I was a programmer. I would certainly pour hot grits down my pants if such a windowmanager came to exist.
oooohh. someone knows what ICMP means. Like the rest of us with brains don't. What a waste of a comment.
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.
I'm happy to hear that Carmack is interested in making useful contributions to the world. Aside from some work on GLX, most of his development work has been on extremely violent, stupid games that incite idiots to go around shooting people.
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
Aehm ... not quite or slightly missleading as TCP and IP are independent and none requires the other.
Regarding the rest ... well, at times TCP seems to be shoot-and-pray to me too, but this is a problem of our local network only.
would you like him to fuck you in the ass?
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.
At the end of the day guess who, or what is going to be blamed -- that other OS and it will not be Windows.
Hmmz do i notice a little contradiction here : * Q3A plays *wonderfully* on my seriously lagged 28.8!); * 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
UDP header compression (for that matter, compression of any type of IP header) over PPP is covered by RFC's 2507 and 2509, which were published nearly a year ago. These are "standards track" RFCs. Now the only problem is getting it implemented everywhere (but maybe that's what you really meant).
get lost loser
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....
Meaning DSL or cable modems. Dial-up modems are dead end technology.
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.
This is JohnC IMHO, I compaired tri-word groupings here and in his plan and got a good match.
If you look at MS ping and traceroute it uses UDP not ICMP, however the common UNIX variants use ICMP.
"You seem to have forgotten the chief advantage of a winmodem. They're cheap."
And that's the only real advantage that they have.
You might want to make a note that that price differential is more for the hardware makers benefit than the consumer. The maker saves on some components. The modem maker marks up appropriately. The kicker is that the components that make up a "real" modem aren't pricey and could be brought down some more if desired, narrowing or even eliminating the so called price advantage. Hardware also can out perform software all other things being equal. Someone else here noted that upgrading your processor would be like getting a new modem. One people don't upgrade their processor all that much. Second is it really that economically justifiable if you compare the "horsepower"/cost of upgrading "real" modem vs upgrading cpu? Overall looking at trends and everything else and I can say that winmodems aren't the long-term bargains that everyone makes them out to be. The only ones making favorable noises towards them are the makers and people who own one. In answer to the head question we don't have to do everything everyone else does.
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.
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. Now do you see why people who've been computing for years (read: grown up since the HaX0r days, actually work with modern OSes) just might think Linux is a piece of shit toy OS? Have fun waiting around for it.
> software can never outperform pure hardware implementation.
Bullshit. Why all the craze over DSPs? Besides, it is easier to upgrade software.
Ryan
The guy just wants to know what flaw John Carmack has found.
Suppose you were driving your car and someone flagged you down. You pull over and he says to you "hey there's something wrong with your car!" Would you (a) say "yes I know. It would be impossible to prove that it's perfect." and drive of; or (b) ask what's wrong with it?
So if you KNOW what's wrong with it, TELL US ALREADY! If you don't, shut the fuck up.
I actually do respect Carmack's skill, but listening to dorks like you treat Carmack like the greatest programmer in history is nauseating. Who knows, maybe he is, but you wouldn't know, because you couldn't code your way out of a paper bag if your life depended on it. So shut the fuck up already, because your opinion on who you think is a great coder doesn't mean shit. Got it?
..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
That type of attitude disgusts me. The sooner you learn that the *only* measure of success is totally subjective, the sooner you will realize that work on, for example, Linux is no more worthwhile than work on something like Quake. In a Universe where Mankind is totally irrelevant, a miniscule collection organisms on a miniscule piece of rock, a Universe where there is no end-goal, anything we humans do is irrelevant and trivial, regardless of how it is perceived by other humans. None of us matter. We, as trivial collections of molecules, have only our happiness as a measure of our success. loryan@sfu.ca www.sfu.ca/~loryan/neural.html
This is the first AC post *EVER* to reach a score of 4.
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
OK, let me rephrase what the poster was trying to say. Software running on a general-purpose scalar CPU like an x86, even with MMX/SSE/3DNow extensions, can never outperform a cheap, dedicated DSP chip which was designed to do nothing but fast frequency-domain transform work.
DSP tasks are very specialized and very vectorizable. The speed of a DSP implementation scales more or less geometrically with the gate count. That hasn't been true of the x86 architecture for a long time.
I have a great deal of respect for John Carmack, but in this case I think he's misapplying himself. Trying to make 10% of a $600 CPU act like a $10 DSP chip is not an optimization problem -- it's an ethical one.
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.
It would be nice to see JohnC throw his weight behind PowerPlay. IP stacks are a pretty damned mature technology at this point, and I'd be utterly blown away if there is much low-hanging optimization fruit left to be picked.
These rumors seem somewhat misguided, to say the least.
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
So now hardware quality determines collision rate? Better read up on CDMA loser.
Wrong...ping and traceroute use ICMP, even in MS land.
Now that was GOOD. Peace brother.
;-)
(But of course it doesn't matter what I think.
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.
uh, TCP == Transfer Control Protocol.
Shared media are cheaper but suffer from contention. If you want to avoid collisions, you buy switched 100BASE-TX instead.
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.
That's funny, my copy of RFC 768 is titled "User Datagram Protocol", and the word "Unix" isn't there at all.
so, please illuminate for us, just where in the TCP/IP stack, do you code I/O completion ports ?
If you lay out an IP packet, ICMP is encapsulated in the body just like TCP and UDP are. It's a utility built as if it were an application.
Connections are controlled by the SYN, ACK, and RST bits in the header of every TCP packet. Granted, things won't work very well without unreachable messages or quenching, but you could still limp along.
Ping is an ICMP echo request, practically by definition. And traceroute as we know it wouldn't work- it deliberately sends packets that should time out before reaching their destination, and "TTL exceeded" is an ICMP message!
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
wrong again. Ping uses ICMP on both windows and UNIX. Windows unix uses ICMP for tracert, whereas unix's traceroute blasts UDP packets at a presumed unused port range, and listens for the ICMP ttl expired messages.
That is why you can easily fake out standard unix traceroute by listening to packets on that range of UDP ports. Of course, traceroute itself has an option to use a different port range, so the arms race continues.
try Transmission Control Protocol.
"who says a WinModem can't work as well as a real modem? "
Me
Everyone with more than half a brain.
Only total fools allow themselves to get saddled with these dogs. Then again all modems kinda suck now a days I guess. I couldn't put up with one today. Really I think there's better things for people to work on with Linux than the TCP/IP stack or WINmodem support, something I hope I never see. Why should Linux support substandard hardware? If John wants to work on something maybe he should pick something more in line with his expertise? Linux only supports 2 chipsets for hardware accelerated GL that I can tell.
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
"High bandwidth will most likely never be availible for them, at least not until someone comes up with a consumer bidirectional satellite connection"
Try cellular phone network. There are third-world countries who are skipping the "run a wire" phase of communications infrastructure, and going straight for wireless. So he may be a punk who lives in the big city that doesn't mean that people out in the "sticks" will be stuck with low bandwith connections. BTW high-speed satellite connections are available. Problem like anything nice is of course cost.
This is what one programmer wrote to me regarding the new tcp/ stack. "The stack that is being worked on will be very cool. It was designed by looking at BSD and linux and anything else, and trying to figure out how to make it faster and more modular. I am personally very impressed with the design. I, however, do not know when it'll be released. It's fairly far from done, so probably not the next release...""
I expect to see some talk of this on kernel traffic?
>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.
And outside of dimwitted tech reporters who work 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. Linux and the BSD's are doing just fine without chasing after "Joe Six-pac" and his brood. If they want to take the time and effort to learn Linux or any other OS, fine. But we shouldn't bend over backwards for them. The companies who make and sell those shitty Winmodems should be recieving all the abuse they are getting from their customers over manufacturing and selling such a shitty product. It not that the "Linux community" are about to band together and decide not to support winmodems, it's that most of us just couldn't care less either way.
Gracias, Muerte2, you have clarified what I so brilliantly fux0r3d up. ;-)
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.
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?
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?
Hmm - I thought USB modems were actually real modems. (Although there might not be Linux support for them yet.)
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.
> Linux lacks many of NT's optimization features (like IO completion ports)
:)
man sigaction
> or evn sufficient use of any threading.
Define sufficient; some parts of Linux are more threaded than others. Why rework something if it isn't a bottleneck?
> Also, lets not forget Windows 2000 currently holds the networking speed record.
For what? And if so, where are all the sites out there using it
what's with all this anti foogle atitude?
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 reason that is in stack? Then we gotto remove that stupid limit NOW. I want my modem work at it's fullest.
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...
The average generic winmodem costs about $16-$18 online.
You can probably find a 'real' one for about $50
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
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
...or Jesus
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.
It wasn't an AC post though, and the funny thing was about thirty or so people moderated it as "funny" and 18 moderated it as "offtopic" or whatever
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
I can agree that he is in it to enhance his name, but to say that is the only reason is absolutely lame. People never do something for one reason, we always do things for many reasons, like for example, I could say you are posting out of jealousy "nothing more nothing less", but the truth is you're posting out of jealousy, ignorance, lack of control, AND lack of responsibility for what you post.
And I bet you want to hold his hand while this happens, pervert...
"I don't code 3d games." Obviously, you probalby don't do anything worthwhile other than swear at the people you're jealous of because you know they're smarter and more worthwhile than you will ever be. "There are several people who do and who do it quite better than Carmack." So name them. Who was making a game with a better or more advanced engine than Wolfenstein 3D in 1992? Better than Doom in 1993? Better than Quake in 1996? Better than Quake 2 in 1997? Better than Quake 3 today? The answer is nobody. Not even Tim Sweeny of Epic (Unreal/Unreal Tournament) is beating him at this game--Q3 is definitely the stronger engine across the board when compared to UT.
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
uhh...so you think that 100base-tx is able to go out on the network before sending the packet to see if the line is clear? Wow, so when did ethernet start using tokens. Collisions are a fact of life with ethernet, it was not designed as a collisionless protocol it was designed to minimize the latency between when a collision is detected and a new packet is sent out.
the guy has to do everything at id practically. he doesn't have free time to spend on this kind of thing.
Do you think Carmack is going to come to your house, shake your hand, suck your dick, and let you drive his Ferrari after you backed him up on Slashdot?
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.
some AC: You mean Linux is being actively developed and improved.
Red herring. Just about every OS is being actively developed and improved. Improvement's not all that helpful when the thing's still broken. The more I think about it, the more ridiculous your answer sounds. "Johnson, ya got that blueprint done, it's time for the meeting!" "Done, boss? What for? Don't worry, it's under improvement." "Johnson, you're fired."
And as for the NT thing, if you want to talk about NT4, service pack 5 actually came out last May. So Linux's fix still isn't here yet, and it's already closer to a full year behind than it is to being just "a few months ago."
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
uhh...so you think that 100base-tx is able to go out on the network before sending the packet to see if the line is clear? Wow, so when did ethernet start using tokens.
Uhh... That *is* exactly what ethernet does ("goes out" on the network and sees if it's clear). It's called CSMA/CD. The CS stands for "carrier sense". It listens for activity on the network, then sends its data, then listens again for an unusual amount of high voltage that would indicate a collision. If a collision is detected, it resends using an exponential backoff algorithm. CSMA/CD greatly reduces the number of collisions compared to a "spray and pray" approach, but they still happen from time to time on shared media (especially with 20%+ utilization).
Dickwad. It isn't out yet.
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
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.
Congrats John,
Hope the weather is nice and the surf is kicking. Itchi
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.
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.
You elitist pig. You should start using NaziOS.
Carmack has consistently pushed OpenGl as the 3D API of choice. This has had a very good effect on the industry. It has pushed IHVs to release decent drivers for Windows, giving people the choice on that platform of using a) Microsoft's proprietary API which isn't portable to Linux or the Mac or b) an open API, which makes porting to other platforms far easier. Similarly, on the Mac Carmack wanted that same open API, rather Apple's proprietary API. What's wrong with that? As a result, cross-platform 3D programming is in a far better state than it would have been. The fact that Quake 3 was released without Rhapsody appearing gives the lie to your comments regarding that. Apple were trying to position the Mac as a gaming platform. Carmack told them what was needed to support it. Carmack then put in significant effort making sure Quake 3 worked on the Mac. End of story.
Your comments regarding 'shunning' 3dfx are even wider of the mark. Carmack is on 3dfx's technical advisory board, for a start, so he hardly 'shunned' them. You also clearly don't know enough about 3D APIs to talk about them authoritatively. No Quake game ever supported GLIDE because it's a hardware specific API (apart from Creative's very limited 'unified' drivers), which is now pretty much dead. Why would anyone target one hardware platform with a low-level API, when they can get more done in a higher-level API and support every card with a suitable driver? You are presumably thinking of the switch from 'mini-drivers' (OpenGl drivers with such a limited subset of functionality that they wouldn't run anything else) to full ICDs. These are an ugly hack that was OK in the days when 3dfx cards were about the only ones which would run GLQuake, but they mean only games specially targeted by 3dfx (or whoever) can run with OpenGl - they just aren't aren't satisfactory with the profusion of modern games and cards. The problems with Quake games and Linux ARE due to problems with the environment. Linux OpenGl support simply isn't very good at the moment, and Carmack is working with other people to rectify this.
I don't see the problem with AMD support for Quake 2. It works doesn't it? I downloaded the patch and the optimized drivers. Now Quake 2 runs faster on my K6-2/400. Where's the problem?
If you'd read Carmack's post above, you'd know that this rumor about re-writing the stack is not entirely correct, anyway. Your little parody just doesn't fit with the reality. Carmack is a pragmatist, but he uses the influence he has to try to steer the industry in directions that are ultimately beneficial for developers and consumers. Your complaint isn't that Carmack ignores the environment in which his code sits, it's that he doesn't support every possible environment.
>You elitist pig. You should start using NaziOS.
Sticks and stones may break my bones, but *Mircosoft Astrotufers* can never hurt me......
the linux version can't be found anywhere in many countries.
They will just have to rely on stats from the master servers to guess how many linux users are playing.. So i bought the windows version, launch IDA and reversed it.
Get the 1.11 linux demo from loki and use my gdb batch !!!:)
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
ROFL, you elitist pig? What are you crying about? The man's not talking about sending Winmodem users to cattlecars and hence to gas chambers. And NaziOS? LOL, give me a break. You sound like an intellectual imbecile who really doesn't understand what the Nazis really were. Did you just learn the word in school last week? Oh, don't figure that you did. That was Christmas vacation.
I don't want to sound rude or anything, but what about giving the game access to the modem so the game could use it's own protocols. You wouldn't need to worry about PPP, UDP, or IP layers at all, you could put whatever you want in your own game-modem code. The problem would be of course people who have to dial long distance, but it would be a lot better to play on a server in your city/area anyways. I know most game servers shouldn't get their own phone numbers, but what if some one wanted to offer up there unused phone lines to let some modem player get a lower latency connection. If you want to spend the time making your own PPP drivers and your own modulation/demodulation, you might as well add in some modem code into your games. ~Jacob Brown
"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?
aren't you?
uh...
help me out here.
what would listening on those udp ports for incoming datagrams have ANYTHING AT ALL to do with the TTL expiring on the ip datagram?
clue:
they are and always will be mutually exclusive. the frames WILL NEVER MAKE IT TO THE DESTINATION because an intermediate routing element will drop the frame THEN send an icmp message back suggesting TTL expired in transit. unless you're referring to a compromised routing element, i'm not sure what you said has anything to do with reality.
sigh.
you'd think no one around here ever read by the likes of these comments...
i second, third, and fourth this suggestion.
there are WAY too many people posting that have no business to be.
LURK folks. only post when you have the humility to *ASK* or the authority to *SUGGEST*, but never the audacity to *TELL*.
sigh.
i hope that didn't really intend qualcomm's money-maker to have anything to do with CSMA/CD (to which i expect it was you were originally referring...)
your point is well taken, nonetheless, but i do expect qualcomm would be pleasantly surprised that their technology is being praised as the sucessor to the kitchen sink.
When OpenGL in BeOS is done for R5 I really don't see why people should use Linux to play games. BeOS installs in 10 minutes, boots in 10 seconds, give it another 5 secs and you are playing your game with some extra FPS compared with Linux/Windows.
There are a pair of unmatched braces on or around line 1135. Oh and sometimes the dude indents at one tab-setting, sometimes at another. Very annoying if you ask me...
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
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.
Let's just say that I want to see ANYONE else in the world write an engine that looks as good as Quake 3--AND runs at 60fps on a fairly standard $2000 PC. Here's a hint--the frames for things like Toy Story take a LONG time to render, even with huge render farms. Writing the programs to create such effects isn't necessarily all that difficult, but doing such effects in real time on consumer hardware in combination with sound, network, server, physics, ai, and other code all running simultaneously IS. And the techniques used in games like Unreal or Q2 and Q3 aren't really that much less advanced in many ways than what you see in tory story of the phantom menace, they just need to be seriously constrained for performance reasons. They've got reflections, volumetric lighting, radiosity lighting, specular highlighting, particles, curved surfaces, active player shadows, dynamic lighting, moving curved surfaces, bump mapping (not used in the retail game for performance reasons on current hardware), and more, all as elements of active "shaders," but of course many of these effects need to be toned down a lot to be playable in real time on cheap PCs. And everything needs to be made to work in arbitrary situations--every model needs to look correct from all angles in all situations, animations need to be done in real-time in response to arbitrary player input, etc. There is no "cheating" here in getting it to look correct from only one POV or of the animation being hand-crafted to work only in one specific way. On top of that, it's running a complex server with advanced physics modelling and game rules, bot AI (pathfinding etc.), sound code, music, and networking code (with very complex client-side prediction to smooth out the effects of modem/internet lag) all at the same time... and it has to run well on a huge range of hardware/software combinations... No, writing a game engine like Quake 3 is NOT a trivial task. There are only a small number of developers in the world who have proved capable of doing so successfully in all respects, and id is the foremost of those. And as time goes on, the task of writing such engines is getting more and more complex.
True, that was a nice engine. I think it came out about the same time as Wolf 3D, but traded somewhat nicer looking graphics for slower rendering speed. But for people contesting John Carmack's programming skills, I think the track record of 10 years of such accomplishments, always being at or near the leading edge of real-time technology for graphics, not to mention accomplishments in networking, scripting, and other areas, pretty much speaks for itself.
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 -
>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
the netbsd stack wh00ps on the linux stack, and it runs on quite a few different pieces of hardware... i'm all for a complete stack rewrite for linux.
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.