'Killer' Network Card Actually Reduces Latency
fatduck writes "HardOCP has published a review of the KillerNIC network card from Bigfoot Networks. The piece examines benchmarks of the product in online gaming and a number of user experiences. The product features a 'Network Processing Unit' or NPU, among other acronyms, which promise to drastically reduce latency in online games. Too good to be true? The card also sports a hefty price tag of $250." From the article: "The Killer NIC does exactly what it is advertised to do. It will lower your pings and very likely give you marginally better framerates in real world gaming scenarios. The Killer NIC is not for everyone as it is extremely expensive in this day and age of "free" onboard NICs. There are very likely other upgrades you can make to your computer for the same investment that will give you more in return. Some gamers will see a benefit while others do not. Hardcore deathmatchers are likely to feel the Killer NIC advantages while the middle-of-the road player will not be fine tuned enough to benefit from the experience. Certainly though, the hardcore online gamer is exactly who this product is targeted at."
But the only real concern in making a killer NIC is keeping all the processing off of the CPU and bus. If the CPU/MB can shuffle packets at and from the NIC at the speed of the data bus, then it can't get much faster unless you want to offload protocols to the NIC etc.
A killer NIC? LOL what a phrase... Aren't there several of these Nicolas guys in jail already? right next to the killer Bobs and killer Joes.... sheesh
Support NYCountryLawyer RIAA vs People
What's more interesting is that the card is actually a single-board computer with PowerPC processor and 64 MB of RAM!
Most network chips these days have checksum and TCP layer offloading.
This article is pure BS. If anything, this card probably increases the latency because of the additional layer of software involved on the card itself.
It's not like a computer sends you some data and the network card is immediately able to reply. To formulate a response, it probably needs data from the CPU, e.g. about your position, your health, or whatever it is that you need to transfer back and forth in a game.
An ICMP echo reply is totally different though. Unless you have a weird firewall setup going on, it's pretty much just safe to send out the echo response as soon as you get the echo request. So in this situation, you could peg the main CPU and then have the NIC doing the mind numbingly boring task of sending out echo responses without going through the CPU, and in this case you might see a latency improvement of a few milliseconds. But in general the CPU is going to have to do some processing and formulate the correct response anyway, so having a "smart" network card doesn't help.
#include ".signature"
Can you list a few examples, preferably with datasheets?
Here are two datapoints. A $10 PCI NIC, and a $100 mobo I bought lately (with an integrated NIC) feature checksum offloading. They are both GBit, so I guess you get that for free on any GBit NIC nowadays.
Other than that, I really don't see how a NIC can decrease latencies. The latency of that first hop off your computer is below 1ms anyways.
I recall reading a technical overview of this card a few months back. Apparently, it's running Linux of some sort on its host processor. So, how awesome would it be if some remote vulnerability affected the card, allowing someone to implant a rootkit on the device? Now all of your raw network traffic can be captured, your machine can be joined to a botnet, etc. and you'll probably have absolutely no way of knowing about it.
Granted, most people that will use this NIC (the few who do) probably aren't communicating a whole lot of sensitive data. Still, the whole thing just looks like a disaster waiting to happen.
hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?
There is hardware, software and internet induced latency. The best a NIC can do is improve hardware induced latency. However that is the least of it. The main thing to worry about is how to reduce the amount of time the software spends processing packet information. There's little you can do about internet latency. Every ms spent rendering the screen is an ms that causes packets to get backed up.
I wrote a client/server app that had to deal with a rediculous amount of information about hundreds of entities moving around the screen. I found the most efficient way to keep messages being processed was to lock the framerate at 30fps and drop frames if that rate could not be maintained. When a frame is dropped the only thing that doesn't happen is that a frame doesn't get rendered. Suddenly the main look is running at thousands of iterations per second clearing out messages from the queue and processing them because it doesn't have to render a frame for a few ms. 30 ms of focused message processing will reduce lag significantly.
If I put the emphasis on rendering frames per second the message queue would back up and eventually the app would crash because the buffer was filling up faster than it could empty it.
Maybe instead of focusing on rendered frames per second, people should be putting more emphasis on iterations per second and getting those messages processed. At 100 fps that give 10ms to render a frame, process all the waiting messages, and perform game logic. Good luck with that. 10ms is barely enough time to just render a frame.
I bet gamers would have a better on-line experience if they'd lock the rendered frame rate to free up more processing power to handle packets. However, I don't think any modern games allow that. Locking the frame rate typically means locking the entire game processing loop and that's stupid and unnecesary. It is possible to not render a frame but still do everything else.
Work Safe Porn
Back in the heyday of Quake II, me and a friend who made the Quake Superheroes and Quake Superheroes II mods put in a superpower that would (ostensibly) reduce your ping time, using some kind of technobabble handwaving. Everyone was convinced that it worked, too, because when you used it, the ping times listed in the player screen would indeed be lower for you!
:) I don't know if anyone ever caught on, but it was funny watching people argue over whether you should take a "real" superpower like flying or teleportation, or try to improve your ping :)
What almost no one knew was that the mod API allowed you to simply edit those values on the fly.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
In Linux, type "ethtool -k eth0" to see if your card does it. Many systems I use have onboard Intel controllers and they all support it.
Network-layer, Deering-model multicast is never going to happen. It has nothing to do with ISP business models and everything to do with simple technical feasibility:
There isn't even an agreement among protocol designers about what multicast is supposed to accomplish anymore. BitTorrent is taking a lot of the steam out of it; so are unicast solutions to streaming media that prove that multicast is inessential. Multicast gets used tactically inside of some networks, but if you're on the same LAN as your other players, the network is already plenty fast for gaming even with unicast.
Forget about multicast.
Some people are used to writing for the 1.8 inch columns of typical newspaper layout, which does use more paragraph breaks than copy elsewhere because 25 to 35 words fill an inch. The 25em column width of Slashdot's comment entry area before the CSS makeover encouraged similar behavior.