Making WiFi fast

Posted Nov 10, 2016 8:38 UTC (Thu) by Sesse (subscriber, #53779)
In reply to: Making WiFi fast by drag
Parent article: Making WiFi fast

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).

to post comments

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.