Network Card for Gamers - Uses Linux to Reduce Lag

Cujo writes "The folks at GDHardare have an interview with Bigfoot Networks discussing the pending release of their Killer Network Card which is said to greatly reduce in-game latency. According to the Interview, this card uses a Linux-based subsystem to do its magic."

Pricey

[HeWhoRoams]

Pre order cost is $280. You'll see a better FPS increase spending that on a graphics card, RAM, or some groceries for 6 months.

Re:Yes.

[Beuno]

I agree, although, also from TFA:

Many network products today claim to 'offload' network calculations (like checksum, tcp segmentation, etc.). Those technologies are usually only for TCP/IP networking (which most games that Hardcore Gamers play don't use). Those technologies are also incomplete as they still go through multiple layers of the gaming network stack to eventually get data to the game. With Killer, we completely bypass your gaming PC's operating system and go directly from our card to the game. Our card automatically handles things like IP Reassembly, UDP/IP checksum, UDP and IP header verification and stripping, etc, etc, etc. By bypassing your gaming PC's operating system and allowing Killer to handle everything, Killer can achieve levels of gaming network performance well beyond the offloading features claimed by other consumer networking products (NICs or onboard chipsets).

Re:Oh, Geeky!

[harrkev]

But... if you read the specs, you have to run Windows in order to use it. It uses Linux, but no Linux drivers...

Re:Huh?

[fm6]

If you go to the web site, and read the white paper, you'll see that they're mainly thinking in terms of LAN usage.

Re:Yes.

[Jherek Carnelian]

Even games that arent exactly TCP are typically a reliable messaging system on top of UDP that pretty much mimics TCP.

With that said, I cant see how this network card could reduce your latency by more than 1ms or 2ms round trip.

Given the constraints - TCP and various homegrown reliable protocols on top of UDP, it isn't too hard to come up with some options to improve latency. But they all involve violating the RFCs.

First you have to wrap head around one important factor that can absolutely kill latency for any transport with guaranteed delivery -- packet loss. Packet loss means you have to discover what packets were lost and then retransmit them - those two steps can easily introduce delays on the order of seconds.

So one trick would be to pre-send the retransmits. Send duplicate packets spaced apart by a few miliseconds. If the other end receives multiple copies of the same packet, it will silently discard any extras - but if one copy gets lost en route, the other packet might still make it through, thus eliminating the whole timeout/retransmit cycle. It should be possible to do this for both TCP and UDP.

However, doing something like that is very unfriendly because it wastes resources. The primary reason packets get lost en route is because of bandwidth saturation. So, if you double or triple your traffic you are just making the problem worse. If you are the only one out of thousands who "breaks the rules" you will probably get away with it and probably even benefit from it since packet loss will be a somewhat even distribution among all traffic, so chances are if one of your packets gets dropped the copy won't get dropped - instead someone else's packet gets dropped.

But if a significant minority of users were to do the same thing, it would probably result in a complete collapse of any usuable bandwidth. Which is exactly the kind of thing I would expect a bunch of MBA's to come up with.

Re:Is this really needed?

[dorath]

They also claim to increase your FPS by offloading other apps onto the NIC, namely a music player but apparently also file sharing. With a mic jack one would think it could also run voice communication software.

Being at work, I'm not in a position to check FPS while running just the game vs the game, music, and chat. :-(

I'm placing this one in close proximity to the "Snake oil" bin.

Re:drivers on cards?

[snowgirl]

1) Make/adopt an industry standard CPU emulation for booting CPU-independant BIOSes, p.e. using some kind of Java-like CPU emulation (like the way the PPC comunity uses PCI boards with x86 BIOSes).
2) Make/adopt an industry standard BIOS boot protocol.

It exists, it's called OpenFirmware by Apple, and both Apple and Sun used it. Of course, since PCs didn't use it, the industry standard died and was replaced by a de facto standard, which is arch dependent.

Also, a) ROM code implies adopting some sort of code execution (ISA dependant, p.e. x86/PPC/MIPS/etc), CPU related.

Devices already have a ROM code in them, which contains execution stuff to get the card into a working order. All cards have this. On an x86 PC, this code is in x86 machine code, while for PowerPC CHRP and Sun Solaris systems it was in FCode (a Forth bytecode, which is extremely simple to write a virtual machine for).

But again, as always, the existing legacy support of the PC destroys yet another better idea.

Re:kinda cool

[Percy_Blakeney]

Linux has had TCP window scaling for a long time. The recent "bugginess" with it came from a change to its default settings that caused issues with a non-compliant device on the Internet. Read about it at KernelTrap [kerneltrap.org].

software alternative

[Intocabile]

Cfosspeed is a great little program for Windows XP+ that gives an incredible ammount of control over quality of service. It detects a large number of standard protocols (http,ftp,nntp,dns...) and can set priority on a per program basis for games, voip and p2p. I reccomend it especially if you have an ADSL connection prone to a high ping while downloading. You can setup cfosspeed to prioritize your connection for low ping or high bandwidth. Unfortunately it doesn't work as intended if you have multiple computers on a router because it shapes the traffic independent of other computers, but the developers are working to add multi computer support.

I've used it for almost 6 months and its given me the highest most stable download speeds I've ever seen on my DSL. My pings while downloading are almost as good as they can be. It's also very lean on CPU overhead.

here's the developers explanation on how it works
http://www.cfos.de/traffic_shaping/traffic_shaping _e.htm [www.cfos.de]

Re:Huh?

[gallwapa]

BTW, is there actually a practical use for Wake-on-LAN (i.e. a real-world scenario for it)

I work for a school district with a sub-standard WAN (READ: 1 T1 link for a school with 500 computers with internet access) and no WSUS or patch management distribution servers. Wake on LAN, have 45 sites with 100-500 computers connect back to our ...*shudder* singular *shudder* SUS server...shut down.

Or, wake on lan, re-image machines with Novell Zenworks, shut down
Or, wake on lan, to unfreeze machines from DeepFreeze
or, wake on lan to virus scan instead of when users are at work

The possibilities are endless :)

The patent...

[STratoHAKster]

...for this so-called so-called gaming card is readable here [freshpatents.com]. I ain't buying it.

Re:So it's a QoS Network Card?

[slashflood]

my most favorite audiophile product is a wooden knob that costs $500

Here it is [referenceaudiomods.com]! You can also spend 7000 bucks for a volume control [referenceaudiomods.com] - a must have.

Tytus (Bigfoot Networks) Responds

[Tytus_Bigfoot]

Hey everyone, I am the inventor of the Killer NIC. I will not try to hijack your thread, so this will be my only post. Thanks for the interest in our Killer Network Card. It has been my personal vision for years. A lot of very good questions have been raised here, and I think a lot of them are answered in our FAQ here: http://www.bigfootnetworks.com/FrequentlyAskedQues tions.aspx [bigfootnetworks.com] . If there are still questions, I would love to try to answer them at our sponsored community site: http://www.endlagnow.org/ELNForums/ [endlagnow.org] Thanks, Tytus

Re:Is it credible?

[Andy Dodd]

Most such "abuses" become useless/irrelevant with any situation these cards would be put into. i.e. in most cases there will be one of the following on the other end of the cable:

1) A cable/DSL modem with an ethernet bridge. i.e. the network is only being used as a point-to-point link
2) A switch - no one uses hubs any more. Again, since CSMA/CD is effectively never used in this situation, tweaking its behavior does nothing.

Unrelated to your post
3) Most games use UDP - Almost every "network accelerator card" I've seen was designed to offload the complexity of TCP. UDP and IP are incredibly simple and there is little to no benefit whatsoever to trying to accelerate them.

Re:drivers on cards?

[dotgain]

Just a couple of things to add to your post:
Sun developed it and trademarked it as OpenBoot, which is the name for their impelementation of it. OpenFirmware is the name given to any IEEE 1275 conforming implementation.
The ROM code is FCode, or Forth Bytecode. This is machine independent, so you can take an IEEE1275 ethernet card from a Sun Sparc, put in a PCI Machintosh, and boot off the LAN right out of the box.
Scrambling to keep up, BIOS manufacturers added bling like being able to change the boot priority of different devices, and for the system to just carry on booting in the face of a keyboard error. Truly revolutionary.

Re:Yes.

[sketerpot]

Bah, I created it first and called it MegaPacketBlast X-Treem!

I had something like this..

[jleq]

I had a card like this back in 1998. It was a 3Com Etherlink with "Parallel Tasking II"... Except that it actually did make a difference with the PCs of that day, and cost a hell of a lot less.

Sadly, I know some people who will probably actually buy a network card like this... LOL KILLER! How ridiculous.

Work for UDP

[shani]

UDP still carries a checksum, which does involve doing calculation over the entire contents of the packet and header. I admit, the calculation is simple, and the amount of data in the packet is small, but it is non-zero.

Also, IP supports packet fragmentation and reassembly. This is why you can send a 5000 byte UDP packet on an Ethernet network, which sends data in chucks of 1500 bytes. I think the main "win" here is that by handling fragmentation on the network card, you avoid the main CPU having to context switch to collect the state before the entire IP packet has arrived. I also freely admit you probably don't get many packets of this size during gameplay.

You are right that network processing does not require much processing power, but that's not the point. The point is latency. The checksum calculation can be sped up by doing it on an ASIC (as this board does I think), and the fragmentation/reassembly can be sped up by avoiding extra context switches of the main CPU.

Personally, I doubt going from (for example) 30 msec to 25 msec ping time is worth it, but I also don't think getting 100 frames per second versus 70 frames per second from your graphics card is worth it, so what do I know? :)