That astronomer really ought to learn some orbital mechanics. The closing speed between the comet and the Deep Impact probe was about 10 km/sec. Soft landing the probe on the comet would have required an equal amount of delta-V from a rocket engine to match the comet's velocity. 10 km/sec is roughly earth escape velocity, so we're talking about a landing rocket roughly equal in size to the one that launched it from earth!
Comets tend to have oddball orbits, often highly inclined to the ecliptic, that can make them very hard to reach because of the required delta-V. Tempel's inclination is only 10 degrees, which is probably one of the reasons it was chosen for this mission.
In any event, it's far easier and cheaper to crash into a given celestial body than it is to rendezvous and land on it. And in this case, an impact was highly desirable since it represented an easy way to expose and study the material deep below the surface.
Robotic exploration of objects in the solar system generally follows a pattern of first flying by an object, then "hard" landings (impacts that destroy the spacecraft), then orbiting it, and then landing on it. That's exactly how the moon was explored; I'm old enough to remember the Ranger series of spacecraft that hit the moon in the mid 1960s, leading the way to Lunar Orbiter, Surveyor (robotic soft landings) and eventually Apollo.
If the body has an atmosphere, then air drag (heatshields and parachutes) can be used to convert a hard landing into a soft one, but the moon, comets and asteroids don't have atmospheres.
I expect somebody someday will figure out the intricate gravity assists that would be required to rendezvous with a carefully chosen comet and match its velocity. But you have to crawl before you can walk, and Deep Impact did an excellent job of that. Remember also that Deep Impact is a Discovery mission, which means it has to make the most of every dollar spent. It very clearly did that too.
My position on smart vs dumb peripheral cards is really limited to network interfaces. There, the protocol operations to be performed on every data byte are way down in the noise compared to the operations to be performed on that same data in the application.
Video controllers are an entirely different story since a lot of very specialized processing has to be done to produce every tiny pixel of image data. There it makes a lot of sense to have specialized graphic engines, especially since there is a large gaming market to amortize the non-recurring engineering costs.
The same can be said of modems since many specialized DSP instructions also have to be executed to send or receive a byte of data. However, dialup modems operate at such slow speeds (and, thanks to Claude Shannon, will never operate faster than 64kb/s) that even these complex operations can be done in real time on modern host CPUs with most of the CPU left over. And all the latest general purpose CPUs implement a pretty powerful DSP engine in the form of MMX, SSE, SSE2, SSE3 and Altivec. So I think Linux's problems with the Winmodem have more to do with the inability to implement standard dialup modem functionality in open source software because of patents than any fundamental technical reasons. Also, there is (still) a large enough market for dialup modems that the NRE can be easily amortized. I.e., external modems are dirt cheap, so why not just use them?
Yes, you're right that there have been (and probably will continue to be) short windows of opportunity for so-called "smart" (and expensive) network cards, most often in legacy systems that can't easily be replaced, but in the long run I think Van Jacobson's position has already been adequately vindicated. You just can't compete with mass produced general purpose CPUs when you're executing a network stack.
I still don't think those things necessarily call for a lot of smarts on a host network card. Several of the features you mentioned, such as VLANs and QoS, put most of their complexity on routers, not hosts.
For those operations that do involve the host, I can't think of any that require a lot of complex code to be executed on each and every data packet. For example, setting a VLAN or QoS value just involves copying a constant into a packet header; that's trivial since you're already copying a whole bunch of other header constants (IP addresses, port numbers, etc).
The one thing you do want on a network card is lots and lots of buffering so the host can take its time to service it and transfer lots of data in each servicing operation.
Pretty much, I think. (I'm a big fan of Linux software RAID).
The arguments for hardware RAID seem to have to do more with functionality than performance. For example, you can't boot off a software RAID-5 array, but you can with a hardware controller. (I get around this on my own system by making the boot volume RAID-1 and having a separate RAID-5 array for large, static databases.)
Also, I've had some system lockups when a drive in a software RAID array fails, probably because the controller and/or its driver got confused. This isn't really a strong argument for a hardware RAID controller (the non-RAID disk controller and/or driver simply ought to be made more robust) but a hardware RAID controller is probably more likely to tolerate a drive failure without hanging since tolerating drive failures is precisely what a RAID controller is designed to do.
If there's a problem with RAID, in software or hardware, it's that there are too many single points of failure in most inexpensive RAID boxes as they're actually constructed. Unless you buy a expensive box with dual power supplies, the power supply is one of them. So are the CPU, memory and software of the host machine to which the RAID array is attached. I've thought about building a "network RAID" where I construct RAID arrays out of network file systems exported by physically separated servers over gigabit Ethernet. No matter how any one PC/controller/drive combination fails, the client machine should recover. Problem is, even that scheme is vulnerable to a failure of the client machine. So RAID isn't the only answer, and higher level data replication schemes are needed to complement it.
Okay, so maybe it was 30 instructions -- it's been 15 years and I came up with that figure from memory. BFD. Whether it's 20 or 30, it's a small number, and as CPUs get faster, it's an even smaller number of nanoseconds to execute. How many instructions will that same CPU execute to process that same data at the application layer? The likely answer is "orders of magnitude more". That means the protocol processing is already down in the noise, and you're just pounding the rubble by trying to optimize it further.
You mentioned "fast path" but you obviously didn't understand what it meant or why it was important. Timeout code, connection establishment, out-of-order reassembly etc, etc, are all irrelevant to performance because they're rare events. You only have to optimize the most common case, which is that the TCP packet you're processing is in sequence and has only the ACK bit set (and maybe the PSH bit, though most OSes can just ignore it).
That's what the fast path code handles, and that's precisely why VJ could do it in only 30 instructions! You're just wasting your time optimizing the stuff that rarely happens; that's basic software engineering.
The only other protocol operation that takes any significant time is the checksum calculation, and here the memory access time dominates. So VJ's answer to that was to build a memory copy operation (which you need anyway) that simultaneously computes the checksum in a single memory access. Simple, and no special hardware is needed.
In nearly every case, really substantial performance increases can be had with very simple and transparent changes; you don't have to get fancy. If you can't handle an interrupt on every packet, then don't interrupt on every packet! It's that simple. Just put lots of memory on the Ethernet controller and let the host transfer a whole bunch of packets on a single interrupt.
When I did my TCP/IP stack for the PC in the mid 1980s, I learned a very simple lesson about interrupt handling: do as little at interrupt time as possible, and do it as seldom as possible. Device hardware, and by extension their interrupt handlers, really have only one function: to buy time until the operating system and upper layers can get around to you. The device and/or interrupt handler (ideally the former) should therefore be able to run as long as possible without host intervention. That means having as much memory as possible to buffer incoming data to ensure that nothing gets lost.
This approach adapts nicely. When the host CPU is fast or lightly loaded and/or the input data rate is low, the host can easily service an interrupt on every packet. But when the data rate is high and/or the CPU is slow or heavily loaded, multiple packets are handled on each interrupt, thus cutting interrupt overhead per packet precisely when you need it.
The same approach has been long used in simple devices like serial ports; the National Semiconductor 16550 UART, for example.
This is weird. The board was billed as an accelerator, but it seems little more than a conventional Ethernet controller with an unconventional host interface. Why that should cost $500 is beyond me.
User-space TCP/IP is hardly new. I did it in 1986 on the IBM PC, mainly because there was no protected-mode OS available for the 8088 and 80286 at that time.
I still think that as CPUs get arbitrarily fast that the conventional network protocol architectures will work just fine as long as the Ethernet hardware can actually run at full network speed and have halfway decent host interfaces.
Don't listen to just the second movement of the 7th; try the whole thing. Beethoven's 7th is the piece that got me solidly hooked on classical music. In many ways the 7th is even better than the 9th, though the 9th too should be heard in its entirety. The last movement is a different experience after hearing the first three; just listening to the Ode to Joy is like eating dessert on an empty stomach.
As my former landlord used to say, if Beethoven doesn't move you, then you must be dead.
"Legislating from the bench" and "activist judge" is just neoconservative code for "striking down my repressive, Draconian laws just because they happen to violate the Constitution".
Some people seem to forget that the Constitution -- including the Bill of Rights -- is the supreme law of the land, and judges have a duty, as established in Marbury v. Madison to strike down unconstitutional laws and abuses of executive power. It's that simple.
And how long ago was that? What kind of servers had loads increase by 20% when you dumped the "smart" NICs? How much faster have general purpose CPUs gotten since then? And whose unusually inefficient TCP/IP stack and/or Ethernet driver were you running?
"Smart" network cards are one of those bad ideas that keep coming back from the grave, because computer science seems to lose its collective memory every decade or so.
Fifteen years ago, Van Jacobsen did a wonderful presentation at SIGCOMM 1990 on just why they were such a bad idea. The reason is very simple. A modern, well-tuned and optimized TCP/IP stack can process a packet with only about 20 instructions on average. Very few "smart" controller cards have host interfaces that can be spoken to with so few instructions! The switch to and from kernel context will usually cost you more than TCP/IP.
Not only that, but the coprocessor on the "smart" controller card inevitably ends up being considerably slower than the host CPU, because typical host CPUs are made in much larger quantities, enjoy large economies of scale, and are updated frequently. So you often have the absurd situation of a blazingly fast and modern host CPU twiddling its thumbs waiting for some piss-poor slow CPU on a "smart" controller to execute a protocol handler that could have been done on the host with fewer instructions than it takes just to move a packet to or from the "smart" card.
And if that weren't enough, rarely do these "smart" network controllers come with open source firmware. Usually the company that makes them obsoletes them quickly (because they don't sell well) and/or goes out of business, and you're left with a very expensive paperweight.
Since his talk, Ethernet interfaces have totally obsoleted "smart" network cards. They now come with lots of internal buffering to avoid losing packets when interrupt latencies are high, and they take relatively few instructions per byte of user data moved. What more could you want?
E*Trade Bank just started using optional SecurID tokens. I've always found them a pain in the ass, but when it's my own money at stake, I'm a little more willing to put up with the inconvenience.
But I agree the best way to solve the problem is to bring your own computer.
I think the auroras appear only when the bomb is detonated above the atmosphere.
Close to the ground, the atmosphere absorbs pretty much everything.
That's why fireballs form at low altitudes but not in space. Microseconds after a bomb explodes, its vaporized residue is so hot that its blackbody radiation peaks in the soft X-ray region. The lower atmosphere is actually fairly opaque to soft X-rays, so it absorbs most of this energy and rapidly heats up, forming the characteristic nuclear fireball. Outside the atmosphere, there's nothing to stop this X-radiation and the associated charged particles, so they can be trapped in the earth's magnetic field lines.
This was all discovered when the US conducted a series of exoatmospheric tests (i.e., tests out of the atmosphere) in the vicinity of Johnston Island in the Pacific in the early 1960s. They literally launched real nuclear bombs on real missiles. (Imagine doing that today!)
This was also how the whole EMP phenomenon was discovered, and quite by accident -- some of the tests induced widespread electrical damage in Hawaii, quite some distance away. It was kept a secret for over a decade.
Re:And while we're at it . . .
on
Nuclear Fuel How-To
·
· Score: 3, Informative
Not only that, much of the basic information about the nuclear fuel cycle and nuclear weapons was openly published by the US decades ago in the book The Effects of Nuclear Weapons.
Why do I care what software my friends and relatives run on their computers? Simple -- I always seem to be the one they call for help. If they're running Linux or Mac OS X, the two systems I use, it's usually easy for me to help, often by remotely logging into the machine in question. And I rarely get calls in the first place, because those two systems generally "just work".
But if they're running Windows, I tell them they're on their own. First of all, a typical Windows machine has far more than its share of major problems. Worms, viruses and spyware are almost entirely Windows afflictions, and most people just won't pay attention to my repeated lectures on proper network hygiene until it's too late.
Second, I find it quite painful to debug a Windows machine even when it's in front of me. Time really starts to drag after the first ten or twenty reboots. Trying to do it over the phone from thousands of miles away, unable to see the screen or type some complicated command without having to spell it out verbally several times, is just beyond my patience. VNC is sometimes useful, but it's painfully slow even over cable modems or DSL, and you still need local human intervention whenever a reboot is needed -- which is all too frequent with Windows.
I can't comment on how good Rhapsody is since I've never met anyone who used it. That probably says enough right there.
Well, I had Rhapsody for perhaps six months. A few days ago, when I realized I was paying for something I hadn't used at all for a few months, I cancelled. To do that, you have to call and talk to a human. This not only deters you from canceling, they get one last chance to talk you out of it. The droid I got, apparently in India, was very clearly programmed to do this.
Rhapsody's model is admittedly interesting: unlimited online listening to anything in their library for a flat monthly fee. That does fill a different niche not covered by the iTunes model of selling downloads of individual songs, and it doesn't cost you anything to explore music and artists you haven't heard before.
But aside from being tethered to a network connection to be able to listen to anything, the Rhapsody implementation of this model has two fatal flaws. First, you have to use their own proprietary user client, and it's only available for Windows. Naturally, I avoid Windows like the plague.
Second, their library is, as a Talosian might say, "shockingly limited". It seems that every time I'd look for a particular artist, either they didn't have anything at all, or only one or two albums. Sometimes I'd find an album only to discover that Rhapsody got rights to only a couple of songs, with the rest missing.
I still think the best way to build a usable personal online music collection is to buy the CDs you want, rip them onto your own server, and put the CDs into storage as an offsite backup. Oh, and if you want to explore new and obscure artists, patronize the more enlightened and progressive labels like Magnatune.
Pardon? Are you talking to me? You didn't quote me, so I'm not sure.
If you were, then please support, with reason and logic, the argument that is apparently being seriously made by some in this discussion that the second amendment is intended to enable ordinary, individual Americans with a few small arms each -- or even a state militia -- to rise up and violently overthrow the entire federal government if it ever gets too far out of hand.
Even without the experience of the US Civil War to show us what actually happened when such a thing was once tried, it would be utterly impossible for any rational person to take such a position seriously.
My point is very simple: those who insist that we all need firearms to "keep the federal government in line" are, by any rational analysis, clearly living in a fantasy universe. I'm no psychologist, but it certainly seems that the ownership of small firearms is often associated with a highly exaggerated sense of self-confidence and personal political empowerment that can border on the psychotic. The less influential the person is in their everyday life, the stronger these exaggerated feelings seem to be.
Um, instead of mouthing redneck cliches, why don't you take the time to study a little history? Exactly what you suggest was very seriously attempted about 140 years ago. It totally failed. It did produce almost a million casualties, enormous economic damage and deep political divides that persist today. And the federal government's weapons and tactics then were far more primitive than they are now.
But I guess you'd much rather live in your romantic gun-nut fantasy world.
Sounds like that would quickly become highly I/O bound, and CPU utilization would be nearly zero.
Again, these things have to be carefully constructed to load up everything. It's almost impossible in any real application -- something always seems to bottleneck well before everything else -- and with the architectural complexities of today's CPUs, probably only a little easier to do in a test designed merely to load everything up without accomplishing any useful work.
Actually, this could quite likely be your own ISP's fault. They almost certainly submitted your IP address block to the MAPS DUL in the first place. Otherwise no random remote SMTP receiver could tell that you're coming from a dialup/DHCP ghetto and should be forced to run the gauntlet of your ISP's overloaded and unreliable mail relay and otherwise severely punished even if you've never spammed in your life. I mean, how can you prove you're not a spammer if they won't even accept your TCP connection and run a content analyzer on your message?
It used to be that if you had the "wrong" (physical) address, or belonged to the "wrong" religion, or had the "wrong" skin color, many businesses wouldn't even talk to you. You weren't even given the chance to prove yourself. That kind of discrimination has long been illegal in the US, but it's still legal to openly discriminate on the basis of your IP address, as opposed to your actual behavior (whether or not you spam). That's why the word "ghetto" is perfectly appropriate.
If you have the option, you could switch to a more enlightened ISP that doesn't treat you like a moronic criminal. I eventually abandoned both Road Runner and SBC DSL and signed up with Speakeasy DSL. While their services are priced at a premium, I think they're fully worth it. I wanted several static IP addresses anyway, and when you price static IP addresses from a typical cable modem or telco DSL provider Speakeasy doesn't look so expensive. Since switching, I've never had any email rejected for having an IP address on a blacklist.
And, as icing on the cake, Speakeasy promises to never block any ports -- try getting a guarantee like that out of Road Runner or SBC! So, given a choice, I decided to give my money to the more clueful outfit.
Well sure, that's what I meant; sorry for my sloppy wording. We need to educate our family and friends and anyone else who will listen to boycott ISPs that subscribe to the MAPS instead of letting their users decide for themselves whether they want their mail filtered. What a concept -- giving the customer what he wants!
Many ISPs do things wrong, but many others do it right, and they deserve to be rewarded with your business. Instead of subscribing to MAPS or other ill-conceived IP blocking lists, a good ISP will run Spam Assassin or a similar content analysis tool and merely divert anything marked as spam to a separate IMAP "Junk" folder where you can still read it to avoid false positives (or if you're just feeling a little masochistic). And you can disable even that mechanism if you don't want it. Speakeasy works this way, and they don't seem to subscribe to the MAPS DUL either. (But I still prefer to run my own mail servers.)
I bet many Internet users still don't know that they don't have to use the mail servers provided by whoever provides them with IP dialtone. They can get their mail service from somebody else. It's especially important that everyone on DSL or a cable modem knows this, as the lack of meaningful competition in the retail broadband market tends to lead to some pretty arrogant email server policies.
Even scarier is the closing quote from the police spokesman: "It's a sign that we're all a little nervous in the post-9/11 world."
Excuse me, but how exactly does one equate suspected small-scale counterfeiting with hijacking airliners, flying them into buildings and killing thousands of people?
If this signifies anything, it's how, in the post-9/11 world, American society has gotten so moronic, brow-beaten and petrified that cops seriously expect us to buy such a flimsy excuse for their Gestapo tactics.
By the way, I went to grade school in Cockeysville, MD. My parents live only a few miles away. I'll make sure they avoid that particular store.
I don't think it's quite as easy as running a simple infinite loop. That will certainly peg the CPU utilization at 100%, but it probably won't maximize the power drain and heat output.
Modern CPUs are complicated beasts, with multiple execution units, deep pipelines and big caches. And they're connected to big external memories and disk drive arrays. If you want to stress-test the cooling system, then you need code that keeps all the execution units and all the pipelines and the caches and main memory and the disk array all going full blast. That's not as easy as it sounds. Intel has mentioned various test programs that they use when thermally testing their CPUs, but I don't know that they've ever released them. Perhaps they're afraid they'd might cause damage, and they'd have to deal with a lot of irate customers.
I absolutely agree. My past run-ins with the MAPS people have been extremely unpleasant. "Militant" is exactly the right word. "Self righteous jerks" would also apply.
A while ago, when the MAPS DUL virus first began to spread, my dad began to have problems delivering his mail from his Linux system on a cable modem. So I contacted MAPS and told them about what I naively assumed they would agree was unintentional collateral damage. Not only did they refuse to take his IP address off the list, they were spiteful enough to contact my dad's ISP and register a complaint about his "unauthorized" server!
It goes without saying that my dad is not a spammer. And we both see to it that his system is properly maintained and configured. All we ever wanted was to exchange email email without depending on his ISP's slow and unreliable mail servers.
MAPS and other spam vigilantes are actually far worse than the spammers they claim to be fighting. No spammer has never prevented me from sending or receiving wanted email. MAPS often does so, and they have to go away. Since they're unlikely to do so on their own accord, our only alternative is to educate the ISPs to not use their services. Openly boycot any ISP who subscribes to the MAPS, and tell them we simply don't want their "help" in blocking email. Patronize the more enlightened ISPs that give you a choice as to how or whether your mail will be spam-filtered.
I don't think it would be quite as easy for the ISPs to ding third party VoIP providers as Cringely makes it sound.
Sure, an ISP can block the ports used by SIP, or the IP addresses used by Vonage and other third-party VoIP servers. That would certainly do the job. But then the FCC would quickly come down on them like a ton of bricks for such a blatantly anticompetitive action, just as they hit Madison River Communications a few weeks ago.
I'll assume that the third party VoIP provider is clueful, so they have fast, redundant paths to all the Tier 1 backbones. This means it would be up to the ISP to somehow delay third-party VoIP packets between his own customers and the backbones.
Simply giving priority to an ISP's own VoIP packets is not such a bad thing. In many cases this involves diverting them to dedicated links or backbones, leaving the normal backbone routes unaffected. But even if they rely on the general purpose backbones for connectivity to their own VoIP gateways, then giving priority to their own VoIP traffic delays other traffic only when there's too much total traffic in the first place. Routers don't gratuitously delay a packet just because it has a low priority level. They'll delay a packet only when link demand exceeds supply and other packets have a higher priority.
So unless the ISP's router deliberately discriminates between third-party VoIP traffic and "ordinary" data traffic -- and that could be detected fairly easily -- I think it would be difficult to make their network unusable for third-party VoIP without doing the same thing to ordinary data traffic. The delay variance for all traffic would have to be quite high. Then all of their customers, not just those using third-party VoIP, would complain and/or switch to their competitors.
It's clear that the best way to protect against this sort of thing is true competition in the access market. But lacking that, I think even a bare minimum of regulation, combined with eternal vigilance on the part of the end users, should keep the ISPs from getting away with too many shenanigans.
1. The fleet was small and expensive to maintain only because GM deliberately kept it small and expensive to maintain. They almost hand-built only a few hundred vehicles in each of two model years (1997 and 1999). While they claimed they could resume production if demand warranted, it became quickly clear they had no intention of doing so. Their existing stock quickly sold out, long waiting lists formed, and then nothing ever happened.
2. What liability issues? If anything, electric cars are safer than gasoline cars. You're not driving around with a good-sized bomb's worth of volatile, toxic, and extremely flammable liquid fuel that can spill out after an accident. Gasoline vehicles catch fire all the time, and you rarely read about it. A few EV1s were involved in accidents; they performed no worse than comparable gasoline cars.
3. The range myth is the single biggest red herring with the EV. Everyboy just seems to know that a "practical" EV must have a range of at least 300-400 miles per charge. Everybody, that is, except those of us who actually drove EVs every day in real life. Marketing studies showed early on that while not everyone's needs are met with a car having 100 miles of range per charge, most of the population drives considerably fewer than 100 miles in their daily routines. Yeah, that still means you have to recharge the car every day, but you do it where and when your car would be parked at home or at work anyway. I found that considerably more practical than having to go out of my way to a gas station every week or so. Every morning and every evening I drove away from home or work with a full charge.
Nothing says your EV can be your only car. Most families already have more than one car. On the rare occasion that you need to take a long road trip, you leave your EV at home and drive your gasoline car. Mine otherwise sat undriven for weeks.
And having said all that, prototype EVs with lithium-ion batteries were just starting to appear that yielded 300 miles of range per charge at the same capital cost as lead acid. (See AC Propulsion.)
4. Simply untrue. Operating costs of EVs are far lower than gasoline vehicles. That cost consists almost entirely of electricity, as very little maintenance is needed, and even in California at the height of the electricity crunch it cost considerably less per mile than gasoline. Routine maintenance for the EV1 consisted of rotating the tires every 5,000 miles and inspecting the brakes and high voltage wiring. My Saturn shop always did it in about 10 minutes. NiMH batteries had estimated lifetimes of 100,000 miles, and except for a few infant mortalities I think they demonstrated those numbers were reasonable.
Slashdot Mirror
Comets tend to have oddball orbits, often highly inclined to the ecliptic, that can make them very hard to reach because of the required delta-V. Tempel's inclination is only 10 degrees, which is probably one of the reasons it was chosen for this mission.
In any event, it's far easier and cheaper to crash into a given celestial body than it is to rendezvous and land on it. And in this case, an impact was highly desirable since it represented an easy way to expose and study the material deep below the surface.
Robotic exploration of objects in the solar system generally follows a pattern of first flying by an object, then "hard" landings (impacts that destroy the spacecraft), then orbiting it, and then landing on it. That's exactly how the moon was explored; I'm old enough to remember the Ranger series of spacecraft that hit the moon in the mid 1960s, leading the way to Lunar Orbiter, Surveyor (robotic soft landings) and eventually Apollo.
If the body has an atmosphere, then air drag (heatshields and parachutes) can be used to convert a hard landing into a soft one, but the moon, comets and asteroids don't have atmospheres.
I expect somebody someday will figure out the intricate gravity assists that would be required to rendezvous with a carefully chosen comet and match its velocity. But you have to crawl before you can walk, and Deep Impact did an excellent job of that. Remember also that Deep Impact is a Discovery mission, which means it has to make the most of every dollar spent. It very clearly did that too.
My position on smart vs dumb peripheral cards is really limited to network interfaces. There, the protocol operations to be performed on every data byte are way down in the noise compared to the operations to be performed on that same data in the application.
Video controllers are an entirely different story since a lot of very specialized processing has to be done to produce every tiny pixel of image data. There it makes a lot of sense to have specialized graphic engines, especially since there is a large gaming market to amortize the non-recurring engineering costs.
The same can be said of modems since many specialized DSP instructions also have to be executed to send or receive a byte of data. However, dialup modems operate at such slow speeds (and, thanks to Claude Shannon, will never operate faster than 64kb/s) that even these complex operations can be done in real time on modern host CPUs with most of the CPU left over. And all the latest general purpose CPUs implement a pretty powerful DSP engine in the form of MMX, SSE, SSE2, SSE3 and Altivec. So I think Linux's problems with the Winmodem have more to do with the inability to implement standard dialup modem functionality in open source software because of patents than any fundamental technical reasons. Also, there is (still) a large enough market for dialup modems that the NRE can be easily amortized. I.e., external modems are dirt cheap, so why not just use them?
Yes, you're right that there have been (and probably will continue to be) short windows of opportunity for so-called "smart" (and expensive) network cards, most often in legacy systems that can't easily be replaced, but in the long run I think Van Jacobson's position has already been adequately vindicated. You just can't compete with mass produced general purpose CPUs when you're executing a network stack.
For those operations that do involve the host, I can't think of any that require a lot of complex code to be executed on each and every data packet. For example, setting a VLAN or QoS value just involves copying a constant into a packet header; that's trivial since you're already copying a whole bunch of other header constants (IP addresses, port numbers, etc).
The one thing you do want on a network card is lots and lots of buffering so the host can take its time to service it and transfer lots of data in each servicing operation.
The arguments for hardware RAID seem to have to do more with functionality than performance. For example, you can't boot off a software RAID-5 array, but you can with a hardware controller. (I get around this on my own system by making the boot volume RAID-1 and having a separate RAID-5 array for large, static databases.)
Also, I've had some system lockups when a drive in a software RAID array fails, probably because the controller and/or its driver got confused. This isn't really a strong argument for a hardware RAID controller (the non-RAID disk controller and/or driver simply ought to be made more robust) but a hardware RAID controller is probably more likely to tolerate a drive failure without hanging since tolerating drive failures is precisely what a RAID controller is designed to do.
If there's a problem with RAID, in software or hardware, it's that there are too many single points of failure in most inexpensive RAID boxes as they're actually constructed. Unless you buy a expensive box with dual power supplies, the power supply is one of them. So are the CPU, memory and software of the host machine to which the RAID array is attached. I've thought about building a "network RAID" where I construct RAID arrays out of network file systems exported by physically separated servers over gigabit Ethernet. No matter how any one PC/controller/drive combination fails, the client machine should recover. Problem is, even that scheme is vulnerable to a failure of the client machine. So RAID isn't the only answer, and higher level data replication schemes are needed to complement it.
You mentioned "fast path" but you obviously didn't understand what it meant or why it was important. Timeout code, connection establishment, out-of-order reassembly etc, etc, are all irrelevant to performance because they're rare events. You only have to optimize the most common case, which is that the TCP packet you're processing is in sequence and has only the ACK bit set (and maybe the PSH bit, though most OSes can just ignore it).
That's what the fast path code handles, and that's precisely why VJ could do it in only 30 instructions! You're just wasting your time optimizing the stuff that rarely happens; that's basic software engineering.
The only other protocol operation that takes any significant time is the checksum calculation, and here the memory access time dominates. So VJ's answer to that was to build a memory copy operation (which you need anyway) that simultaneously computes the checksum in a single memory access. Simple, and no special hardware is needed.
When I did my TCP/IP stack for the PC in the mid 1980s, I learned a very simple lesson about interrupt handling: do as little at interrupt time as possible, and do it as seldom as possible. Device hardware, and by extension their interrupt handlers, really have only one function: to buy time until the operating system and upper layers can get around to you. The device and/or interrupt handler (ideally the former) should therefore be able to run as long as possible without host intervention. That means having as much memory as possible to buffer incoming data to ensure that nothing gets lost.
This approach adapts nicely. When the host CPU is fast or lightly loaded and/or the input data rate is low, the host can easily service an interrupt on every packet. But when the data rate is high and/or the CPU is slow or heavily loaded, multiple packets are handled on each interrupt, thus cutting interrupt overhead per packet precisely when you need it.
The same approach has been long used in simple devices like serial ports; the National Semiconductor 16550 UART, for example.
User-space TCP/IP is hardly new. I did it in 1986 on the IBM PC, mainly because there was no protected-mode OS available for the 8088 and 80286 at that time.
I still think that as CPUs get arbitrarily fast that the conventional network protocol architectures will work just fine as long as the Ethernet hardware can actually run at full network speed and have halfway decent host interfaces.
As my former landlord used to say, if Beethoven doesn't move you, then you must be dead.
Some people seem to forget that the Constitution -- including the Bill of Rights -- is the supreme law of the land, and judges have a duty, as established in Marbury v. Madison to strike down unconstitutional laws and abuses of executive power. It's that simple.
"Smart" network cards are one of those bad ideas that keep coming back from the grave, because computer science seems to lose its collective memory every decade or so.
Fifteen years ago, Van Jacobsen did a wonderful presentation at SIGCOMM 1990 on just why they were such a bad idea. The reason is very simple. A modern, well-tuned and optimized TCP/IP stack can process a packet with only about 20 instructions on average. Very few "smart" controller cards have host interfaces that can be spoken to with so few instructions! The switch to and from kernel context will usually cost you more than TCP/IP.
Not only that, but the coprocessor on the "smart" controller card inevitably ends up being considerably slower than the host CPU, because typical host CPUs are made in much larger quantities, enjoy large economies of scale, and are updated frequently. So you often have the absurd situation of a blazingly fast and modern host CPU twiddling its thumbs waiting for some piss-poor slow CPU on a "smart" controller to execute a protocol handler that could have been done on the host with fewer instructions than it takes just to move a packet to or from the "smart" card.
And if that weren't enough, rarely do these "smart" network controllers come with open source firmware. Usually the company that makes them obsoletes them quickly (because they don't sell well) and/or goes out of business, and you're left with a very expensive paperweight.
Since his talk, Ethernet interfaces have totally obsoleted "smart" network cards. They now come with lots of internal buffering to avoid losing packets when interrupt latencies are high, and they take relatively few instructions per byte of user data moved. What more could you want?
But I agree the best way to solve the problem is to bring your own computer.
Close to the ground, the atmosphere absorbs pretty much everything. That's why fireballs form at low altitudes but not in space. Microseconds after a bomb explodes, its vaporized residue is so hot that its blackbody radiation peaks in the soft X-ray region. The lower atmosphere is actually fairly opaque to soft X-rays, so it absorbs most of this energy and rapidly heats up, forming the characteristic nuclear fireball. Outside the atmosphere, there's nothing to stop this X-radiation and the associated charged particles, so they can be trapped in the earth's magnetic field lines.
This was all discovered when the US conducted a series of exoatmospheric tests (i.e., tests out of the atmosphere) in the vicinity of Johnston Island in the Pacific in the early 1960s. They literally launched real nuclear bombs on real missiles. (Imagine doing that today!)
This was also how the whole EMP phenomenon was discovered, and quite by accident -- some of the tests induced widespread electrical damage in Hawaii, quite some distance away. It was kept a secret for over a decade.
Not only that, much of the basic information about the nuclear fuel cycle and nuclear weapons was openly published by the US decades ago in the book The Effects of Nuclear Weapons.
But if they're running Windows, I tell them they're on their own. First of all, a typical Windows machine has far more than its share of major problems. Worms, viruses and spyware are almost entirely Windows afflictions, and most people just won't pay attention to my repeated lectures on proper network hygiene until it's too late.
Second, I find it quite painful to debug a Windows machine even when it's in front of me. Time really starts to drag after the first ten or twenty reboots. Trying to do it over the phone from thousands of miles away, unable to see the screen or type some complicated command without having to spell it out verbally several times, is just beyond my patience. VNC is sometimes useful, but it's painfully slow even over cable modems or DSL, and you still need local human intervention whenever a reboot is needed -- which is all too frequent with Windows.
Well, I had Rhapsody for perhaps six months. A few days ago, when I realized I was paying for something I hadn't used at all for a few months, I cancelled. To do that, you have to call and talk to a human. This not only deters you from canceling, they get one last chance to talk you out of it. The droid I got, apparently in India, was very clearly programmed to do this.
Rhapsody's model is admittedly interesting: unlimited online listening to anything in their library for a flat monthly fee. That does fill a different niche not covered by the iTunes model of selling downloads of individual songs, and it doesn't cost you anything to explore music and artists you haven't heard before.
But aside from being tethered to a network connection to be able to listen to anything, the Rhapsody implementation of this model has two fatal flaws. First, you have to use their own proprietary user client, and it's only available for Windows. Naturally, I avoid Windows like the plague.
Second, their library is, as a Talosian might say, "shockingly limited". It seems that every time I'd look for a particular artist, either they didn't have anything at all, or only one or two albums. Sometimes I'd find an album only to discover that Rhapsody got rights to only a couple of songs, with the rest missing.
I still think the best way to build a usable personal online music collection is to buy the CDs you want, rip them onto your own server, and put the CDs into storage as an offsite backup. Oh, and if you want to explore new and obscure artists, patronize the more enlightened and progressive labels like Magnatune.
If you were, then please support, with reason and logic, the argument that is apparently being seriously made by some in this discussion that the second amendment is intended to enable ordinary, individual Americans with a few small arms each -- or even a state militia -- to rise up and violently overthrow the entire federal government if it ever gets too far out of hand.
Even without the experience of the US Civil War to show us what actually happened when such a thing was once tried, it would be utterly impossible for any rational person to take such a position seriously.
My point is very simple: those who insist that we all need firearms to "keep the federal government in line" are, by any rational analysis, clearly living in a fantasy universe. I'm no psychologist, but it certainly seems that the ownership of small firearms is often associated with a highly exaggerated sense of self-confidence and personal political empowerment that can border on the psychotic. The less influential the person is in their everyday life, the stronger these exaggerated feelings seem to be.
But I guess you'd much rather live in your romantic gun-nut fantasy world.
Again, these things have to be carefully constructed to load up everything. It's almost impossible in any real application -- something always seems to bottleneck well before everything else -- and with the architectural complexities of today's CPUs, probably only a little easier to do in a test designed merely to load everything up without accomplishing any useful work.
It used to be that if you had the "wrong" (physical) address, or belonged to the "wrong" religion, or had the "wrong" skin color, many businesses wouldn't even talk to you. You weren't even given the chance to prove yourself. That kind of discrimination has long been illegal in the US, but it's still legal to openly discriminate on the basis of your IP address, as opposed to your actual behavior (whether or not you spam). That's why the word "ghetto" is perfectly appropriate.
If you have the option, you could switch to a more enlightened ISP that doesn't treat you like a moronic criminal. I eventually abandoned both Road Runner and SBC DSL and signed up with Speakeasy DSL. While their services are priced at a premium, I think they're fully worth it. I wanted several static IP addresses anyway, and when you price static IP addresses from a typical cable modem or telco DSL provider Speakeasy doesn't look so expensive. Since switching, I've never had any email rejected for having an IP address on a blacklist.
And, as icing on the cake, Speakeasy promises to never block any ports -- try getting a guarantee like that out of Road Runner or SBC! So, given a choice, I decided to give my money to the more clueful outfit.
Many ISPs do things wrong, but many others do it right, and they deserve to be rewarded with your business. Instead of subscribing to MAPS or other ill-conceived IP blocking lists, a good ISP will run Spam Assassin or a similar content analysis tool and merely divert anything marked as spam to a separate IMAP "Junk" folder where you can still read it to avoid false positives (or if you're just feeling a little masochistic). And you can disable even that mechanism if you don't want it. Speakeasy works this way, and they don't seem to subscribe to the MAPS DUL either. (But I still prefer to run my own mail servers.)
I bet many Internet users still don't know that they don't have to use the mail servers provided by whoever provides them with IP dialtone. They can get their mail service from somebody else. It's especially important that everyone on DSL or a cable modem knows this, as the lack of meaningful competition in the retail broadband market tends to lead to some pretty arrogant email server policies.
Excuse me, but how exactly does one equate suspected small-scale counterfeiting with hijacking airliners, flying them into buildings and killing thousands of people?
If this signifies anything, it's how, in the post-9/11 world, American society has gotten so moronic, brow-beaten and petrified that cops seriously expect us to buy such a flimsy excuse for their Gestapo tactics.
By the way, I went to grade school in Cockeysville, MD. My parents live only a few miles away. I'll make sure they avoid that particular store.
Modern CPUs are complicated beasts, with multiple execution units, deep pipelines and big caches. And they're connected to big external memories and disk drive arrays. If you want to stress-test the cooling system, then you need code that keeps all the execution units and all the pipelines and the caches and main memory and the disk array all going full blast. That's not as easy as it sounds. Intel has mentioned various test programs that they use when thermally testing their CPUs, but I don't know that they've ever released them. Perhaps they're afraid they'd might cause damage, and they'd have to deal with a lot of irate customers.
A while ago, when the MAPS DUL virus first began to spread, my dad began to have problems delivering his mail from his Linux system on a cable modem. So I contacted MAPS and told them about what I naively assumed they would agree was unintentional collateral damage. Not only did they refuse to take his IP address off the list, they were spiteful enough to contact my dad's ISP and register a complaint about his "unauthorized" server!
It goes without saying that my dad is not a spammer. And we both see to it that his system is properly maintained and configured. All we ever wanted was to exchange email email without depending on his ISP's slow and unreliable mail servers.
MAPS and other spam vigilantes are actually far worse than the spammers they claim to be fighting. No spammer has never prevented me from sending or receiving wanted email. MAPS often does so, and they have to go away. Since they're unlikely to do so on their own accord, our only alternative is to educate the ISPs to not use their services. Openly boycot any ISP who subscribes to the MAPS, and tell them we simply don't want their "help" in blocking email. Patronize the more enlightened ISPs that give you a choice as to how or whether your mail will be spam-filtered.
Sure, an ISP can block the ports used by SIP, or the IP addresses used by Vonage and other third-party VoIP servers. That would certainly do the job. But then the FCC would quickly come down on them like a ton of bricks for such a blatantly anticompetitive action, just as they hit Madison River Communications a few weeks ago.
I'll assume that the third party VoIP provider is clueful, so they have fast, redundant paths to all the Tier 1 backbones. This means it would be up to the ISP to somehow delay third-party VoIP packets between his own customers and the backbones.
Simply giving priority to an ISP's own VoIP packets is not such a bad thing. In many cases this involves diverting them to dedicated links or backbones, leaving the normal backbone routes unaffected. But even if they rely on the general purpose backbones for connectivity to their own VoIP gateways, then giving priority to their own VoIP traffic delays other traffic only when there's too much total traffic in the first place. Routers don't gratuitously delay a packet just because it has a low priority level. They'll delay a packet only when link demand exceeds supply and other packets have a higher priority.
So unless the ISP's router deliberately discriminates between third-party VoIP traffic and "ordinary" data traffic -- and that could be detected fairly easily -- I think it would be difficult to make their network unusable for third-party VoIP without doing the same thing to ordinary data traffic. The delay variance for all traffic would have to be quite high. Then all of their customers, not just those using third-party VoIP, would complain and/or switch to their competitors.
It's clear that the best way to protect against this sort of thing is true competition in the access market. But lacking that, I think even a bare minimum of regulation, combined with eternal vigilance on the part of the end users, should keep the ISPs from getting away with too many shenanigans.
1. The fleet was small and expensive to maintain only because GM deliberately kept it small and expensive to maintain. They almost hand-built only a few hundred vehicles in each of two model years (1997 and 1999). While they claimed they could resume production if demand warranted, it became quickly clear they had no intention of doing so. Their existing stock quickly sold out, long waiting lists formed, and then nothing ever happened.
2. What liability issues? If anything, electric cars are safer than gasoline cars. You're not driving around with a good-sized bomb's worth of volatile, toxic, and extremely flammable liquid fuel that can spill out after an accident. Gasoline vehicles catch fire all the time, and you rarely read about it. A few EV1s were involved in accidents; they performed no worse than comparable gasoline cars.
3. The range myth is the single biggest red herring with the EV. Everyboy just seems to know that a "practical" EV must have a range of at least 300-400 miles per charge. Everybody, that is, except those of us who actually drove EVs every day in real life. Marketing studies showed early on that while not everyone's needs are met with a car having 100 miles of range per charge, most of the population drives considerably fewer than 100 miles in their daily routines. Yeah, that still means you have to recharge the car every day, but you do it where and when your car would be parked at home or at work anyway. I found that considerably more practical than having to go out of my way to a gas station every week or so. Every morning and every evening I drove away from home or work with a full charge.
Nothing says your EV can be your only car. Most families already have more than one car. On the rare occasion that you need to take a long road trip, you leave your EV at home and drive your gasoline car. Mine otherwise sat undriven for weeks.
And having said all that, prototype EVs with lithium-ion batteries were just starting to appear that yielded 300 miles of range per charge at the same capital cost as lead acid. (See AC Propulsion.)
4. Simply untrue. Operating costs of EVs are far lower than gasoline vehicles. That cost consists almost entirely of electricity, as very little maintenance is needed, and even in California at the height of the electricity crunch it cost considerably less per mile than gasoline. Routine maintenance for the EV1 consisted of rotating the tires every 5,000 miles and inspecting the brakes and high voltage wiring. My Saturn shop always did it in about 10 minutes. NiMH batteries had estimated lifetimes of 100,000 miles, and except for a few infant mortalities I think they demonstrated those numbers were reasonable.