Making WiFi fast

Posted Nov 10, 2016 3:15 UTC (Thu) by drag (guest, #31333)
In reply to: Making WiFi fast by rgmoore
Parent article: Making WiFi fast

The trend has always been towards sucking as much functionality out of the computer and into the processor die as possible and out of hardware logic and into the software as much as possible.

It's a cost performance thing.. as in cost and performance and reliability improves the dumber the hardware gets and the faster the cpu gets. This is generally speaking, of course. The deal here is software is much more flexible, much cheaper, and is much easier to patch to correct bugs.

That's one of the really big take-home points about Moore's law.

It's true for everything in computing, not just networking. Phone modems had their guts ripped out and became winmodems. I hated winmodems until I learned how to chance the software drivers Linux to get different algorithms and bump up my connection speeds. Then it moved to sound cards and into network and into harddrive controllers, and now things like software raid is superior for most purposes over hardware raid. Even now there isn't really any such thing as '3D acceleration' anymore, instead you just have different types of processor cores that are optimized to graphics workloads with most of the logic in the 'drivers'.

The problem with networking is that we deal with such small MTU sizes that _sometimes_ you can get better performance by offloading some of it. But for most server purposes turning off all the 'offload features' on network cards isn't a bad idea.

to post comments

Making WiFi fast

Posted Nov 10, 2016 8:38 UTC (Thu) by Sesse (subscriber, #53779) [Link] (3 responses)

While I agree with most of your point, there really is something as 3D acceleration. Even the most modern of GPUs will have a triangle rasterizer, a texture mapper and a framebuffer blend unit, all of them large fixed-function blocks (well, instantiated lots of times). This is _not_ done by the more CPU-like units (the shader cores), even though they certainly are flexible these days.

You can imagine moving all of these functions up into software, but it doesn't seem to work all that well in practice (witness e.g. Larrabee).

Fixed-function hardware

Posted Nov 10, 2016 10:04 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

It's worth noting that the original Larrabee design was intended to be a pure software system on a massively parallel chip; by the time they got as far as cancelling Larrabee the GPU in favour of Knights Ferry, they'd had to add traditional fixed-function samplers to ensure that the GPU design would be competitive. Similar applies to CPUs - in some senses, the Cell Broadband Engine SPUs are what you get if you replace a fixed-function L2 cache controller with a software-controlled L2 cache, while weak memory models are what you get if you make software responsible for cache coherency only.

In general, it looks like there's a (movable) happy medium between hardware and software; where the hardware's function is well-understood, and unlikely to change in the next decade (texture samplers, cache controllers, Ethernet checksum handling etc), then it's best as fixed-function hardware. Where there's still debate about what the function should be (not just how fast you can make it), then it's best as programmable hardware (TCP offloads, graphics shaders etc) under the control of software.

Fixed-function hardware

Posted Nov 16, 2016 19:47 UTC (Wed) by mtaht (guest, #11087) [Link] (1 responses)

The core need for offloaded into the hardware firmware is that wifi has the need to do certain things under very hard realtime constraints that the Linux kernel cannot meet. In other words, it's latency, once again, driving the need for intelligence "down there". From a signal processing perspective, we care about nanoseconds - and there are like 400+ DSPs on a modern 802.11ac chip. Up from there, in the core wifi standards are need for sub 10us response times for many operations.

What we showed was that at the higher levels of the wifi stack - at the txop level - linux is more than responsive enough to fare well at the 500+us latency range, and we can put a lot more intelligence there, that can make a huge difference in actual network behavior.

I have outlined on my blog multiple ways for even smarter firmware can do even better than we do today shifting more stuff back into the core processor, instead onto the onboard firmware

As well as multiple ways to do more smart things in the core linux networking layer, building on top of this work. If made more universal, we can also make a dent in several other nagging problems in wifi, like better routing metrics.

Many of the trials, travails, missteps, and other bugs we've had
to fix along the way are in my blog and/or discussed on the make-wifi-fast list.

http://blog.cerowrt.org/post/

There is so much more that can be done to improve wifi! The best document we have on all that, is here:

https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEy...

Fixed-function hardware

Posted Nov 16, 2016 20:09 UTC (Wed) by mtaht (guest, #11087) [Link]

As a counter-example of how better onboard firmware could cut observed latencies down below what we can achieve by moving more ops into the kernel, see:

http://blog.cerowrt.org/post/a_look_back_at_cerowrt_wifi/

Some chipsets already expose a per-station concept, in particular.