[Make-wifi-fast] [Battlemesh] 33C3: another make wifi fast again

[Dave Taht]

On Wed, Dec 28, 2016 at 5:57 AM, Benjamin Henrion <zoobab at gmail.com> wrote:
> On Wed, Dec 28, 2016 at 10:39 AM, Benjamin Henrion <zoobab at gmail.com> wrote:
>> On Wed, Dec 28, 2016 at 10:26 AM, Albert Rafetseder
>> <albert.rafetseder+v10 at univie.ac.at> wrote:
>>> Hi Benjamin,
>>>
>>> Am 28/12/16 um 09:50 schrieb Benjamin Henrion:
>>>> 33C3: another make wifi fast again:
>>>>
>>>> https://media.ccc.de/v/33c3-7911-make_wi-fi_fast_again
>>>>
>>>> In German unfortunately...
>>>
>>> The MP4 file contains an English voice-over as the second audio track.
>>>
>>> If you use VLC, switch to the other track via the menu:
>>>
>>> Audio > Audio Track > Track 2 - [English]
>>>
>>> (However, there is no translation for the slides AFAICT.)
>>
>> Thanks for the tip, however I had the same problem with the European
>> Parliament videos, which uses the same trick to save space on their
>> side, but make things very complicated for the end user.
>>
>> It would be simpler to make a second video with the audio track in
>> english. Most browsers that play videos inside don't support this
>> feature of switching audio channels.
>
> In english here:
>
> https://www.youtube.com/watch?v=V48slukR3zQ

I took a listen of the english version; thanks for pointing it out. A
good intro to the upcoming standards at layer 2.

And I'm all in favor of every approach towards making wifi fast again,
but, I guess when I use the term "fast", I mostly mean "low latency".
(the phrase is a h/t to a famous mailing list: "make-tcp-fast"). I
wish some language had a good way of distinguishing between bandwidth
and response time. "Licking lag in wifi"?

I have been encouraged by the evolution of the standards (beamforming
far more than mu-mimo, which has a really ugly "sounding" phase), but
unhappy at the trendline towards binary firmware everywhere in wifi.
It would be so awesome for open source-rs to be able to participate in
evolving the next generation of wifi forward.

I note that the bufferbloat project, now that phase IV is completed,
is casting around for other major problems to solve. The
make-wifi-fast sub-project's fq_codel and airtime fairness code, for
example, does not do gang-scheduling in part due to the chicken/egg
problem of finding some 802.11ac chipset worth hacking on.

 A possible goal - make twitch gaming feasible over wifi.....

This document needs to get updated, but still has a lot of todo items on it:

https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit?usp=sharing

The thing with the largest number of todo items (after 802.11ac), as
we enter the new year... is routing...
(separate document, presently)

> --
> Benjamin Henrion <bhenrion at ffii.org>
> FFII Brussels - +32-484-566109 - +32-2-3500762
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org