'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."

Comments

correct me if I'm wrong...

[zappepcs]

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

Re:correct me if I'm wrong...

[Anonymous Coward]

You're wrong on somethings..

1) bunch of blah and stuff about memory. Since your explanation is memory->application->CPU->kernel memory->protocol stack->CPU memory->NIC driver->bus (basically, it was hard to follow with all the fud), you obviously have no idea how an OS works (I can't think of any modern, common OS's that have such a path). None of this happens as you describe, they are all parts, but the flow is nothing like you describe. See LKML for 2.6 on network programming if you want to see how this works on Linux, which is relatively transparent http://lkml.org/lkml/2005/5/17/78 also you can look at BSD.

2) The PCI Bus is irrelevant for gigabit ethernet (which is about the only network controller commonly in production, legacy stuff like 10/100 is more common- but is almost out of production) and for faster types (10GE or myrinet or infiniband), totally irrelevant. The 32bit PCI bus limit is about at gigabit speeds, and it is shared with everything else on the PCI bus- therefore suboptimal:

http://www.codepedia.com/1/PCI+BUS

PCI-X and gigabit controllers directly off the Controller chipsets is how networking is mostly done now.

3) blah blah, network slower than computers (ridiculous depends on the network and computer exclusively- in consumer computers it swings in a pendulum, when 100Mb came out most of the stuff in the PC couldn't keep up- it was faster to install over the network than from CD ROM because the CD drive was slower, it is going through that again with gigabit- most consumer PCs disk systems can't even approach filling gigabit). Then some conflation about what QoS, and policing can do... QoS only helps if the pipe is full:

http://en.wikipedia.org/wiki/Quality_of_service

or

http://www.cisco.com/univercd/cc/td/doc/cisintwk/i to_doc/qos.htm

4) ISP and stupidity. ISP's may or may not be stupid. They are driven by market forces and the market force is people don't currently want to pay for a tiered service class internet. When they do, they will offer it. Technically it has been feasible for years. Read NANOG mailing list, you will see they are not stupid, but instead are in a low margin business.

5) blah blah blah, microsecond delay, destinguishable from millisecond via a consumer computer with a common OS by a person?? hahahahah. not without a measuring device. It is possible with enough training (I suppose musicians can). Since you can buy commodity off the shelf lan gear that will turn in sub millisecond delay, I don't think spending the extra-money on low microsecond delay will help

Bunch of pseudo-science modded up on Slash again...

Oh and Jumbo FRAMES are commonly 9000B in size (although the term can refer to anything bigger than 1500B:

http://sd.wareonearth.com/~phil/net/jumbo/

or 9K on cisco:

http://www.cisco.com/warp/public/473/148.html

Lowering pings

[Dirtside]

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!

What almost no one knew was that the mod API allowed you to simply edit those values on the fly. :) 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 :)

ISPs aren't "bloody stupid" about multicast

[tqbf]

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:

• Routing table management is an issue even in unicast (which is why I can't get an ASN and advertise a /27, even though that would be incredibly convenient and useful). But multicast addresses individual pieces of content --- video streams, game rooms, chat channels --- and requires diverse, interdomain routing for each. This is akin to demanding BGP advertisements for every popular page on the web.
• The protocols for interdomain routing barely exist and have never been proven; no production network relies on them. Even interior routing for multicast is in flux; just a few years ago, the model changed to single-sender, which simplifies routing but changes the service model so only one source can efficiently send data.
• Forward error correction may work for streaming media, but it's a disaster for tiny, discrete updates, and outside of FEC there are no proven ideas in multicast reliability. "Scaleable Reliable Multicast" isn't a protocol, it's a position paper from the early '90s. The well-known current multicast reliability protocols all require infrastructure support: strategically deployed "repair" servers.

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.