Re: [Cerowrt-devel] ath10k test of openwrt head

[Toke Høiland-Jørgensen]

Dave Taht  writes:

> well, aqm is engaging, but waaay too late - 2-3 sec latencies on a
> given 10mbit wifi test.

So this would be without AQL, right?

-Toke
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] AQL in openwrt head, but not 19 stable

[Toke Høiland-Jørgensen]

"David P. Reed"  writes:

> Pragmatically, I solve this by a mixed, manual strategy. My entry
> router at home isn't OpenWRT based, it only connects a WAN GigE port
> to a home LAN GigE port. I use multiple APs, and for now solve the
> "make wifi fast" problem by using one 5 GHz channel per AP, and enough
> APs so I can have only one laptop or phone per AP/channel. And the
> bulk of my heavy dutu use is wired to a 10 GigE backbone in the house.
> That way, most of my file transfers only interfere with the same
> endpoints interactions.
>
> I'd really like to not have to do this, but to be honest, maintaining
> OpenWRT, and dealing with the super-proprietary garbage in WiFi
> chipsets is just a waste of my time, which is spent on other efforts -
> I can buy my way out by treating APs as disposable, suboptimal crap.
>
> I'd really like to see someone fund you guys and to actually learn what you 
> know.
>
> The atheros, broadcom, and other chip providers are the obvious source
> of support, but for some reason they don't want to compete on getting
> rid of bloat in the airwaves.
>
> Maybe some Chinese company is motivated to beat Qualcomm and Broadcom
> by going open in their packet handling driver code and letting you
> guys make it work?

That would be MediaTek (Taiwanese, though). They got Felix to write the
upstream driver (mt76), and I'm sure it'll surprise no one that it's
quite good. Haven't had a chance to actually install any of the hardware
yet, although I do have a few cards lying on my desk, biding their time.

-Toke
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Clearing out the moderation queues

[Toke Høiland-Jørgensen via Cerowrt-devel]

--- Begin Message ---
Hey everyone

I'm going through the moderation queue of these two lists, and, well,
turns out there was a bit of a backlog. Up to four years of backlog, in
fact. I'm letting everything through that is not spam, so if you're
wondering why a lot of old emails suddenly show up in your mailbox
that's why.

Apologies for the inconvenience, I'll keep an eye on the moderation
requests in the future (I wasn't getting notifications before, but now
that I am it shouldn't be an issue to get a moderation turn-around
slightly below four years ;)).

-Toke
--- End Message ---
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DC behaviors today

[Luca Muscariello]

I think everything is about response time, even throughput.

If we compare the time to transmit a single packet from A to B, including
propagation delay, transmission delay and queuing delay,
to the time to move a much larger amount of data from A to B we use
throughput in this second case because it is a normalized
quantity w.r.t. response time (bytes over delivery time). For a single
transmission we tend to use latency.
But in the end response time is what matters.

Also, even instantaneous throughput is well defined only for a time scale
which has to be much larger than the min RTT (propagation +  transmission
delays)
Agree also that looking at video, latency and latency budgets are better
quantities than throughput. At least more accurate.










On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson  wrote:

> On Mon, 4 Dec 2017, dpr...@reed.com wrote:
>
> I suggest we stop talking about throughput, which has been the mistaken
>> idea about networking for 30-40 years.
>>
>
> We need to talk both about latency and speed. Yes, speed is talked about
> too much (relative to RTT), but it's not irrelevant.
>
> Speed of light in fiber means RTT is approx 1ms per 100km, so from
> Stockholm to SFO my RTT is never going to be significantly below 85ms
> (8625km great circle). It's current twice that.
>
> So we just have to accept that some services will never be deliverable
> across the wider Internet, but have to be deployed closer to the customer
> (as per your examples, some need 1ms RTT to work well), and we need lower
> access latency and lower queuing delay. So yes, agreed.
>
> However, I am not going to concede that speed is "mistaken idea about
> networking". No amount of smarter queuing is going to fix the problem if I
> don't have enough throughput available to me that I need for my application.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> ___
> Bloat mailing list
> bl...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] [Cake] flent testers wanted prior to next release

[Klatsky, Carl]

Toke,

Sorry for the delays again but I was able to turn on debug logging.  I created 
an Issue on github Flent as the means to pass the debug log file.  Please check 
there and we can continue the debug dialog there as needed.

Regards,
Carl Klatsky

-Original Message-
From: Toke Høiland-Jørgensen [mailto:t...@toke.dk] 
Sent: Tuesday, January 31, 2017 10:47 AM
To: Klatsky, Carl 
Cc: Dave Taht ; bloat ; 
flent-us...@flent.org; cerowrt-devel@lists.bufferbloat.net; 
c...@lists.bufferbloat.net; make-wifi-f...@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] [Cake] flent testers wanted prior to next release

"Klatsky, Carl"  writes:

> Finally had some time to get to this request. I downloaded the current 
> git version of Flent and was able to launch the flent-gui on Windows. 
> I had some old test *.flent.gz results files which loaded just fine. I 
> tried to open the test files that were linked from Pete Heist mail 
> "[Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS 
> available". Those files did not load for some reason.
>
> Note, in Windows I am only using Flent to view results files in the 
> GUI. I do not use it to launch tests from Windows.

It would be helpful if you could turn on debug logging and exception debugging 
in the GUI, or run with -L logfile.txt from the command line, and post the 
resulting log entries (after trying to load the files that didn't work) 
somewhere... :)

-Toke

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Babel-users] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Benjamin Henrion]

On Wed, Jun 22, 2016 at 1:31 PM, Juliusz Chroboczek
 wrote:
>> The preinstalled OS has sufficient compiler and onboard flash space to
>> build a current babeld from git, and I'm happy to report IPV6_SUBTREES
>> is compiled in by default.
>
> Dave,
>
> It's not the first time that I notice with wonder that you're compiling on
> the devel boards.  Are you aware that cross-compiling babeld to armhf is
> so easy it's not even funny?
>
>   sudo apt-get install gcc-arm-linux-gnueabihf
>   make CC=arm-linux-gnueabihf-gcc

Well, I have been pushing for those xcompilers 10 years ago, depending
on the distro you use, it is still not in Debian stable:

https://packages.debian.org/search?keywords=gcc-arm-linux-gnueabihf

So if you use Ubuntu, it is there since 12.04LTS:

http://packages.ubuntu.com/search?keywords=gcc-arm-linux-gnueabihf

Otherwise, if you want to avoid the "compile on the target", you could
also run the following qemu+docker trick, even though docker should
not be a requirement, it should be doable with chroot:

docker run -it --rm -v
/usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian
bash

Best,

-- 
Benjamin Henrion 
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."
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] ipv6 not quite working for me on internal networks

[Simon Dalley]

On 17/06/16 15:21, Dave Taht wrote:

On Thu, Jun 16, 2016 at 8:56 PM, Simon Dalley  wrote:

Hello,

First, thanks for all the work to make cerowrt what it is.

Was. I am really encouraging everyone to update to lede at this point,
which has nearly everything that was "good" about cerowrt in it.
Well, the nice thing about cerowrt "was" its improved list of setup 
defaults vs. openwrt, not least the routed-instead-of-bridged subnets 
which is so helpful on mixed wired/wireless. Has this been carried over 
into lede? Is there a recommended cerowrt-flavoured git branch in lede?

I am having some difficulty with ipv6 on the "last hop", namely my internal
network.

Platform: Netgear WNDR3800
Cerowrt version: CeroWrt Toronto 3.10.50-1 / LuCI Trunk (svn-r10459)

AQUISS, my UK ISP, provides an ipv6 address range:
 IPv6 Address 20xx::xx55:ae00::/56

Are you getting this via dhcp-pd or is it static?
I had set the Network | Interfaces | GE00 check box "Enable IPv6 
negotiation on the PPP link" and the options below for the WAN6 
interface, but that didn't seem to do anything. Only when I added an 
explicit value for the "ipv6prefix" option did any global ipv6 addresses 
appear. In /etc/config/networks:

config interface 'wan6'
option ifname '@ge00'
option proto 'dhcpv6'
option broadcast '1'
option metric '2048'
option reqprefix '56'
option reqaddress 'try'
option ip6prefix '20xx::xx55:ae00::/56'

config interface 'ge00'
option _orig_ifname 'ge00'
option _orig_bridge 'false'
option ifname 'ge00'
option proto 'pppoe'
option ipv6 '1'
option username 'xx...@aquiss.com'
option password 'x'
option mtu '1458'



Recommended MTU: 1458 bytes

I can make ipv6 work when connecting PC host "centaur" directly to the cable
modem and running pppd. ping6 ipv6.google.com etc works fine.

The "cable" modem is running over ppp???
Sorry, I shouldn't have just glibly said "cable modem". It's actually a 
FTTC DSL modem, serving via PPPoE. When I was trying it directly from 
the PC, I set it up using pppoeconf under ubuntu.

Reconnecting via the WNDR3800, everything ipv4 related works fine with
"centaur" on the se00 subnet.

I can also ping6 without problems from the WNDR3800:
   root@cerowrt:~# ping6 ipv6.google.com
   PING ipv6.google.com (2a00:1450:4009:80f::200e): 56 data bytes
   64 bytes from 2a00:1450:4009:80f::200e: seq=0 ttl=53 time=15.576 ms
   64 bytes from 2a00:1450:4009:80f::200e: seq=1 ttl=53 time=14.959 ms
   64 bytes from 2a00:1450:4009:80f::200e: seq=2 ttl=53 time=15.156 ms
   64 bytes from 2a00:1450:4009:80f::200e: seq=3 ttl=53 time=15.044 ms
   ^C
   --- ipv6.google.com ping statistics ---
   4 packets transmitted, 4 packets received, 0% packet loss
   round-trip min/avg/max = 14.959/15.183/15.576 ms

but ping6 can't get through from centaur on se00:

A traceroute6 would be better. Try it from various source addresses on
the router.

From centaur on se00:
root@centaur:/etc/network# traceroute6 ipv6.google.com
traceroute to ipv6.l.google.com (2a00:1450:400b:c00::71) from 
20xx::xx55:ae02::f48, 30 hops max, 24 byte packets
 1  20xx::xx55:ae02::1 (20xx::xx55:ae02::1)  0.498 ms !N 0.559 
ms !N  0.438 ms !N


From cerowrt using default interface:
root@cerowrt:/etc/config# traceroute6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4009:80e::200e), 30 hops max, 
16 byte packets
 1  fe80::f60f:1bff:fe17:8d00%pppoe-ge00 
(fe80::f60f:1bff:fe17:8d00%pppoe-ge00)  8.742 ms  8.763 ms  8.595 ms
 2  gi1-2.inx.dist.dsl.enta.net (2001:4d48:feed:58::a)  8.901 ms 8.512 
ms  8.410 ms
 3  te2-2.interxion.dsl.enta.net (2001:4d48:feed:4b::a)  8.825 ms 8.628 
ms  8.749 ms
 4  te2-3.interxion.core.enta.net (2001:4d48:feed:22::a)  9.024 ms 
7.482 ms  9.070 ms

 5  2001:4d48:ace::44 (2001:4d48:ace::44)  15.690 ms  17.611 ms 15.333 ms
 6  2001:4d48:ace::43 (2001:4d48:ace::43)  15.427 ms  15.566 ms 16.255 ms
 7  2001:4860:1:1:0:2114:0:5 (2001:4860:1:1:0:2114:0:5)  15.109 ms 
14.715 ms  14.300 ms
 8  2001:4860:1:1:0:2114:0:4 (2001:4860:1:1:0:2114:0:4)  14.467 ms 
15.516 ms  14.986 ms
 9  2001:4860::1:0:cd12 (2001:4860::1:0:cd12)  15.367 ms  15.571 ms 
15.638 ms
10  2001:4860::8:0:87b7 (2001:4860::8:0:87b7)  14.824 ms  24.848 ms 
15.119 ms
11  2001:4860::8:0:ac54 (2001:4860::8:0:ac54)  15.387 ms  29.964 ms 
15.637 ms
12  2001:4860::1:0:ab9d (2001:4860::1:0:ab9d)  16.347 ms  16.363 ms 
15.685 ms
13  2001:4860:0:1::1b27 (2001:4860:0:1::1b27)  16.147 ms  16.556 ms 
15.459 ms
14  2001:4860:0:1::1755 (2001:4860:0:1::1755)  15.657 ms  15.828 ms 
15.434 ms
15  lhr25s01-in-x200e.1e100.net (2a00:1450:4009:80e::200e)  15.515 ms  
15.551 ms  15.457 ms


From cerowrt but using se00 interface's address:
root@cerowrt:/etc/config# traceroute6 -s 20xx::xx55:ae02::1 
ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4009:80e::200e) from 
20xx::xx55:ae02::1, 30 hops max, 16 byte packets

 1traceroute6: sendto: Operation not permitted



Disabling the firewall

Re: [Cerowrt-devel] [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[Dirk Neukirchen]

On 11.06.2016 19:44, Dave Taht wrote:
> E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk
> 
> The principal problem with fdisk nowadays is that very large (> 2TB, I
> think) devices are not supported by it, and require a GPT capable
> tool. Is there a replacement in lede that handles GPT? If not - this
> is an old gdisk port to openwrt that I used to use.

util-linux w. fdisk/cfdisk etc. should work - i just tested your case in a 
malta VM w. virtual 3TB qemu disk:

qemu-img create test.disk 3T
Formatting 'test.disk', fmt=raw size=3298534883328

qemu-system-mipsel -M malta -hda lede-malta-le-root.ext4 -hdb test.disk -kernel 
lede-malta-le-vmlinux.elf -nographic -append "root=/dev/sda console=ttyS0 debug 
ignore_loglevel loglevel=7 verbose "

root@(none):/# lsblk
[9.429150] random: nonblocking pool is initialized
NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda 8:00   48M  0 disk /
sdb 8:16   03T  0 disk 
mtdblock0  31:001M  1 disk 
mtdblock1  31:10  2.9M  0 disk 
mtdblock2  31:20  128K  1 disk 

cfdisk /dev/sdb
i create 3 partitions there

root@lede:/# fdisk -l /dev/sdb
Disk /dev/sdb: 3 TiB, 3298534883328 bytes, 6442450944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5F5FA543-8EEB-47B1-A6D0-F0E24A4C544D

Device  StartEndSectors  Size Type
/dev/sdb12048 2147485695 21474836481T Linux filesystem
/dev/sdb2  2147485696 4294969343 21474836481T Linux filesystem
/dev/sdb3  4294969344 6442450910 2147481567 1024G Linux filesystem
root@lede:/# lsblk
NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda 8:00   48M  0 disk /
sdb 8:16   03T  0 disk 
├─sdb1  8:17   01T  0 part 
├─sdb2  8:18   01T  0 part 
└─sdb3  8:19   0 1024G  0 part 


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[Lars Kruse]

Hi Dave,


Am Sun, 12 Jun 2016 08:23:04 -0700
schrieb Dave Taht :

> Groovy. There are quite a few other devices that have POE (edgerouter
> is the first that comes to mind), perhaps this can be built on
> generically?

here should be the proper place (it was changed after my patch):
 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/03_gpio_switches

Cheers,
Lars
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] flent testers wanted prior to next release

[Klatsky, Carl]

Finally had some time to get to this request.  I downloaded the current git 
version of Flent and was able to launch the flent-gui on Windows.  I had some 
old test *.flent.gz results files which loaded just fine.  I tried to open the 
test files that were linked from Pete Heist mail "[Cake] Flent results for 
point-to-point Wi-Fi on LEDE/OM2P-HSavailable".  Those files did not 
load for some reason.

Note, in Windows I am only using Flent to view results files in the GUI.  I do 
not use it to launch tests from Windows.

Regards,
Carl Klatsky

-Original Message-
From: Cake [mailto:cake-boun...@lists.bufferbloat.net] On Behalf Of Dave Taht
Sent: Tuesday, December 20, 2016 2:03 PM
To: bloat ; flent-us...@flent.org; 
cerowrt-devel@lists.bufferbloat.net; c...@lists.bufferbloat.net; 
make-wifi-f...@lists.bufferbloat.net
Subject: [Cake] flent testers wanted prior to next release

Toke has been busy adding new features to the flent network test tool.
I consider it *almost* stable enough for a new release. Some of the development 
has been focused on making the flent-gui much faster and more responsive (as 
our data sets have got larger), others on providing better default command line 
output, and there's other fixes across the board, including QT5 support.

In particular, I fear we've broken windows users of flent. I would dearly like 
it if some more folk out there using flent could pull the latest git version 
and see if there are any new bugs or regressions in it, any of the the 87 
tests, and the plotters, before freezing the code for a new year's release.

github: https://github.com/tohojo/flent
main site: https://flent.org/

While you are at it, please feel free to stress out any of the flent servers as 
a target, give the new cake a shot and compare it against
htb+fq_codel or your aqm of choice, or fiddle with the new wifi code,
and share your data. tcp_nup, tcp_ndown, rrul, rrul_be remain the main tests, 
but the square wave one is turning out interesting :)

And if you have any feature requests or bugs to file, please get them in soon 
to the github!

We could also use better documentation and tutorials for use... some more 
example scripts leveraging things like the cpu_stats and qdisc_stats tools, and 
so on,

Active public servers include:

flent-freemont.bufferbloat.net
( this is colocated with flent-bbr-west which has bbr on by default - an 
interesting test might be testing both these servers at the same time via the 
rtt_fair* tests from your location)

flent-dallas.bufferbloat.net
flent-london.bufferbloat.net
flent-tokyo.bufferbloat.net
flent-newark.bufferbloat.net

There are also netperf-west and netperf-east and netperf-eu and no doubt a few 
others.

We plan to add a few BBR enabled servers over the holidays.

The changelog so far:


- Support PyQt5 in the GUI (and prefer it over PyQt4). If PyQt5 is not found, 
fall back to PyQt4.


- Add new SummaryFormatter that outputs mean and median values for each data 
series. This is the new default formatter, meaning that its output will be 
shown after a test run if no other formatter (or plot) is specified.

- Support multiprocessing in the GUI. When loading several plots at once, 
plotting will now be passed off to separate worker processes.

  This allows plotting to use all the available processors on the machine, and 
speeds up loading of many plots tremendously (initial load is sped up by an 
order of magnitude). This change also means that re-plotting on config changes 
will be done dynamically in the background, which makes the GUI more responsive.

- Make text completely black in the default colour scheme. This increases 
contrast, and helps legibility, especially on printed figures.


- Some internal code changes: Port command line parser from the old optparse 
class to the newer argparse, and fix a bunch of linter


--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
Cake mailing list
c...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Cross-compiling to armhf

[Benjamin Henrion]

On Wed, Jun 22, 2016 at 3:10 PM, Juliusz Chroboczek
 wrote:
>> you could also run the following qemu+docker trick,
>
> That's like taking a machine gun to a knife fight ;-)
>
> Just set up a chroot (I like deboostrap, but you could simply copy the
> contents of the device's rootfs), and do
>
>   sudo apt-get install qemu-user-static
>   sudo cp /usr/bin/qemu-arm-static ~/chroot/usr/bin/
>   sudo chroot ~/chroot
>
> and everything should work (but check /proc/sys/fs/binfmt_misc/qemu-arm
> first).

Do not forget:

mount --bind /dev ~/chroot/dev
mount --bind /dev/pts ~/chroot/dev/pts
mount --bind /proc ~/chroot/proc
mount --bind /sys ~/chroot/sys

But with the docker machine gun it is there.

--
Benjamin Henrion 
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."
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] first 802.11ad appearance

[Luca Muscariello]

Sorry for resurrecting a year old thread.
Is there any router with 802.11ad chips that can host openwrt?

I did not find any, but I might be wrong.

Luca






On Wed, Jan 20, 2016 at 7:27 PM, Dave Täht  wrote:

> It would be so nice, of course, if this was open source from the getgo.
>
> http://arstechnica.com/gadgets/2016/01/tp-link-
> unveils-worlds-first-802-11ad-wigig-router/
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] eero gains competition in plumewifi

[Erkki Lintunen]

On 06/20/2016 09:16 AM, Dave Taht wrote:

I sure wish I knew how they are implementing diversity routing and if
they are bothering to pay attention to make-wifi-fast

https://www.plumewifi.com/



Quite a staffing for a startup, the web site lists 46 names and 
positions from which 26 are named as engineers. Wondering if they 
already are in the business of WiFi chip and RF engineering, which 
enable them to do some "magic" to make a network of their own from the 
plumewifi plugs. On staffing resources this isn't on par with Eero, I think.


- Erkki
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DC behaviors today

[Matthias Tafelmeier]

>
> Probably, me forming some papers wrapping this up would be worthwile.
>
> [1]https://phys.org/news/2017-08-high-bandwidth-capability-ships.html
>
> [2]https://arxiv.org/pdf/1705.10630.pdf
>
I couldn't refrain. Currently, I've no affiliation rights, therefore I'm
not eligible to push up to arxiv.org or equivalent: this I why I went
for a blog article here [1] in favour of a paer. It's mediocre, thin,
yes ... nevertheless, was astounded during recherche that the idea is
actually already ~ 15 y. old [2]. Back then, this was really an
'intellectual step'.


[1]
https://matthias0tafelmeier.wordpress.com/2017/12/26/speed-of-light-in-the-air-towards-an-airborne-internet-backbone

[2] 
https://www.researchgate.net/publication/224793937_Stratospheric_Optical_Inter-Platform_Links_for_High_Altitude_Platforms
 

-- 
Besten Gruß

Matthias Tafelmeier



0x8ADF343B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DC behaviors today

[Matthias Tafelmeier]

> I tend not to care as much about how long it takes for things that do
> not need R/T deadlines as humans and as steering wheels do.
>
> Propigation delay, while ultimately bound by the speed of light, is also
> affected by the wires wrapping indirectly around the earth - much slower
> than would be possible if we worked at it:
>
> https://arxiv.org/pdf/1505.03449.pdf

Enchanting that somebody actually quantified this intricacy!

*My* Addendum/Errata:

The alternative to a 'fast lane' backbone is not necessarily a mast
based microwave link as stated, which is probably infeasible/inflexible etc.

They were mentioning 'weather-balloons' as well- which actually boils
down to - I'm presuming this - the probably ongoing airborne platform
internet extension attempts by Goggle/Lockheed Martin etc., you call
them ...

These attempts are not based on balloons, but airships
('dirigible'-balloons so to speak), being able to stay aloft for
potentially years. That's widely known and so let's get them away, not
out for that.

NB. Airships are quite impressive for its own and therefore worth bein
recherched for!!!

What I actually wanted to posit in relation to that is that one could
get sooner a c-cabable backbone sibling by marrying two ideas: the
airborne concept ongoing as outlined plus what NASA is planning to bring
about for the space backbone, e.g [1][2]. It's laser based instead of
directed radio-wave only. Sure, both is in the speed range of c,
apparantely, laser transmission has in addition a significantly higher
bandwidth to offer. "10 to 100 times as much data at a time as
radio-frequency systems"[3]. Attenuations to photons in clean
atmospheric air are neglible (few mps - refractive index of about
1.0003), so actually a neglible slowdown - easily competing with top
notch fibres (99.7% the vacuum speed of light). Sure, that's the ideal
case, though, if cleverly done from the procurement of platforms and
overall system steering perspective, might feasible.


[1]
https://www.nasa.gov/feature/goddard/2017/nasa-taking-first-steps-toward-high-speed-space-internet

[2]
https://www.nasa.gov/feature/new-solar-system-internet-technology-debuts-on-the-international-space-station

[3]
https://www.nasa.gov/feature/goddard/2017/tdrs-an-era-of-continuous-space-communications

-- 
Besten Gruß

Matthias Tafelmeier



0x8ADF343B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Klatsky, Carl]

On Thu, 20 Oct 2016, Rich Brown wrote:

> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps
> _In_v1.pdf

Does anyone understand what access speeds these customers had during these 
tests?
[Carl Klatsky] For this trial, the customers were provisioned with 110 Mbps 
down / 10 Mbps up.

96 kilobyte buffer on 1 megabit/s upstream or 50 megabit/s upstream makes a big 
difference.

(I have 250/50 on my DOCSIS3.0 connection, but perhaps it's common knowledge 
what speeds Comcast customers typically has, that I don't know?)

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
bl...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Fwd: perf and BQL on the linksys 1200ac.

[Marcin Wojtas]

Hi Toke,

Yes, I've been overloaded heavily with another projects and this one
is my hobby activity I haven't had time for. I should have some spare
time though in the beginning of December and will send v2.

Best regards,
Marcin

2016-11-20 22:44 GMT+01:00 Toke Høiland-Jørgensen :
> Dave Taht  writes:
>
>> this was the last patch set I saw. I seem to recall it or something
>> like it was reviewed later on netdev.
>
> Looks like it:
>
> https://patchwork.kernel.org/patch/9328415/ and
> https://patchwork.kernel.org/patch/9328413/
>
> Seems the xmit_more part needs a v2; guess that's why it's still
> pending? :)
>
> -Toke
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [gluon] Introducing the LEDE project

[Jochen Demmer]

Hi,

I'm looking forward to this as I your goals sound very appealing. I have 
zero knowledge about what went good and what didn't at/(in the 
background of) the OpenWrt project. But when your implications about the 
past problems are right, than I'm convinced they should be overcome.


What I'm curious about is:
* what tools will be used in order to prevent past obstacles, with 
special regard to communication?
* what methods will you be using to recuit more active members, while I 
believe it should be technically very easy to actively participate. I 
hope there is no exclusive focus on IRC and Mailing lists, as I consider 
both fringe group tools.
* Especially for power users/administrators. Will there be such an 
overwhelming amount of documentation one day? Compatible devices, but 
also operating manual etc.


My only concern is that this split might slow things down. I hope it 
won't.


Jochen Demmer

On 2016-05-03 20:55, John Crispin wrote:

The LEDE project is founded as a spin-off of the OpenWrt project and
shares many of the same goals. We are building an embedded Linux
distribution that makes it easy for developers, system administrators 
or

other Linux enthusiasts to build and customize software for embedded
devices, especially wireless routers. The name 'LEDE' stands for 'Linux
Embedded Development Environment'.

Members of the project already include a significant share of the most
active members of the OpenWrt community. We intend to bring new life to
Embedded Linux development by creating a community with a strong focus
on transparency, collaboration and decentralisation.

LEDE’s stated goals are:
- Building a great embedded Linux distribution with focus on stability
and functionality.
- Having regular, predictable release cycles coupled with community
provided device testing feedback.
- Establishing transparent decision processes with broad community
participation and public meetings.

We decided to create this new project because of long standing issues
that we were unable to fix from within the OpenWrt project/community:
1. Number of active core developers at an all time low, no process for
getting more new people involved.
2. Unreliable infrastructure, fixes prevented by internal disagreements
and single points of failure.
3. Lack of communication, transparency and coordination in the OpenWrt
project, both inside the core team and between the core team and the
rest of the community.
4. Not enough people with commit access to handle the incoming flow of
patches, too little attention to testing and regular builds.
5. Lack of focus on stability and documentation.

To address these issues we set up the LEDE project in a different way
compared to OpenWrt:
1. All our communication channels are public, some read-only to
non-members to maintain a good signal-to-noise ratio.
2. Our decision making process is more open, with an approximate 50/50
mix of developers and power users with voting rights.
3. Our infrastructure is simplified a lot, to ensure that it creates
less maintenance work for us.
4. We have made our merge policy more liberal, based on our experience
with the OpenWrt package github feed.
5. We have a strong focus on automated testing combined with a
simplified release process.

We would like to thank the communities using the codebase and would
welcome endorsements. If your community feels that the idea is good and
will benefit all our communities as a whole then please post an
endorsement on the lede-dev mailing list.

Find out more on our project website http://lede-project.org/

Daniel Golle
Felix Fietkau
Hauke Mehrtens
Jo-Philipp Wich
John Crispin
Matthias Schiffer
Steven Barth

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] Linux network is damn fast, need more use XDP (Was: DC behaviors today)

[Matthias Tafelmeier]

Hello,
> Scaling up to more CPUs and TCP-stream, Tariq[1] and I have showed the
> Linux kernel network stack scales to 94Gbit/s (linerate minus overhead).
> But when the drivers page-recycler fails, we hit bottlenecks in the
> page-allocator, that cause negative scaling to around 43Gbit/s.
>
> [1] http://lkml.kernel.org/r/cef85936-10b2-5d76-9f97-cb03b418f...@mellanox.com
>
> Linux have for a _long_ time been doing 10Gbit/s TCP-stream easily, on
> a SINGLE CPU.  This is mostly thanks to TSO/GRO aggregating packets,
> but last couple of years the network stack have been optimized (with
> UDP workloads), and as a result we can do 10G without TSO/GRO on a
> single-CPU.  This is "only" 812Kpps with MTU size frames.

Cannot find the reference anymore, but there was once some workshop held
by you during some netdev where you were stating that you're practially
in rigorous exchange with NIC vendors as to having them tremendously
increase the RX/TX rings(queues) numbers. Further, that there are hardly
any limits to the number other than FPGA magic/physical HW - up to
millions is viable was coined back then.  May I ask were this ended up?
Wouldn't that be key for massive parallelization either - With having a
queue(producer), a CPU (consumer)  - vice versa - per flow at the
extreme? Did this end up in this SMART-NIC thingummy? The latter is
rather trageted at XDP, no?


-- 
Besten Gruß

Matthias Tafelmeier



0x8ADF343B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DC behaviors today

[Matthias Tafelmeier]

>
>> What I actually wanted to posit in relation to that is that one could
>> get sooner a c-cabable backbone sibling by marrying two ideas: the
>> airborne concept ongoing as outlined plus what NASA is planning to
>> bring about for the space backbone, e.g [1][2]. It's laser based
>> instead of directed radio-wave only. Sure, both is in the speed range
>> of c, apparantely, laser transmission has in addition a significantly
>> higher bandwidth to offer. "10 to 100 times as much data at a time as
>> radio-frequency systems"[3]. Attenuations to photons in clean
>> atmospheric air are neglible (few mps - refractive index of about
>> 1.0003), so actually a neglible slowdown - easily competing with top
>> notch fibres (99.7% the vacuum speed of light). Sure, that's the
>> ideal case, though, if cleverly done from the procurement of
>> platforms and overall system steering perspective, might feasible.
>
> Todays laser links are in the few km per hop range, with is easily at
> least one magnitude shorter than radio based equivalents.
>
Hold on! This is a severe oversimplifcation, isn' it. The devices you're
probably referring to are in the low-end segment, dillentically and
maybe terrestrially operated only - to mention a few limiting factor
conceivable possibly being perceived.

Certainly, there are range limiting factors when fully submerged in the
near-ground atmospheric ranges. E.g. in the darkest snow storm, one
cannot expect optics to be reliablly working - admitting that.
Nothwithstanding, recent research[1] showed astounding achievements of
FSOs even in harsh atmospheric conditions - "up to 10 gigabits per
second" while in vivid movement, in heavy fog ... for a single pathed laser.

90% mass of the atmosphere  is below 16 km (52,000 ft), therefore also
most of it's randomness[2]. Meaning, one only had to surpass this
distance to more decently unfold the capabilities of an airborne
backbone. Therefore, a hierarchy of airborne vessels might be necessary.
Might smaller, more numerous ones gatewaying the optics out of the dense
parts of the atmosphere to the actual backbone-net borne lasers, might
by doing this relaying not laser beam based. Far more mitigation
techniques are conceivable. From there on, the shortcomings appear
controllable.

> I don't know the physics behind it, but people who have better insight
> than I do tell me "it's hard" to run longer hops (if one wants any
> kind of high bitrate).
If one looks up what is achievable in space, where the conditions
shouldn't be too different from earth atmosphere over 16 km. Thousands
of kilometres for a single hop, single path. Now imagine a decent degree
of multipathing.

Physical intricacies are certainly a headache in this topic, though
shouldn't be decisive, I'd dare to categorize the largest complexity
compartment of such a system into the algorithmics for steering,
converging or stabilizing the airborne components, directing the optics
problerly and in time. The overall automatic or even autonomic
operations to abstract it.

Probably, me forming some papers wrapping this up would be worthwile.

[1]https://phys.org/news/2017-08-high-bandwidth-capability-ships.html

[2]https://arxiv.org/pdf/1705.10630.pdf

-- 
Besten Gruß

Matthias Tafelmeier



0x8ADF343B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[Daniel Curran-Dickinson]

Hi Dave,

I don't speak for the LEDE team, but it looks to me a lot of your
problem is that you are using LEDE/openwrt for far bigger iron than the
primary target (standard routers, including pre-AC non-NAND ones, which
are really quite small and low powered).  2 TB+ storage for example, or
using lighttpd instead of uhttpd are really things that don't affect the
primary use case and if you want to support this, you need to find a way
to do that does not negatively affect your typical router (without
external storage).

Regards,

Daniel

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DC behaviors today

[Luca Muscariello]

+1 on all.
Except that Little's Law is very general as it applies to any ergodic
process.
It just derives from the law of large numbers. And BTW, Little's law is a
very powerful law.
We use it unconsciously all the time.



On Tue, Dec 12, 2017 at 11:53 PM,  wrote:

> Luca's point tends to be correct - variable latency destroys the stability
> of flow control loops, which destroys throughput, even when there is
> sufficient capacity to handle the load.
>
>
>
> This is an indirect result of Little's Lemma (which is strictly true only
> for Poisson arrival, but almost any arrival process will have a similar
> interaction between latency and throughput).
>
>
>
> However, the other reason I say what I say so strongly is this:
>
>
>
> Rant on.
>
>
>
> Peak/avg. load ratio always exceeds a factor of 10 or more, IRL. Only
> "benchmark setups" (or hot-rod races done for academic reasons or marketing
> reasons to claim some sort of "title") operate at peak supportable load any
> significant part of the time.
>
>
>
> The reason for this is not just "fat pipes are better", but because
> bitrate of the underlying medium is an insignificant fraction of systems
> operational and capital expense.
>
>
>
> SLA's are specified in "uptime" not "bits transported", and a clogged pipe
> is defined as down when latency exceeds a small number.
>
>
>
> Typical operating points of corporate networks where the users are happy
> are single-digit percentage of max load.
>
>
>
> This is also true of computer buses and memory controllers and storage
> interfaces IRL. Again, latency is the primary measure, and the system never
> focuses on operating points anywhere near max throughput.
>
>
>
> Rant off.
>
>
> On Tuesday, December 12, 2017 1:36pm, "Dave Taht"  said:
>
> >
> > Luca Muscariello  writes:
> >
> > > I think everything is about response time, even throughput.
> > >
> > > If we compare the time to transmit a single packet from A to B,
> including
> > > propagation delay, transmission delay and queuing delay,
> > > to the time to move a much larger amount of data from A to B we use
> > throughput
> > > in this second case because it is a normalized
> > > quantity w.r.t. response time (bytes over delivery time). For a single
> > > transmission we tend to use latency.
> > > But in the end response time is what matters.
> > >
> > > Also, even instantaneous throughput is well defined only for a time
> scale
> > which
> > > has to be much larger than the min RTT (propagation + transmission
> delays)
> > > Agree also that looking at video, latency and latency budgets are
> better
> > > quantities than throughput. At least more accurate.
> > >
> > > On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson 
> > wrote:
> > >
> > > On Mon, 4 Dec 2017, dpr...@reed.com wrote:
> > >
> > > I suggest we stop talking about throughput, which has been the
> > mistaken
> > > idea about networking for 30-40 years.
> > >
> > >
> > > We need to talk both about latency and speed. Yes, speed is talked
> about
> > too
> > > much (relative to RTT), but it's not irrelevant.
> > >
> > > Speed of light in fiber means RTT is approx 1ms per 100km, so from
> > Stockholm
> > > to SFO my RTT is never going to be significantly below 85ms (8625km
> > great
> > > circle). It's current twice that.
> > >
> > > So we just have to accept that some services will never be deliverable
> > > across the wider Internet, but have to be deployed closer to the
> > customer
> > > (as per your examples, some need 1ms RTT to work well), and we need
> > lower
> > > access latency and lower queuing delay. So yes, agreed.
> > >
> > > However, I am not going to concede that speed is "mistaken idea about
> > > networking". No amount of smarter queuing is going to fix the problem
> if
> > I
> > > don't have enough throughput available to me that I need for my
> > application.
> >
> > In terms of the bellcurve here, throughput has increased much more
> > rapidly than than latency has decreased, for most, and in an increasing
> > majority of human-interactive cases (like video streaming), we often
> > have enough throughput.
> >
> > And the age old argument regarding "just have overcapacity, always"
> > tends to work in these cases.
> >
> > I tend not to care as much about how long it takes for things that do
> > not need R/T deadlines as humans and as steering wheels do.
> >
> > Propigation delay, while ultimately bound by the speed of light, is also
> > affected by the wires wrapping indirectly around the earth - much slower
> > than would be possible if we worked at it:
> >
> > https://arxiv.org/pdf/1505.03449.pdf
> >
> > Then there's inside the boxes themselves:
> >
> > A lot of my struggles of late has been to get latencies and adaquate
> > sampling techniques down below 3ms (my previous value for starting to
> > reject things due to having too much noise) - and despite trying fairly
> > hard, well... a process can't even sleep accurately much below 1ms, on
> > bare metal linux. A dream of 

Re: [Cerowrt-devel] [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[Rosen Penev]

E: current fdisk versions support GPT. g must be used instead of o in order
to create it. from what i've seen, both tools work the same(2048 sector
padding, etc...) for GPT.

On Sat, Jun 11, 2016 at 10:46 AM Dave Taht  wrote:

> happy to see cake working today! thx all!
>
> In https://github.com/dtaht/ceropackages-3.10:
>
> A) We have flent's tc-iterate.c as a fast, lightweight means of
> polling fq_codel, pie, cake stats (as the shell in openwrt doesn't
> support a subsecond sleep) for openwrt.
>
> (However this package and code is in need of iteration to support
> polling the new stats presented in the fq_codel for wifi sysfs code.)
>
> Having something like this working is essential to analyze the real
> performance and correctness of the new implementations on the low end
> hardware.
>
> B) I am probably the only user of the gnugol package. :(
>
> C) I really need to sync the isochronous code with what avery has upstream
>
> D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe
>
> I don't know what landed upstream to control poe for the nano-m5
> radios, if anything?
>
> E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk
>
> The principal problem with fdisk nowadays is that very large (> 2TB, I
> think) devices are not supported by it, and require a GPT capable
> tool. Is there a replacement in lede that handles GPT? If not - this
> is an old gdisk port to openwrt that I used to use.
>
> F)
> https://github.com/dtaht/ceropackages-3.10/tree/master/utils/cerowrt-scripts
> was a tool we used to measure latency under load directly on the
> router...
>
> some other packages that might be worth upstreaming, or putting in
> another repo or updating in ceropackages
>
> owamp: lets us measure ping times very precisely. (requires good ntp)
> ntpsec - a vastly hardened full fledged ntp fork https://www.ntpsec.org/
> scamper - two other measurement tools
> shaperprobe
>
> ?
>
> G) We used lighttpd in cerowrt as it was tons faster than uhttpd and
> flexible enough to also do local web serving. can it (or ngnix) be
> substituted for uhttpd? Or has uhttpd got faster?
>
> H) Anyone working on go or rust for lede? hugo and ipfs and all the
> other blockchain related distributed web bits looks like fun...
>
> It looks like the static linking in go is a deal-killer
>
> https://github.com/GeertJohan/openwrt-go/issues/2
>
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] kmod_sched_pie falis to compile with implicit declaration error in openwrt trunk for x86

[Ignatius Rivaldi]

I tried to build openwrt with Cake support according to this page:
https://www.bufferbloat.net/projects/codel/wiki/Cake/ , then I run make,
and it crashes. I then run make -j1 V=s as instructed by the make process,
and  is the last error message:

make[3]: Leaving directory
'/home/feanor/Development/Programming/openwrt/package/base-files'
make[3]: Entering directory
'/home/feanor/Development/Programming/openwrt/feeds/cero/net/kmod-sched-fq_pie'
make -C
/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/linux-4.4.14
HOSTCFLAGS="-O2
-I/home/feanor/Development/Programming/openwrt/staging_dir/host/include
-I/home/feanor/Development/Programming/openwrt/staging_dir/host/usr/include
-I/home/feanor/Development/Programming/openwrt/staging_dir/target-x86_64_musl-1.1.16/host/include
-Wall -Wmissing-prototypes -Wstrict-prototypes"
CROSS_COMPILE="x86_64-openwrt-linux-musl-" ARCH="x86" KBUILD_HAVE_NLS=no
KBUILD_BUILD_USER="" KBUILD_BUILD_HOST="" CONFIG_SHELL="bash" V=''
CC="x86_64-openwrt-linux-musl-gcc"
SUBDIRS="/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git"
modules
make[4]: Entering directory
'/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/linux-4.4.14'
  CC [M]
/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git/sch_fq_pie.o
/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git/sch_fq_pie.c:
In function 'fq_pie_change':
/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git/sch_fq_pie.c:820:2:
error: implicit declaration of function 'qdisc_tree_decrease_qlen'
[-Werror=implicit-function-declaration]
  qdisc_tree_decrease_qlen(sch, drop_count);
  ^
cc1: some warnings being treated as errors
make[5]: *** [scripts/Makefile.build:265:
/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git/sch_fq_pie.o]
Error 1
make[4]: *** [Makefile:1385:
_module_/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git]
Error 2
make[4]: Leaving directory
'/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/linux-4.4.14'
make[3]: *** [Makefile:43:
/home/feanor/Development/Programming/openwrt/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/sched-fq_pie-2015-git/.built]
Error 2
make[3]: Leaving directory
'/home/feanor/Development/Programming/openwrt/feeds/cero/net/kmod-sched-fq_pie'
make[2]: *** [package/Makefile:197:
package/feeds/cero/kmod-sched-fq_pie/compile] Error 2
make[2]: Leaving directory '/home/feanor/Development/Programming/openwrt'
make[1]: *** [package/Makefile:193:
/home/feanor/Development/Programming/openwrt/staging_dir/target-x86_64_musl-1.1.16/stamp/.package_compile]
Error 2
make[1]: Leaving directory '/home/feanor/Development/Programming/openwrt'
make: *** [/home/feanor/Development/Programming/openwrt/include/
toplevel.mk:194: world] Error 2

If this is the wrong place for bug report please tell me as this is my
first time I use mailing list
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[dpr...@deepplum.com]

Meltdown is very easy to exploit, and doesn't need heavy CPU usage (well, the 
obvious exploit is dumping all of kernel data space, which might be somewhat 
slower than a memcpy() of that data. :-)
 
Essentially, you run a loop that uses speculative memory tests to load a unique 
userspace cache line for each bit of kernel memory, and after loading some 
cache lines, you check to see if those userspace locations are in the cache. If 
you stick lo L1 cache, you can do this concurrently on multiple cores. But you 
don't need multiple cores, one will do.
 
That assumes that you are running a program that wants to read your kernel data 
looking for passwords in the clear, etc.
 
Sceptre may require heavy CPU usage, but Meltdown doesn't.
 
Depending on how you set up your "home router", you might allow "infected" or 
"trojan" programs to run in userspace there. I wouldn't do that, because 
hardware is cheap. But some people like to throw all kinds of server code into 
their router setups - even stuff like node.js servers.
 
The really core issue with Meltdown at the highest level is that the kernel is 
addressable from userspace, except for the "privilege level" in the page table 
entries. That's a couple of bits between userspace and data that userspace 
isn't supposed to ever see. And those bits are ignored during specutlative 
execution's memory accesses.
 
-Original Message-
From: "Dave Taht" 
Sent: Thursday, January 4, 2018 9:53am
To: "Jonathan Morton" 
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?



On Thu, Jan 4, 2018 at 6:49 AM, Jonathan Morton  wrote:
>> On 4 Jan, 2018, at 3:59 pm, Dave Taht  wrote:
>>
>> Alan cox has been doing a good job of finding the good stuff. Power
>> and the IBM z-series are also affected.
>
> Conversely, the ARM-1176, Cortex-A7 and Cortex-A53 cores used by various 
> iterations of the Raspberry Pi are not affected. These are all in-order 
> execution CPUs with short pipelines, and I think they're representative of 
> what you'd want in CPE.

Well, I'd hope that this string of bugs stalls deployment of more
advanced arches in this space until the speculative execution bugs are
fully resolved.

(and I *vastly* prefer short pipelines)

> - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[Lars Kruse]

Hi Dave,

> D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe
> 
> I don't know what landed upstream to control poe for the nano-m5
> radios, if anything?

I submitted a patch (that was accepted) for GPIO-based POE control - at least
for Nanostations XM/XW and for TP-Link CPE210 and CPE510:
 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=d65916047b44d6d157d88d15e8e3d92555c5e6f8

Only the luci interface is missing ...

Cheers,
Lars
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] upstreamed sqm sch_cake in openwrt-18.06-rc2

[Eric Johansson]

On 7/15/2018 11:34:50 PM, Dave Taht  wrote:
Come on, don't you remember back when reflashing for the cause was fun?
Eric Johansson: er...fun??  one PITA with updating openwrt is I need to track 
down all the modules I installed and reinstall them again. they really should 
reload all the modules found or at the very least, give you an option to select 
which modules that were installed to be installed 


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Jason Abele]

On Mon, Jun 27, 2016 at 2:43 AM, moeller0  wrote:
> Hi David,
>
>> On Jun 27, 2016, at 09:44 , David Lang  wrote:
>>
>> On Mon, 27 Jun 2016, Sebastian Moeller wrote:
>>
 On a wireless network, with 'normal' omnidirctional antennas, the signal 
 drops off with the square of the distance. So if you want to service 
 clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4 
 orders of magnatude), this is before you include effects of shielding, 
 bounces, bad antenna alignment, etc (which can add several more orders of 
 magnatude of variation)

 The receiver first normalized the strongest part of the signal to a 
 constant value, and then digitizes the result, (usually with a 12-14 bit 
 AD converter). Since 1000x is ~10 bits, the result of overlapping 
 tranmissions can be one signal at 14 bits, and another at <4 bits. This is 
 why digital processing isn't able to receive multiple stations at the same 
 time.
>>>
>>> But, I you add 10 Bits to your AD converter you basically solved this. 
>>> Now, most likely this also needs to be of higher quality and of low 
>>> internal noise, so probably expensive... Add to this the wide-band 
>>> requirement of the sample the full band approach and we are looking at a 
>>> price ad converter. On the bright side, mass-producing that might lower the 
>>> price for nice oscilloscopes...
>>
>> well, TI only manufactures AD converters up to 16 bit at these speeds, so 24 
>> bit converters are hardly something to just buy. They do make 24 and 32 bit 
>> ADCs, but only ones that could be used for signals <5MHz wide (and we are 
>> pushing to 160 MHz wide channels on wifi)
>
> But David’s idea was to sample the full 5GHz band simultaneously, so 
> we would need something like a down-mixer and an ADC system with around 2GHz 
> bandwidth (due to Nyquist), I believe multiplexing multiple slower ADC’s as 
> done in better oscilloscopes might work, but that will not help reduce the 
> price not solve the bit resolution question.
>

The reason you can not just add bits to the ADC is the thermal noise
floor: 
https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise#Noise_power_in_decibels

If you assume a maximum transmit power of ~20dBm (100mW) and a 160MHz
channel bandwidth (with a consequent thermal noise floor of -92 dBm),
the total possible dynamic range is ~112dB, if you receiver and
transmitter a coupled with no loss.  At ~6dB/bit in the ADC, anything
beyond 19bits is just quantizing noise and wasting power (which is
heat, which raises your local thermal noise floor, etc).  If your
channel bandwidth is 1GHz, the effective noise floor rises by another
~2bits, so ~17bits of dynamic range max, before accounting for path
loss and distortion.

Speaking of distortion, look at the intermod (IP3) or harmonic
distortion figures for those wideband ADC sometime, if the signals of
interest are of widely varying amplitudes in narrower bandwidths, the
performance limit will usually be distortion from the strongest
signal, not the thermal noise floor.  This usually limits dynamic
range to less than 10 effective bits.

Also transmitters are usually only required to suppress their adjacent
channel noise to around -50dB below the transmit power, so a little
over 8bits of dynamic range before the ADC is quantizing an interferer
rather than the signal of interest.

I am surprised that 802.11 still uses the same spreading code for all
stations.  I am no expert on cellular CDMA deployments, but I think
they have been using different spreading codes for each station to
increase capacity and improve the ability to mathematically remove the
interference of other physically close stations for decades.  As
complex as the 802.11 MAC is becoming, I do not understand why an
approach like MU-MIMO was chosen over negotiating a separate spreading
code per station.

My best guess is that it keeps the complexity (and therefore power) at
the AP rather than in the (increasingly mobile, power-constrained)
station.  Hopefully the rise of mesh / peer-to-peer networks in mobile
stations will apply the right engineering pressure to re-think the
idea of keeping all complexity in the AP.

Cheers,
Jason
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cheap BGP capable routers?

[Dan Mahoney]

ASR1K’s run IOS-XE.  If you need something that runs IOS classic, even a 
7206VXR might be fine, but the software is like a year out of date and the max 
ram can’t take a full BGP table right now.

I might have something floating around that you can borrow.

Sent from my iPad

> On Feb 20, 2019, at 21:26, Dave Taht  wrote:
> 
> I'm casting about for some old, cheap, cisco/juniper/etc *actual
> hardware* routers, with bgp capability, for some interop testing in
> light of my upcoming talk at netdevconf. They need not be fast, need
> not have more than 2 ports, it would help for the software to be
> maintained and current.
> 
> I hit ebay and an asr-1000 still goes for 6k. Anything "out there"
> that is significantly cheaper than that?
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Luca Muscariello]

Hi Bob,

I meant licensed/unlicensed for private/non private.

Luca

On Mon, Aug 27, 2018 at 9:39 AM Bob McMahon 
wrote:

> Hi Luca,
>
> What is non private spectrum defined as per  "I don't yet see how a non
> private spectrum can be shared  w/o LBT."
>
> Thanks,
> Bob
>
>
>
>
> On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello <
> luca.muscarie...@gmail.com> wrote:
>
>> Jonathan,
>>
>> Not that giant handwaving though.
>> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The
>> almost is necessary as it operates in 2.4/5Ghz bands.
>> Similar to what you describe, and is coming very soon in shipping
>> products.
>>
>> RTS/CTS is still a LBT to create a window where TDM can be done.
>> I don't yet see how a non private spectrum can be shared  w/o LBT.
>>
>> On the other hand, medium sharing is one thing, the other thing is
>> capacity.
>> There is no way to efficiently share a medium if this is used close to
>> its theoretical capacity.
>>
>> Capacity as #of stations per band including #SSID per band. Today scaling
>> can be achieved
>> with careful radio planning for spatial diversity or dynamic bean forming.
>>
>> When you approach capacity with WiFi you only see beacon traffic and
>> almost zero throughput.
>> Cannot forget Mobile World Congress where you can measure several
>> thousands of SSIDs on 2.4
>> and several hundreds of SSID in 5GHz. But even LTE was very close to
>> capacity.
>>
>> Dave,
>> Having air time fairness in open source is a significant achievement. I
>> don't see a failure.
>>
>> Luca
>>
>>
>> On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton 
>> wrote:
>>
>>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
>>> wrote:
>>> >
>>> > Curious to how LBT can be solved at the PHY level and if the potential
>>> solution sets preserve the end to end principle.
>>>
>>> The usual alternatives include TDM, usually coordinated by a master
>>> device (eg. the AP); full-duplex operation via diplexers and/or orthogonal
>>> coding; and simply firing off a packet and retrying with exponential
>>> backoff if an acknowledgement is not heard.
>>>
>>> TDM and diplexing are already used by both DOCSIS and LTE.  They are
>>> proven technology.  However, in DOCSIS the diplexing is greatly simplified
>>> by the use of a copper channel rather than airwaves, and in LTE the
>>> diplexer is fitted only at the tower, not in each client - so the tower can
>>> transmit and receive simultaneously, but an individual client cannot, but
>>> this is still useful because there are many clients per tower.  Effective
>>> diplexers for wireless are expensive.
>>>
>>> Orthogonal coding is already used by GPS and, in a rather esoteric form,
>>> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
>>> GPS, it allows all of the satellites in the constellation to transmit on
>>> the standard frequency simultaneously, while still being individually
>>> distinguishable.  The data rate is very low, however, since each
>>> satellite's signal inherently has a negative SNR (because there's a dozen
>>> others shouting over it) - that's why it takes a full minute for a receiver
>>> to get a fix from cold, because it simply takes that long to download the
>>> ephemeris from the first satellite whose signal is found.
>>>
>>> A future version of wifi could reasonably use TDM, I think, but not
>>> diplexing.  The way this would work is that the AP assigns each station
>>> (including itself) a series of time windows in which to transmit as much as
>>> they like, and broadcasts this schedule along with its beacon.  Also
>>> scheduled would be windows in which the AP listens for new stations,
>>> including possibly other nearby APs with which it may mutually coordinate
>>> time.  A mesh network could thus be constructed entirely out of mutually
>>> coordinating APs if necessary.
>>>
>>> The above paragraph is obviously a giant handwave...
>>>
>>>  - Jonathan Morton
>>>
>>> ___
>>> Bloat mailing list
>>> bl...@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] meanwhile... .home, finally has a home.arpa.

[Ted Lemon]

No, but that's coming.   Their security model was borked.

BTW, the naming architecture does handle cleaning up names.

I think your use case is a very interesting one.   If it doesn't work
reliably, that's a bad sign.   Not shocking at present, though.   There are
a lot of things that need to be fixed in HNCP before it can really work;
I'm sorry to hear that about Babel, though.

On Tue, Oct 23, 2018 at 12:16 PM Dave Taht  wrote:

> On Tue, Oct 23, 2018 at 8:42 AM Ted Lemon  wrote:
> >
> > That is good feedback, if depressing.   I'm kind of in the same boat—I
> really want to do some work on this for OpenWRT, but it hasn't come up to
> the top of the stack yet.   The reason I was asking is that when I've said
> at IETF that I don't think HNCP is actually complete yet, I get a lot of
> rotten tomatoes from the authors.
>
> Did they ever get it to work over dtls?
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] beating the drum for BQL

[Pete Heist]

> On Aug 23, 2018, at 10:26 AM, Pete Heist  wrote:
> 
>> On Aug 23, 2018, at 2:49 AM, Dave Taht > > wrote:
>> 
>> I had a chance to give a talk at broadcom recently, slides here:
>> 
>> http://flent-fremont.bufferbloat.net/~d/broadcom_aug9.pdf 
>> 
> 
> Thanks for sharing, this is really useful, raising awareness where it 
> matters. Quite a bit of content... :)
> 
> Ubiquiti needs some work getting this into more of their products (EdgeMAX in 
> particular). A good time to lobby for this might be, well a couple months 
> ago, as they’re producing alpha builds for their upcoming 2.0 release with 
> kernel 4.9 and new Cavium/Mediatek/Octeon SDKs. I just asked about the status 
> in the EdgeRouter Beta forum, in case it finds the right eyes before the 
> release:
> 
> https://community.ubnt.com/t5/EdgeRouter-Beta/BQL-support/m-p/2466657 
> 

This started a discussion, and no, so far it looks like there’s no BQL support 
in the upcoming 2.0 release.

For my own benefit, re-reading the original patch series comment 
(https://lwn.net/Articles/469652/ ) makes it 
sound like BQL is useful even without AQM (original benchmarks were done with 
straight pfifo_fast). I didn’t realize this, actually. If anything incorrect 
about BQL was said in this discussion, correct us, please… :)

Pete

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Pete Heist]

> On Jul 21, 2018, at 6:09 PM, Dave Taht  wrote:
> 
> PS I also have two other issues going on. This is the first time I've
> been using irtt with a 20ms interval, and I regularly see single 50+ms
> spikes (in both ping and irtt) data and also see irtt stop
> transmitting.

irtt should keep sending for the duration of the test. I noticed that it looks 
like irtt was actually used in only one of these initial tests: 
ping-2018-07-21T082842.445812.flent-newark-reno.flent. In the rest, netperf 
UDP_RR was used, which can stop sending upon packet loss.

If irtt was configured but didn’t run, that may be because flent does a 
connectivity check to the server with “irtt client -n”, where it sends three 
requests within 900ms (200ms timeout, then 300ms then 400ms) and if it doesn’t 
receive a reply, it falls back to netperf UDP_RR. Do you think that’s what 
happened here?

> On this front, it could merely be that my (not tested in
> months!) test cablemodem setup is malfunctioning also! Or we're
> hitting power save. Or (finally) seeing request-grant delays. Or
> scheduling delay somewhere in the net-next kernel I'm using... Or
> (regardless, this seems independent of my main issue, and I've not had
> such high res data before)

Regarding the spikes both you and Arie you’re seeing, I also saw in one of your 
later emails "0 delay via fq would be better than even
the 15-40ms I'm getting now with linux flows”. Those numbers struck me as 
similar to an issue I’m still dealing with:

https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spikes-about-once-per-second-even-just-to/m-p/2359800/highlight/true#M119202
 


To summarize, with airOS on the NanoStation M5, there are isochronous pauses 
around once per second in the processing of all packets, not just for the WiFi 
device but Ethernet also. Packets are not lost, but queued for either 20ms, if 
one Ethernet port is connected, or 40ms, if both are connected. This behavior 
is exactly described by the ar7240sw_phy_poll_reset function in 
ag71xx_ar7240.c, so it looks to me like the ar7240 internal switch is being 
reset once per second for no apparent reason. So far I’ve gotten crickets in 
response.

The cable modem you’re using doesn’t happen to have built-in WiFi and an 
ar7240, does it? If it does and has the same or a similar driver problem, you 
could just do a low-interval ping straight to its Ethernet adapter and check 
for isochronous spikes, something like:

sudo ping -l 100 -c 5000 -i 0.001 cablemodem

Now, back to vacation :)___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] meanwhile... .home, finally has a home.arpa.

[Ted Lemon]

On Oct 22, 2018, at 11:51 PM, Dave Taht  wrote:
> This is one of those endless bikesheds I'd totally given up on. Thx ted!

If you're feeling like an adventure, you might find the latest draft of the 
homenet naming architecture entertaining.

https://github.com/ietf-homenet-wg/simple-naming/blob/master/draft-ietf-homenet-simple-naming.txt
 


I decided to keep going on it since the submission deadline was extended, so 
it's pretty close to feature complete except for the HNCP part.

I'm curious: are you using HNCP on your networks?

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] beating the drum for BQL

[Pete Heist]

> On Aug 23, 2018, at 2:49 AM, Dave Taht  wrote:
> 
> I had a chance to give a talk at broadcom recently, slides here:
> 
> http://flent-fremont.bufferbloat.net/~d/broadcom_aug9.pdf 
> 

Thanks for sharing, this is really useful, raising awareness where it matters. 
Quite a bit of content... :)

Ubiquiti needs some work getting this into more of their products (EdgeMAX in 
particular). A good time to lobby for this might be, well a couple months ago, 
as they’re producing alpha builds for their upcoming 2.0 release with kernel 
4.9 and new Cavium/Mediatek/Octeon SDKs. I just asked about the status in the 
EdgeRouter Beta forum, in case it finds the right eyes before the release:

https://community.ubnt.com/t5/EdgeRouter-Beta/BQL-support/m-p/2466657 


https://community.ubnt.com/t5/EdgeMAX-Beta-Blog/New-EdgeRouter-firmware-2-0-0-alpha-2-has-been-released/ba-p/2414938
 


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] althea presentation on isp in a box at nanog 76

[Toke Høiland-Jørgensen]

Maciej Sołtysiak  writes:

>> https://www.youtube.com/watch?v=G4EKbgShyLw
>>
>> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
>> metric that allows for cryptocurrency traffic billing.
> Very refreshing, would love to see that succeed and then get popular in 
> Europe too!
>
> On Getting Started Page [1] they suggest TP Link C7 for CPEs. Is that
> still one of the best suited home routers for getting make-wifi-fast
> and bufferbloat-combat in?

Yeah, if your link speed is within its capabilities. It can shape up to
~250 Mbps I think...

-Toke
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] looking for some testers this week

[Pete Heist]

> On Mar 13, 2019, at 12:20 AM, Dave Taht  wrote:
> 
> only 225/8-231/8 are opened up from the relevant reserved for
> multicast space by this patch series. They have always been unassigned
> addresses. I did not change the userspace IN_MULTICAST macro, but
> nearly nothing in userspace checks that.

So, for ar71xx generic om2p, I’m able to set up an AP/router with IP 225.1.2.1:

root@uniextap:~# ip addr show br-lan
8: br-lan:  mtu 1500 qdisc noqueue state UP 
qlen 1000
link/ether ac:86:74:10:26:30 brd ff:ff:ff:ff:ff:ff
inet 225.1.2.1/24 brd 225.1.2.255 scope global br-lan
   valid_lft forever preferred_lft forever

and pick up a DHCP address in that subnet from an STA:

root@uniextsta:~# ip addr show wlan0
5: wlan0:  mtu 1500 qdisc noqueue state UP 
qlen 1000
link/ether ac:86:74:03:0d:f2 brd ff:ff:ff:ff:ff:ff
inet 225.1.2.120/24 brd 225.1.2.255 scope global wlan0
   valid_lft forever preferred_lft forever
inet6 fe80::ae86:74ff:fe03:df2/64 scope link 
   valid_lft forever preferred_lft forever

and NAT traffic on that subnet to the Internet:

root@uniextsta:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=11.562 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=12.722 ms

root@uniextap:~# tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
18:50:32.290616 IP uniextap.lan > google-public-dns-a.google.com: ICMP echo 
request, id 1252, seq 0, length 64
18:50:32.300259 IP google-public-dns-a.google.com > 10.72.0.37: ICMP echo 
reply, id 1252, seq 0, length 64
18:50:33.291222 IP uniextap.lan > google-public-dns-a.google.com: ICMP echo 
request, id 1252, seq 1, length 64
18:50:33.302339 IP google-public-dns-a.google.com > 10.72.0.37: ICMP echo 
reply, id 1252, seq 1, length 64

Tires kicked. Anything else?___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Babel-users] althea presentation on isp in a box at nanog 76

[Juliusz Chroboczek]

> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> metric that allows for cryptocurrency traffic billing.

Justin, could you please document the private TLVs that you're using and
register them with IANA?  (I'm currently under pressure to make the TLV
allocation more onerous, and yours is a good example of why requiring an
RFC for every Babel extension is a bad idea.)

You're running Wireguard over Babel or the other way around?  Any issues
with that?

-- Juliusz
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] meanwhile... .home, finally has a home.arpa.

[Ted Lemon]

That is good feedback, if depressing.   I'm kind of in the same boat—I
really want to do some work on this for OpenWRT, but it hasn't come up to
the top of the stack yet.   The reason I was asking is that when I've said
at IETF that I don't think HNCP is actually complete yet, I get a lot of
rotten tomatoes from the authors.

On Tue, Oct 23, 2018 at 11:09 AM Dave Taht  wrote:

> On Mon, Oct 22, 2018 at 9:13 PM Ted Lemon  wrote:
> >
> > On Oct 22, 2018, at 11:51 PM, Dave Taht  wrote:
> >
> > This is one of those endless bikesheds I'd totally given up on. Thx ted!
> >
> >
> > If you're feeling like an adventure, you might find the latest draft of
> the homenet naming architecture entertaining.
> >
> >
> https://github.com/ietf-homenet-wg/simple-naming/blob/master/draft-ietf-homenet-simple-naming.txt
>
> Read it just now. this is an ietf notion of "simple", yes?
>
> >
> > I decided to keep going on it since the submission deadline was
> extended, so it's pretty close to feature complete except for the HNCP part.
> >
> > I'm curious: are you using HNCP on your networks?
>
> Mikael is the sole survivor here, so far as I know.
>
> 2 years back, I gave up on deploying ipv6 any further than the lab.
> Getting dynamic ipv6 reliably into my production network... I gave up.
> I asked for a static allocation from comcast, haven't heard back yet.
>
> As examples that persist, dhcpv6-pd renewals seem to be broken in
> openwrt still, so I get a bunch of prefixes... and a few a days later
> they vanish. I get static routes to nowhere, often, out of that. And:
> with only a /60 available, I also run out of prefixes to allocate if
> something reboots at the wrong time at the wrong place, and so on.
>
>
> >
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Ecn-sane] three new internet drafts regarding SCE

[Luca Muscariello]

Remote attendance is free of charge but you have to register to be able to
access.

https://www.ietf.org/registration/ietf105/remotereg.py



On Wed, Jul 17, 2019 at 3:13 PM Dave Taht  wrote:

> IETF 105 runs from July 20-27th in Montreal.
>
> https://datatracker.ietf.org/meeting/105/agenda/
>
> tsvwg meets thursday morning 10-12, and friday 12:20-
>
> Remote attendance via videconferencing tools is straightforward. There
> are of course dozens of other wg meetings of possible interest, in my
> case, I'm still tracking babel's progress through the ietf, in
> particular, and I always try to
> check in on iccrg, also in case anything interesting comes up.
>
> Since not all members of our mailing lists are on the relevant tsvwg
> or tcpmwg  mailing lists, here are some drafts
> from those working on the SCE front (I'm not, but I do read things)
> for aqm and transport enhancements.
>
> https://tools.ietf.org/html/draft-grimes-tcpmwg-tcpsce-00
>
> https://tools.ietf.org/html/draft-morton-tsvwg-sce-00
>
> https://tools.ietf.org/html/draft-heist-tsvwg-sce-one-and-two-flow-tests-00
>
> I would have liked it if the the actual scripts, & flent data files
> were published and referenced in this last draft. (I think the
> pictures were published on some other email thread (?), and I look
> forward to the slides) My own
> (eventual) contribution to this work might be on the wifi front, but
> neither l4s or sce are baked enough yet to bother trying,
> IMHO. My analysis of the battlemesh fq_codel + ecn over wifi data I
> hope to finish this week, but I'll find an other outlet for
> publication. (smallest subset of observations is that we can reduce
> the codel target to 6ms on wifi networks that have powersave disabled,
> and that serious 802.11e queue use still massively sucks. details to
> come later)
>
> There are many, many, many other drafts in progress in tsvwg, of note
> might be:
>
> https://tools.ietf.org/id/draft-white-tsvwg-lld-00.txt
>
> https://tools.ietf.org/id/draft-white-tsvwg-nqb-02.txt
>
> In addition to the perpetually revised l4s related ones.
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> ___
> Ecn-sane mailing list
> ecn-s...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] fcc initial comments due sept 10

[Livingood, Jason]

Hi David - See some comments inline below. Hope you are well!
- Jason

On 8/10/18, 11:35 PM, "Bloat on behalf of dpr...@deepplum.com" 
 wrote:

Of course, the folks who wanted to see Internet connectivity spread and 
restructure the economic structure of communications decided not to look this 
"gift horse" in the mouth. Congress was going to fund rollouts of Cable TV (new 
and upgrades), and as a side effect, maybe some better Internet.

[JL] How and when did Congress fund DOCSIS network investments (either in 
2007-2008 or before)? Do you have any citations for this? 

The architecture of the Cable TV service distributes *every* channel 
simultaneously to every endpoint, consuming outrageous bandwidth compared to 
the 25 Mb/s diddly squat usage on the "broad band" cable or fiber.

[JL] This is changing more rapidly than you may realize, through a combination 
of factors. One is that most cable companies have been deploying IP-based set 
tops for several years, which enables more unicast delivery using IP, which 
frees up channels for DOCSIS Internet services (otherwise where would cable 
companies find the channel space to 24 or 32 downstream channels plus D3.1 OFDM 
compared to 4 or 8 downstreams a few years ago?). In addition, on the demand 
side, customers increasingly watch programs via their DVR or On Demand library 
rather than watching something live (typical exceptions being sports, news, 
weather, etc.). Finally, they are also watching increasingly on non-set-top 
devices like tablets and laptops.

So, in responding to this notice by the FCC of a "standard" for Broadband, 
just realize that you might want to question the entire proposition that 
Broadband is a thing that needs a standard.

[JL] I thought it was just the usual annual NOI on the definition of "advanced 
telecommunications capabilities". The use of the word "broadband" just appears 
to be shorthand for that. See 
https://docs.fcc.gov/public/attachments/FCC-18-119A1.pdf which says:

"Section 706 of the Telecommunications Act of 1996, as amended (1996 Act), 
requires us to determine and report annually on “whether advanced 
telecommunications capability is being deployed to all Americans in a 
reasonable and timely fashion.”FN1
 
FN1 47 U.S.C. § 1302(b). For simplicity in past inquiries, the Commission has 
sometimes used the term “broadband” to refer to “advanced telecommunications 
capability.” However, “advanced telecommunications capability” is a statutory 
term with a definition that is narrower than the term “broadband.” See 47 
U.S.C. § 1302(d)(1) (“The term ‘advanced telecommunications capability’ is 
defined, without regard to any transmission media or technology, as high-speed, 
switched, broadband telecommunications capability that enables users to 
originate and receive high quality voice, data, graphics, and video 
telecommunications using any technology.”). As this definition makes clear, 
while all services providing advanced telecommunications capability are 
“broadband,” not all broadband services provide advanced telecommunications 
capability."

What "high speed" means in the Internet is a much more meaningful question, 
but that's a truth in advertising question. And it really has to do with 
"response time" more than any guarantee of an "up to" speed. How long does it 
take Netflix to buffer enough content to play the rest of the show without 
interruption? (that's why you need burst rate) How fast do your trigger pulls 
on your multiperson VR shooter get reflected on all the other players' displays?

People do pay more for that. But the standard of what "that" is - high 
speed, very high speed, ... isn't just 25 Mb/sec. It's also bufferbloat, for 
example.

THink about that, and don't get sucked into comments on what Cable TV 
should do for minimal Internet quality.

[JL] Putting aside all the stuff about cable and broadband, it seems your 
bottom line is that buffer bloat, latency, and latency under load are also 
meaningful and should be considered in addition to speed/throughput measures in 
this definition. That seems a worthwhile technical question to raise.






___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] closing up my make-wifi-fast lab

[Luca Dionisi]

Godspeed for your next project, Dave.

On Fri, Aug 24, 2018 at 10:11 PM Dave Taht  wrote:

> All:
>
> It is with some regret that I am announcing the closing of my
> make-wifi-fast lab at the end of this month.
>
> Over the years we have relied on the donation of lab space from
> ISC.org, georgia tech, the LINCs, and the University of Karstadt and
> elsewhere - but my main base of operation has always been the
> "yurtlab", in a campground deep in the los gatos hills where I could
> both experiment and deploy wifi fixes[0] at scale. CeroWrt, in
> particular, was made here.
>
> During the peak of the make-wifi-fast effort I rented additional space
> on the same site, which at peak had over 30 routers in a crowded
> space, competing. Which I (foolishly) kept, despite the additional
> expense. Having heat in the winter and aircond in the summer was
> helpful.
>
> With ongoing donations running at $90/month[1] - which doesn't even
> cover bufferbloat.net's servers in the cloud - my biggest expense has
> been keeping the lab at lupin open at $1800/mo.
>
> I kept the lab going through the sch_cake and openwrt 18.06 release
> process, and I'm now several months behind on rent[3], and given how
> things have gone for the past 2 years I don't see much use for it in
> the future. Keeping it open, heated and dry in the winter has always
> been a problem also. I'm also aware of a few larger, much better
> equipped wifi labs that have thoroughly tested our "fq_codel for
> wifi"[4] work that finally ends the "wifi performance anomaly". it's
> in multiple commercial products now, we're seeing airtime fairness
> being actually *marketed* as a wifi feature, and I kind of expect
> deployment be universal across all mediatek mt76, and qualcomm ath9k
> and ath10k based products in the next year or two. We won, big, on
> wifi. Knocked it out of the park. Thanks all!
>
> Despite identifying all kinds of other work[5] that can be done to
> make wifi better, no major (or even minor) direct sponsor has ever
> emerged[2] for the make-wifi-fast project. We had a small grant from
> comcast, a bit of support from nlnet also, I subsidized what I did
> here from other work sources, toke had his PHD support, and all the
> wonderful volunteers here... and that's it.
>
> Without me being able, also, to hire someone to keep the lab going, as
> I freely admit to burnout and PTSD on perpetually reflashing and
> reconfiguring routers...
>
> I'm closing up shop here to gather enough energy, finances, and time
> for the next project, whatever it is.
>
> The make-wifi-fast mailing list and project will continue, efforts to
> make more generic the new API also, and hopefully there's enough users
> out there to
> keep it all going forward without the kind of comprehensive testing I
> used to do here.
>
> If anyone feels like reflashing, oh, 30 bricked routers of 8 different
> models, from serial ports (in multiple cases, like the 6 uap-ac-lites,
> via soldiering on headers), I'll gladly toss all the extra equipment
> in the lab in a big box and ship them to you. Suggestions for a
> suitable donation target are also of interest.
>
> The yurtlab has been an amazing, totally unique, unusual (and
> sometimes embarrassing [6]) place to work and think, but it's time to
> go.
>
> Perhaps I'll convince my amazingly supportive landlord to let me leave
> behind a plaque:
>
> "On this spot bufferbloat on the internet and in WiFi was fixed,
> 2011-2018".
>
> Sincerely,
> Dave Taht
>
> [0] https://lwn.net/Articles/705884/ "How we made wifi fast again"
> [1] https://www.patreon.com/dtaht
> [2] Like adrian chadd's infamous flameout - I too, give up on wifi.
> There's gotta be some other tech worth working on. What we shipped is
> "good enough" to carry a few years though.
> [3] This is not a passive-aggressive request for help making rent next
> month, given all the other problems I have, it's best to close up shop
> while I look for a new gig.
> [4] https://arxiv.org/pdf/1703.00064.pdf "ending the wifi anomaly"
> [5]
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
> [6]
> https://www.cringely.com/2012/10/01/clothing-may-be-optional-but-bufferbloat-isnt/
> ___
> Bloat mailing list
> bl...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Babel-users] althea presentation on isp in a box at nanog 76

[Benjamin Henrion]

On Thu, Jun 20, 2019 at 7:11 AM Dave Taht  wrote:
>
> https://www.youtube.com/watch?v=G4EKbgShyLw
>
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> metric that allows for cryptocurrency traffic billing.

Is it hackable?

Like could you cheat on the amount of traffic transmitted?

--
Benjamin Henrion (zoobab)
Email: zoobab at gmail.com
Mobile: +32-484-566109
Web: http://www.zoobab.com
FFII.org Brussels
"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."
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] beating the drum for BQL

[Pete Heist]

> On Aug 23, 2018, at 12:51 PM, Mikael Abrahamsson  wrote:
> 
> On Thu, 23 Aug 2018, Pete Heist wrote:
> 
>> Thanks for sharing, this is really useful, raising awareness where it 
>> matters. Quite a bit of content... :)
>> 
>> Ubiquiti needs some work getting this into more of their products (EdgeMAX 
>> in particular). A good time to lobby for this might be, well a couple months 
>> ago, as they’re producing alpha builds for their upcoming 2.0 release with 
>> kernel 4.9 and new Cavium/Mediatek/Octeon SDKs. I just asked about the 
>> status in the EdgeRouter Beta forum, in case it finds the right eyes before 
>> the release:
>> 
>> https://community.ubnt.com/t5/EdgeRouter-Beta/BQL-support/m-p/2466657 
>> 
>> 
>> https://community.ubnt.com/t5/EdgeMAX-Beta-Blog/New-EdgeRouter-firmware-2-0-0-alpha-2-has-been-released/ba-p/2414938
>>  
>> 
> 
> My only experience with these devices is the Edgerouter 3/5/X, and they have 
> very low performance if you disable offloads (which you need to do to enable 
> AQM) and run everything in CPU, around 100 megabit/s of uni-directional 
> traffic.

I have a similar experience with my ER-X- with soft rate limiting (the only 
thing allowed in the UI), 120-140Mbit is the upper limit.

> Do they have other platforms where this would actually matter?

One can add fq_codel or Cake from the command line (many are doing so), and 
some may be using 100Mbit Ethernet. In that case, BQL could be useful even on 
these devices when run at line rate, without soft rate limiting.

I’m also assuming that their higher-end products are capable of fq_codel at 1 
Gbit, and that some may use those devices at line rate. Any time this is the 
case, even if only during bursts, BQL would be useful, I suppose...
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] looking for some testers this week

[Pete Heist]

> On Mar 12, 2019, at 10:24 PM, Pete Heist  wrote:
> 
> Yes, this rfc and patch are off the deep end. :)

Meant that in a good way. The potential new IP space is enormous.
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Georgios Amanakis]

Yes. Unshaped it is ~20mbit, the tests were ran with cake shaping at 80%.

On Sat, Jul 21, 2018, 2:20 PM Dave Taht  wrote:

> hmm? you only have 15mbits down?
> On Sat, Jul 21, 2018 at 11:18 AM Georgios Amanakis 
> wrote:
> >
> > On Sat, 2018-07-21 at 10:47 -0700, Dave Taht wrote:
> > > for reference can you do a download and capture against flent-newark,
> > > while using the ping test?
> > >
> >
> > New data, this is what I did:
> >
> > 1) Started a ping test using the flent-fremont server.
> > 2) Started a tcp_8down test (for 15 seconds) using the flent-newark
> > server. I chose tcp_8down since fast.com was also using 8 flows.
> > 3) Captured on the host where the above tests ran.
> >
> > It seems to be working as expected here.
> >
> > Georgios
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] Off-topic: What to Make of the U.K.’s New Code of Practice on Internet-of-Things Security

[David Collier-Brown]

The definition of "faulty" is, fortunately, "settled law", probably 
dating back as far as the era of Hanseatic League (a particular interest 
of mine: the league was the invention of a packet 
international-network-thingie where the packets were sailing ships).


In Canada, the courts would simply follow the legislation and precedent, 
and the only way you could get off is by trying to interpret the caselaw 
to say you were different.


For an example of the difficulty of weaseling out, see [6-8] in 
https://www.canlii.org/en/nl/nlca/doc/1995/1995canlii9847/1995canlii9847.html?searchUrlHash=AQAOZmF1bHR5IHByb2R1Y3QAAQ&resultIndex=2


As a more relevant example of a decision, I'd expect that an access 
control system on a router with a hard-coded back door would be found 
"not suitable for the purpose sold", and expose the authors to an order 
for replacement. Even in current Canadian law, that particular example 
(re Cisco routers) would put them on the wrong side of the definition of 
fraud, and subject to being ordered to make it right.


Individual countries will vary in the details: in the US, different 
States could even differ, but in broad strokes


 * it must be suitable for the purpose sold, at any age
 * it must not fail before it reaches a specified age
 * it may well have undiscovered faults, but the vendor must make them
   right once found, subject to age


--dave
Amusingly, I also found a Canadian case about concealing a backdoor 
password, at [204] in 
https://www.canlii.org/en/on/onsc/doc/2009/2009canlii64185/2009canlii64185.html?searchUrlHash=AQAIYmFja2Rvb3IAAQ&resultIndex=9



On 2019-01-19 9:16 a.m., Dave Taht wrote:

There should probably be a list for political issues somewhere.

I am liking various proposals for improving device security like this
and the german router thing (https://www.ccc.de/de/updates/2018/risikorouter
) but missing from all these requirements is

"the right to repair"


" The code also asks manufacturers to disclose a minimum timeline for
  software updates and makes provisions for devices or components that
  cannot be updated through software, noting that the manufacturer can
  replace them—in fact, under U.K. law they must repair or replace faulty
  products for 6 years."

oh, I so wish we had that in the US. But what qualifies as faulty?




David Collier-Brown  writes:


I'm pleased to have seen this discussion on lawfare,
https://www.lawfareblog.com/what-make-uks-new-code-practice-internet-things-security

Instead of proposing frozen, unmaintainable devices, they expect
updates, and note that a major UK retailer pulled an insecure product
because it couldn't be updated.

--dave

 Forwarded Message 

  Subject:  What to Make of the U.K.’s New Code of Practice on
Internet-of-Things Security
  Date: Tue, 15 Jan 2019 10:26:40 -0500
  From: Jack Watson <>, Beau Woods <>

What to Make of the U.K.’s New Code of Practice on Internet-of-Things
Security

Across the globe, the rapid pace of technology development has made it
difficult to govern emerging tech effectively. Policymakers struggle
with several primary issues, including knowledge of the subject
matter, the potential impact on the pace of innovation, and the rapid
rate of adoption. The United Kingdom’s “Secure by Design” program
intends to meet these challenges, as well as take steps to position
the country as “best place in the world to do digital business.” As
Brexit continues, and Britain’s finance sector looks to jump ship,
such a goal is as timely as it is necessary. At its core, the program
will create powerful tools for policymakers, industry, consumers,
retailers, and others. The final U.K. “Code of Practice” for
internet-of-things security released on Oct. 14, 2018 by the
Department for Digital, Culture, Media and Sport in conjunction with
GCHQ’s National Cyber Security Centre offers one of the clearest
policy positions articulated yet by any national government. It sets
out a technically literate policy that will drive manufacturers to
innovate more efficient ways to protect internet-connected consumer
devices, through market and regulatory incentives.

By its own terms, the code of practice—and, more broadly, the Secure
by Design program—seeks to “support all parties involved in the
development, manufacturing and retail of consumer [internet-of-things
devices].” To support this goal, the release is accompanied by
awareness and educational documents, technical standards guidance, and
an implementation plan, all of which show the U.K.’s commitment to a
leadership role in securing the internet of things. The fact that the
code is translated into eight languages, including Mandarin, Korean,
French, German and Japanese, is crucial in showing that the U.K.
intends to be a global trendsetter, but it also reflects the global
nature of the markets, supply chains and security threats, as well as
resilience and confidence in consumer internet-of-things dev

Re: [Cerowrt-devel] [Ecn-sane] three new internet drafts regarding SCE

[Rodney W. Grimes]

> IETF 105 runs from July 20-27th in Montreal.
> 
> https://datatracker.ietf.org/meeting/105/agenda/
> 
> tsvwg meets thursday morning 10-12, and friday 12:20-
> 
> Remote attendance via videconferencing tools is straightforward. There
> are of course dozens of other wg meetings of possible interest, in my
> case, I'm still tracking babel's progress through the ietf, in
> particular, and I always try to
> check in on iccrg, also in case anything interesting comes up.
> 
> Since not all members of our mailing lists are on the relevant tsvwg
> or tcpmwg  mailing lists, here are some drafts
> from those working on the SCE front (I'm not, but I do read things)
> for aqm and transport enhancements.
> 
> https://tools.ietf.org/html/draft-grimes-tcpmwg-tcpsce-00
> 
> https://tools.ietf.org/html/draft-morton-tsvwg-sce-00
> 
> https://tools.ietf.org/html/draft-heist-tsvwg-sce-one-and-two-flow-tests-00

There is actually a 4th related draft which is a new Q algorithm:

https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing

> I would have liked it if the the actual scripts, & flent data files
> were published and referenced in this last draft. (I think the
> pictures were published on some other email thread (?), and I look
> forward to the slides)

We are working towards this, part of the problem is the tools
and the data was evolving at a pace faster than we could publish them.

We have now validated that an independent person can build,
install and run a SCE capable linux kernel avaliable at:

https://github.com/chromi/sce

Note that this is evolving code, so expect to see updates,
as well as complete notes on new sysctl's avaliable to
enable/disable features for testing purposes.

> My own
> (eventual) contribution to this work might be on the wifi front, but
> neither l4s or sce are baked enough yet to bother trying,
> IMHO. My analysis of the battlemesh fq_codel + ecn over wifi data I
> hope to finish this week, but I'll find an other outlet for
> publication. (smallest subset of observations is that we can reduce
> the codel target to 6ms on wifi networks that have powersave disabled,
> and that serious 802.11e queue use still massively sucks. details to
> come later)
> 
> There are many, many, many other drafts in progress in tsvwg, of note might 
> be:
> 
> https://tools.ietf.org/id/draft-white-tsvwg-lld-00.txt
> 
> https://tools.ietf.org/id/draft-white-tsvwg-nqb-02.txt
> 
> In addition to the perpetually revised l4s related ones.
> 
> -- 
> 
> Dave T?ht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740

-- 
Rod Grimes rgri...@freebsd.org
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] apu2 sqm/htb issue + a minor win for speeding up fq_codel itself

[Pete Heist]

Cool, well I for one would like to see the APU be able to handle higher speeds, 
for FreeNet’s backhaul, at least. Although frankly, I’ve not definitively 
witnessed any significant bloat in their backhaul yet with production traffic.

A good number of their routers are still ALIX 
(https://www.pcengines.ch/alix2d2.htm ), 
all of which are on an upgrade list. These don’t do hfsc + sfq on kernel 2.6.26 
much beyond about 70 Mbit. Not a problem to focus on… :)

> On Sep 4, 2018, at 11:16 PM, Dave Taht  wrote:
> 
> my guess is that burst and cburst should scale roughly as a function
> of the bytes that can fit into 1ms.
> On Tue, Sep 4, 2018 at 2:14 PM Dave Taht  wrote:
>> 
>> making htb's cburst and burst parameters 64k gets the APU2  up to
>> where it can shape 900mbits. 3 ksoftirq handlers start getting cpu
>> time, and we end up 54% idle to achiefe that.
>> 
>> I should really go around running my own old code. I was deeply
>> involved in sqm when we still had to run at sub 200mbit levels. since
>> then it's been
>> mostly tbf (burst 64k) + fq_codel or cake, and me ignoring various bug
>> reports about it not scaling well enough at higher rates.
>> On Tue, Sep 4, 2018 at 12:59 PM Dave Taht  wrote:
>>> 
>>> less than scientifically (via monitoring top) - on the apu2
>>> 
>>> 100Mbit sqm (htb + fq_codel)
>>> 
>>> fq_codel_mainline | fq_codel_fast
>>> idle 78.8| 83.5 |
>>> si20   | 16.1 |
>>> 
>>> Yea! But:
>>> 
>>> 900Mbit sqm (htb + fq_codel)
>>> 
>>> fq_codel_mainline | fq_codel_fast
>>> idle 74.4| 74.4 |
>>> si25   | 25.1 |
>>> 
>>> Here: completely bottlenecked on ksoftirqd - and I only get 340Mbits
>>> out of the 900mbit setting. quantum 96k and burst of 15000. Haven't
>>> fiddled with higher values yet...

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] mo bettah open source multi-party videoconferncing in an age of bloated uplinks?

[Anthony Minessale II]

Working on this a bit right now. I have the controls to tell the browser to
send less manually but not auto. We might add transport-cc as google seems
to have picked that one. We can have you on a call sometime to test.



On Fri, Mar 27, 2020 at 12:27 PM Dave Taht  wrote:

> sort of an outgrowth of this convo:
>
> https://lwn.net/SubscriberLink/815751/786d161d06a90f0e/
>
> I imagine worldwide videoconferencing quality could be much better if
> we could convince more folk to
> finally install sqm or upgrade to a working docsis 3.1 solution, etc.
> Maybe some rag somewhere will finally pick up on bufferbloat solutions
> and run with it? Or we can write some articles? Or reach out to school
> systems? Or?
>
> I've been fiddling with jitsi, and am about to give freeswitch a try.
> Last I looked freeswitch's otherwise pretty nifty conference bridge
> didn't dynamically adjust at all due to e2e signalling, but that was
> years ago. (?)
>
> I have to admit that p2p multiparty videoconferencing seems more
> plausible in a de-bufferbloated age, but
> haven't explored what tools are available. (?)
>
> There's also been this somewhat entertaining convo on the ietf mbone
> list:
> https://mailarchive.ietf.org/arch/msg/mboned/2thFQk_IYn38XCZBQavhUmOd6tk/
>
> Around me there has been this huge interest in "streaming". The user
> agreement for these (see restream.io's) is scary - and the copyright
> police have control... but I am very happy to report that even a
> couple really lousy long distance fq_codel'd ath9k links work *really*
> well (with facebook's implementation), where a non fq_codeled link
> (ath10k) failed miserably... and setting up a reflector in nginx also
> failed miserably.
>
> Anyone working on the ath10k AQL backport for openwrt as yet?
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
>


-- 

[image: Inline image 1]

Anthony Minessale II | President

FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045


Email: an...@freeswitch.com

Mobile: +12623098501

Website: https://www.FreeSWITCH.com 

[image: color-facebook-96.png] [image:
color-twitter-96.png]

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[bkil]

I've only skimmed through, but as I see it, many points have already been
addressed. TV went digital, large parts of the spectrum freed up for other
purposes while allowing to transmit in local whitespaces where available:

https://en.wikipedia.org/wiki/IEEE_802.11af#Spectrum_regulation

As a different note, there's also research towards the direction of fully
and efficiently utilizing the TV spectrum everywhere:

https://en.wikipedia.org/wiki/WiB_(Digital_Terrestrial_Television)

They say that CB, despite its numerous channels demised due to overuse and
illegal range extensions.
https://en.wikipedia.org/wiki/CB_radio#21st-century_use

Wifi is already pretty crowded in urban areas, but it is only saved by its
poor propagation. Imagine what happened if people got their hands on UHF
that propagates very well even using very cheap transmitters without any
strings attached. Many would definitely attempt to set up their very own
town-wide stations, happily spoiling the fun for everyone else.

It is interesting that a majority of people who I talk to already ask what
needs to be done or bought if one wants to crank up the power on wifi so
every corner in their house gets excellent coverage. It rarely occurs to
them that instead of trying to beef up a router, they could simply buy two
cheap & standard ones and connect them via cable (/wireless) for a stable
AP (/repeater) configuration. This seems to be the nature of human thinking.

https://en.wikipedia.org/wiki/Tragedy_of_the_commons

On Sun, Aug 26, 2018 at 2:26 PM David P. Reed  wrote:

> Baran: I got the year wrong. I remember it as 1993, but it was 1994 CNGN
> speech he made, which is resurrected here:
> https://www.eff.org/pages/false-scarcity-baran-cngn-94
>
> Paul was educated in EE, as was I. So radio made sense to him. Unlike kids
> brought up on the idea that bits are and must be physically discrete
> spatial and temporal mechanical things.
>
> You know, one can have 1/10 of a bit of information, and store it in 1/10
> of a bit of storage. Or transmit a symbol that passes through local noise
> and comes out the other side uncorrupted.
>
> But kids trained in fancy CS depts. assume that bits require clear, empty,
> noiseless, pristine paths. Pure Bullshit. But CS and now many EE depts. and
> the FCC all proselytize such crap
>
> So scarcity is inventedand sustained.
>
> There is a reigning Supreme Court opinion, the law of the land, that says
> that there is by law a "finite number" of usable frequencies, and only one
> transmitter can be allowed to use it at a time. Like legislating that pi =
> 3 in a state, to make math easier.
>
> Except it is totally designed to create scarcity. And the State/Industry
> Nexus maintains it at every turn. It's why lunatic economists claim that
> spectrum is a form of property that can be auctioned. Like creating
> property rights to each acre of the sea, allowing owners to block shipping
> by buying a connected path down the mid Atlantic.
>
> We live in a Science Ignorant world. Intentionally. Even trained pH D.
> Engineers testify before the FCC to preserve these lies.
>
> Yeah, I sound nuts. Check it out.
>
>
> -Original Message-
> From: "Dave Taht" 
> Sent: Sat, Aug 25, 2018 at 5:22 pm
> To: dpr...@deepplum.com
> Cc: bloat-annou...@lists.bufferbloat.net, "bloat" <
> bl...@lists.bufferbloat.net>, "Make-Wifi-fast" <
> make-wifi-f...@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] closing up my make-wifi-fast lab
>
> On Sat, Aug 25, 2018 at 1:04 PM David P. Reed  wrote:
> >
> > WiFi is a bit harder than IP. But you know that.
> >
> > I truly believe that we need to fix the phy/waveform/modulation space to
> really scale up open wireless networking capability. LBT is the basic bug
> in WiFi, and it is at that layer, melow the MAC.
> >
> > I have tried for 20 years now to find a way to begin work at that
> project, by the way. There is also no major donor anywhere to be found for
> that work. Instead, any funds that seem to be appearing get attacked and
> sucked into projects that miss the point, being controlled by folks who
> oppose openness (e.g. WISPs wanting exclusive ownership of a market, such
> as so called SuperWiFi or whitespaces). I did once come close to a useful
> award when I was at MIT Media Lab, from NSF. But after the award, the
> funding was cut by 90%, leaving just enough to support a Master's thesis on
> co-channel sharing, using two 1st Gen USRPs. Using my own funds, spare
> time, and bubblegum and baling wire, I've slowly begun work on extra
> wideband FPGA based sounding-centric sharing in the 10 GHz Ham band. (500
> MHz wide modulation), where I can self certify multiple stations in a
> network.
> >
> > But the point is, I've failed, because there is less than zero support.
> There is active opposition, on top of cluelessness.
> >
> > Paul Baran tried in 1993 to push forward a similar agenda, famously. 99%
> of his concepts died.
>
> Cite?
>
> O

Re: [Cerowrt-devel] [Bloat] Ubiquiti Launches a Speed Test Network

[Pete Heist]

> On Sep 7, 2019, at 2:02 PM, Sebastian Moeller  wrote:
> 
> Hi Pete,
> 
> If the PayPal ad of an irtt packet would contain the requested DSCP as ascci 
> string (maybe starting with a string like "DSCP: 46: 101110 (EF)" in the 
> first few bytes of the payload would make confirming bleaching/remapping from 
> packetdumps relatively convenient, say just by looking at a packet in 
> Wireshark and comparing the IP headers DSCP value with the string in the 
> payload. Sure that is not automated, but would be great in at least allowing 
> to test for bleaching in the packets received from a irtt server
> 
> But, as much as I would like that feature, I believe the total audience will 
> be quite small
> 
> Best Regards
> Sebastian

You probably noticed, but it’s possible to fill the whole payload with the dscp 
byte, although the server has to allow that to put it in replies (requests can 
always contain it), for example:

irtt server --allow-fills=“*"

irtt client --dscp=0x10 -l 256 --fill=pattern:10 --sfill=pattern:10 localhost

If you still want the payload to be mostly random, I could potentially add a 
new fill mode which fills first with some arbitrary bytes (or a string) then 
the rest is random. I think in the case of flent, the irtt runner fills with 
random, but this only applies when there’s actually a payload (i.e. for the 
voip tests).
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Luca Muscariello]

Jonathan,

Not that giant handwaving though.
IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The almost
is necessary as it operates in 2.4/5Ghz bands.
Similar to what you describe, and is coming very soon in shipping products.

RTS/CTS is still a LBT to create a window where TDM can be done.
I don't yet see how a non private spectrum can be shared  w/o LBT.

On the other hand, medium sharing is one thing, the other thing is
capacity.
There is no way to efficiently share a medium if this is used close to its
theoretical capacity.

Capacity as #of stations per band including #SSID per band. Today scaling
can be achieved
with careful radio planning for spatial diversity or dynamic bean forming.

When you approach capacity with WiFi you only see beacon traffic and almost
zero throughput.
Cannot forget Mobile World Congress where you can measure several thousands
of SSIDs on 2.4
and several hundreds of SSID in 5GHz. But even LTE was very close to
capacity.

Dave,
Having air time fairness in open source is a significant achievement. I
don't see a failure.

Luca


On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton 
wrote:

> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
> wrote:
> >
> > Curious to how LBT can be solved at the PHY level and if the potential
> solution sets preserve the end to end principle.
>
> The usual alternatives include TDM, usually coordinated by a master device
> (eg. the AP); full-duplex operation via diplexers and/or orthogonal coding;
> and simply firing off a packet and retrying with exponential backoff if an
> acknowledgement is not heard.
>
> TDM and diplexing are already used by both DOCSIS and LTE.  They are
> proven technology.  However, in DOCSIS the diplexing is greatly simplified
> by the use of a copper channel rather than airwaves, and in LTE the
> diplexer is fitted only at the tower, not in each client - so the tower can
> transmit and receive simultaneously, but an individual client cannot, but
> this is still useful because there are many clients per tower.  Effective
> diplexers for wireless are expensive.
>
> Orthogonal coding is already used by GPS and, in a rather esoteric form,
> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
> GPS, it allows all of the satellites in the constellation to transmit on
> the standard frequency simultaneously, while still being individually
> distinguishable.  The data rate is very low, however, since each
> satellite's signal inherently has a negative SNR (because there's a dozen
> others shouting over it) - that's why it takes a full minute for a receiver
> to get a fix from cold, because it simply takes that long to download the
> ephemeris from the first satellite whose signal is found.
>
> A future version of wifi could reasonably use TDM, I think, but not
> diplexing.  The way this would work is that the AP assigns each station
> (including itself) a series of time windows in which to transmit as much as
> they like, and broadcasts this schedule along with its beacon.  Also
> scheduled would be windows in which the AP listens for new stations,
> including possibly other nearby APs with which it may mutually coordinate
> time.  A mesh network could thus be constructed entirely out of mutually
> coordinating APs if necessary.
>
> The above paragraph is obviously a giant handwave...
>
>  - Jonathan Morton
>
> ___
> Bloat mailing list
> bl...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[bkil]

Yes, I've read that part in the past. These are very good rules of
thumb, but there are many inefficiencies to cope with.

Note that not all wireless users are "rude" on purpose. It's just that
if you want to keep in touch with your relatives in the nearby town,
you use the minimal needed power for the given circumstances that
happens to be a large amount (point to point).

1a.
Let's focus on a point to point link first. Omni antennas would
trivially interfere with our own neighborhood as well while working a
long link. However, because not everyone has roof access, space for a
large aerial or money for an expensive one, using an omni would be
considered a local optimum for many.

1b.
Let's assume that we are a good citizen using more expensive highly
directional antennae and we live at the perimeter. Considering that
the reception angle of the most practical ones should be 10-20
degrees, this probably easily illuminates the perimeter of the
neighboring town. That wouldn't be deadly interference from that
distance, but it means that it's not scalable in the sense that not
everyone living at the perimeter could communicate with their
respective relative in the neighboring town. It would need a high
level of sophistication to achieve that. It would be much more
efficient and cost effective if these people cooperated and pooled in
resources to build only a handful of well-placed high power
transcievers that they digitally shared with each other using low
power and inexpensive last mile access technologies. But as the old
saying goes, "The common horse is worst shod." So it is cleanest if we
simply pay for equipment and maintenance, and a new telco is born.
Then as competition intensifies, the spectrum gets clogged up, etc.

1c
If we aren't fortunate enough to live at the perimeter, we need to
cooperate with hops towards the perimeter. It is energetically the
most efficient to have directional links between each of them, but
that requires 2-3 antennae at each node. The ones at the perimeter
definitely need at least two. For one who lives at the perimeter and
only communicates with the neighboring town, it is a local optimum to
not purchase and operate two sets of antennae, cables, radios and
other tools. Without incentives, taking this to the extreme creates a
disconnected ring of perimeter around the town who point outwards. So
in worst case, ones in the middle would again need to up their power
again to work the distance.

2.
To achieve hop optimization, have we reached a level of social
sophistication and digital literacy where we can mesh with everything
and anyone in sight? I feel that to be a stretch, but let's pretend
that we have. Now the "feasible" part is still problematic.
Let's stick with the above scenario of inter-town links or sparsely
populated areas. If there is nobody to mesh with, we need to
artificially deploy and maintain intermediate nodes for this purpose.
Who will pay for this? If nobody, it is not feasible. See above point.
The local optimum of each user is to not deploy intermediate nodes,
and we have reached the tragedy of the commons again.

And we didn't even consider "rude" users analogue to an uninvited
guest who gobbles all your snacks when dropping by. These are only a
minority, but they take plenty. Though UWB wasn't there yet in 1994,
it's feasible today. Just imagine if a school deployed a 1GHz UWB
transciever on UHF to stream their backups or research data all day
over the air because it is less expensive (free) compared to cables.
It would not be feasible to peer with any intermediate hop because
nobody has such expensive and advanced hardware, so they'd happily
operate a point to point link to the nearby town (or partner
institution?). That would definitely spoil the fun for many along the
route and no amount of LBT can fix that. Also they could have decide
to use >100GHz instead, but there is no incentive if the whole
spectrum is free, as higher frequencies propagate worse and equipment
costs more.

So all in all, without incentives, system spectral efficiency doesn't
come naturally - you have to work for it. Hard.
I'm not saying that we should give up, but it takes much more than a
few sentences to come up with rules that really work in real life
situations when scaled up. There are pro and contra in many methods of
spectrum allocations, no doubt about that, but I don't feel that there
exists one clear "best" method that we are purposefully neglecting.

Of course at the same time, scalable unregulated alternatives do
exist, but we were talking radio above:
https://en.wikipedia.org/wiki/RONJA
https://en.wikipedia.org/wiki/Modulated_ultrasound
https://en.wikipedia.org/wiki/Sneakernet

On Thu, Aug 30, 2018 at 9:17 PM Bob McMahon  wrote:
>
> Minimizing power is rule #2 per Paul Banan.
>
> SOME KINDERGARTEN RULES (written in 1994)
>
>To take the fullest advantage of our new technology with its sharing
>of a common resource requires that our smart transmitters and
>  

Re: [Cerowrt-devel] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks?

[Toke Høiland-Jørgensen]

Dave Taht  writes:

>> So: 1. We really should rethink how timing-sensitive algorithms are
>> expressed, and it isn't gonna be good to base them on semaphores and
>> threads that run at random rates. That means a very different OS
>> conceptual framework. Can this share with, say, the Linux we know and
>> love - yes, the hardware can be shared. One should be able to
>> dedicate virtual processors that are not running Linux processes, but
>> instead another computational model (dataflow?).
>
> Linux switched to an EDF model for networking in 5.0

Not entirely. There's EDT scheduling, and the TCP stack is mostly
switched over, I think. But as always, Linux evolves piecemal :)

>> 2. EBPF is interesting, because it is more secure, and is again
>> focused on running code at kernel level, event-driven. I think it
>> would be a seriously difficult lift to get it to the point where one
>> could program the networked media processing in BPF.
>
> But there is huge demand for it, so people are writing way more in it
> than i ever ever thought possible... or desirable.

Tell me about it.

We have seen a bit of interest for combining eBPF with realtime, though.
With the upstreaming of the realtime code, support has landed for
running eBPF even on realtime kernels. And we're starting to see a bit
of interest for looking specifically at latency bounds for network
processing (for TSN), including XDP. Nothing concrete yet, though.

-Toke

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] looking for some testers this week

[Pete Heist]

> On Mar 12, 2019, at 4:19 AM, Dave Taht  wrote:
> 
> We already made the 240/4 address range work in openwrt in december.
> This patch adds in other formerly reserved address ranges:
> 
> 1) 
> https://github.com/dtaht/unicast-extensions/blob/master/patches/linux/0001-Allow-0.0.0.0-8-and-reduce-localnet-and-enable-225-2.patch
> 
> And it would be good to know if these addresses worked at all, on
> wifi, and through nat. We hit a limit in the netifd daemon last time.
> 
> (this is in relation to my moonshot talk at netdevconf. Which is
> totally a moonshot)

Yes, this rfc and patch are off the deep end. :) Then again, I haven’t used the 
Mbone since ’95 on IRIX, so I for one am ok with killing that dead.

Working on building my first OpenWRT image, ever. Does 32-bit mips do you much 
good?

I guess I’ll just see what I can do with two boxes somewhere on 224.0.0.0/4...

> 2) I hope we have the first SCE (
> https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00 )  patchset
> up fairly soon for fq_codel_fast (my out of tree mildly improved
> fq_codel), and sch_cake. Maybe Freebsd also, if anyone here runs that.

Looking forward to that patch (esp. Cake).

> There's one other thing I'd like to test, if at all possible - that's
> the new babel-hmac code.

Likely too much for me to digest before the conference.
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[bkil]

Full-duplex still needs some work, but there is definite progress:
http://www.ti.rwth-aachen.de/~taghizadehmotlagh/FullDuplex_Survey.pdf
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/TR-1.pdf
https://sing.stanford.edu/fullduplex/
https://spectrum.ieee.org/tech-talk/telecom/wireless/new-full-duplex-radio-chip-transmits-and-receives-wireless-signals-at-once
http://fullduplex.rice.edu/research/

On Mon, Aug 27, 2018 at 9:46 PM Jonathan Morton 
wrote:

> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon 
> wrote:
> >
> > I guess my question is can a WiFi transmitting device rely on primarily
> energy detect and mostly ignore the EDCA probability game and rather search
> for (or predict) unused spectrum per a time interval such that its digital
> signal has enough power per its observed SNR?   Then detect "collisions"
> (or, "superposition cases" per the RX not having sufficient SINR) via
> inserting silent gaps in its TX used to sample ED, i.e. run energy detect
> throughout the entire transmission?  Or better, no silent gaps, rather
> detect if there is superimposed energy on it's own TX and predict a
> collision (i.e. RX probably couldn't decode its signal) occurred?  If
> doable, this seems simpler than having to realize centralized (or even
> distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
> token rings, etc. and not require media access coordination by things like
> APs.
>
> The software might be simpler, but the hardware would need to be
> overspecified to the point of making it unreasonably expensive for consumer
> devices.
>
> Radio hardware generally has a significant TX/RX turnaround time, required
> for the RX deafening circuits to disengage.  Without those deafening
> circuits, the receivers would be damaged by the comparatively vast TX power
> in the antenna.
>
> So in practice, it's easier to measure SNR at the receiver, or indirectly
> by observing packet loss by dint of missing acknowledgements returned to
> the transmitter.
>
>  - Jonathan Morton
>
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Georgios Amanakis]

On Mon, 2018-07-23 at 19:36 -0700, Dave Taht wrote:
> George does your result mean you also have a crappy cablemodem?
> 

Yes, I think so. It's a Linksys DPC3008 DOCSIS 3.0. Also, I cannot get
it to behave any differently with hping3 as Arie suggested.

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [homenet] https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-09.txt

[Eric Vyncke (evyncke)]

Ray and Christophe and others,

As the responsible AD for this draft, would you mind forwarding/adding 
mbo...@ietf.org to the recipient list? So that authors 
can read your valuable comments?

Thank you

-éric



From: homenet  on behalf of "Ray Hunter (v6ops)" 

Date: Wednesday, 23 October 2019 at 10:55
To: Dave Taht 
Cc: HOMENET , cerowrt-devel 

Subject: Re: [homenet] 
https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-09.txt


Dave Taht wrote on 23/10/2019 08:56:


has anyone here had much chance to review this?


Thanks for the prompt.

>From a pure Homenet perspective, it reinforces that L3 routing is the correct 
>solution for segmenting networks where end nodes have different 
>characteristics. e.g. battery powered or different underlying LAN technology. 
>And maybe we need a firewall in front of those segments to prevent inbound 
>scanning traffic overloading the link.

Other than that I'm not sure it says much more than "Multicast is great for 
efficiency, until it isn't".

Section 3.2.4:
> On a wired network, there is not a huge difference between unicast, multicast 
> and broadcast traffic.

I'd dispute this statement as being overly generic. Anyway, it doesn't add much 
to the discussion (about wireless).

The majority of modern wired Ethernets are actually effectively point to point 
networks, with multicast and broadcast being emulated in silicon or software.

Although maybe having a less visible impact than on wireless, multicast and 
broadcast can also have some similar operational impact on wired networks 
(waking nodes unnecessarily, switching via a slow (software) path in the main 
processor,  https://tools.ietf.org/html/rfc6583 etc.).

--
regards,
RayH
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] Ubiquiti Launches a Speed Test Network

[Pete Heist]

> On Sep 7, 2019, at 1:12 AM, Toke Høiland-Jørgensen  wrote:
> 
 From irtt help client:
 --fill=fillfill payload with given data (default none)
  none: leave payload as all zeroes
  rand: use random bytes from Go's math.rand
  pattern:XX: use repeating pattern of hex (default 69727474)
 --fill-one fill only once and repeat for all packets
 --sfill=fill   request server fill (default not specified)
  see options for --fill
  server must support and allow this fill with --allow-fills
>>> 
>>> As above, we're doing --fill=rand today.
>> 
>>  Sama as above, but maybe Pete could be convinced to do the read back of 
>> the first X bytes automatically.
> 
> Certainly not opposed to adding this support to Flent if it materialises
> in irtt :)

Coming into this late so haven’t parsed the full request, but irtt sends the 
requested DSCP value passed in via --dscp to the server during the handshake. 
It would be possible, though not very intuitive, to pull this out of the 
initial request packet, which contains type/value pairs encoded with varint 
style encoding: https://developers.google.com/protocol-buffers/docs/encoding.

The format of the request is “documented” in code in the bytes() method in 
params.go. Visually, the DSCP value is often the value 0x08, close to the end 
of the initial packet, following by the DSCP value as a signed varint. 
(Clearly, it would have made more sense if I’d just sent that as an unsigned 
byte instead of using a varint, let alone a signed one, but I just leaned on 
the binary package’s varint support, such as it is, so one has to grok this: 
https://developers.google.com/protocol-buffers/docs/encoding#signed-integers. 
I’ve added it to irtt’s todo list to clean this up before 1.0, which will mean 
a protocol version bump).

One unfortunate thing is that if the goal is to verify that DSCP values have 
not been modified along the way (without a pcap), afaik the receiver has no way 
of obtaining the received DSCP value in user space without opening up a raw 
socket and parsing the IP packet in full (requiring root). But, figuring it out 
from packet dumps would be possible. If I ever get around to adding irtt 
support to scetrace (https://github.com/heistp/scetrace), I could detect and 
count changes to dscp values there, though that’s a ways off at the moment.

Knowing all this, are there any simple changes I can make to get you what you 
need?

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks?

[Toke Høiland-Jørgensen]

"David P. Reed"  writes:

> Regarding EDF.
>
> I've been pushing folks to move latency sensitive computing in ALL OS's to a 
> version of EDF since about 1976. This was when I was in grad school working 
> on distributed computing on LANs. In fact, it is where I got the idea for my 
> Ph.D. thesis (completed in 1978) which pointed out a bigger idea - that 
> getting ACID consistency [ACID hadn't been invented then as a term, we called 
> it atomic actions] on data in a distributed system being processed by 
> concurrent distributed transactions can be done by using timestamps that 
> behave like the "deadlines" in EDF. In fact, the scheduling of code in my 
> thesis was a generalized version of EDF, approximated because of the 
> impossibility of perfect synchronization.
>
> The Croquet system, which was a real-time edge based decentralized system, 
> with no central server, that we demonstrated with a Second-Life style virtual 
> world that wored entirely on a set of laptops that could be across the 
> country from each other was based on an OS implemented in a variant of the 
> Squeak programming language, where the scheduling and object model was not 
> process based, but message based with replicated computation synchronized via 
> a shared "timestamp" that was used for execution scheduling (essentially 
> distributed EDF). The latency requirements for this distributed virtual world 
> were on the order of 100 msec. simultaneity for mouse clicks affecting all 
> participating nodes across the country in a virtual 3D world, with sound, etc.
>
> Croquet was built in 2 years by 3 people (starting from scratch).  And 
> scheduling was never a problem, nor was variable network delay (our protocol 
> was based on UDP frames synchronized by the same timestamps used to 
> synchronize each object method execution.
>
> The operating system model is one I created within that modified Squeak 
> environment as part of its base "interpreter", which wasn't a loop, but a 
> scheduler using EDF.
>
> To make this work properly, the programming model has to be unified around 
> this kind of scheduling.
>
> And here's why I am mentioning this. To put EDF *only* into the networking 
> stack, but leave the userspace applicaiton living with the stupid Linux 
> timesharing system scheduler, optimized for people typing commands on 
> terminals every few seconds and running batch compilation is the *worst of 
> all possible ways to use EDF*.
>
> Because it creates a huge mess bridging those two ideas.
>
> Croquet is a much more complicated thing that a teleconferencing system, 
> because it actually lets end users write simple programs that control the 
> user interactive experience, 30 frames per second across the entire US, 
> replicated on each computer, in the Squaak variant of Smalltalk. And we did 
> it with 3 coders in a couple of years. (yes, they are sckilled people - me, 
> David A. Smith, and the late Andreas Raab, who died way too young).
>
> In contrast, trying to bridge between EDF and regular Linux processes running 
> under the ordinary scheduler, even with "nice" and all kinds of hacks, just 
> to do a video conferencing system with fixed, non-programmable behavior, 
> would take far more design, far more lines of code, etc.
>
> So this is why I think timesharing OS's are really obsolescent for modern 
> distributed interactive systems. Yeah, "rsync" and "git" are nice for batch 
> replication of files. ANd yeah, EDF can help make them perform faster in 
> their file transferring.
>
> But to make an immersive, real-time experience (which is what computing today 
> is all about, on all time scales, even in the servers other than HPC) it is 
> ALL wrong, and incrementally patching little pieced of Linux ain't gonna get 
> there. Windows or BSD (macOS) ain't gonna do it either.
>
> I'm old. Why is Linux living in the idea space of operating systems that 
> precededed networking, distributed computing, media sharing?
>
> My opinion, and it is only an opinion based on experience, is that it really 
> is time for networking to stop focusing on file transfers, and OS's to stop 
> focusing on timesharing behavior. The world is "live" and time-based. It may 
> not be hard-real-time. But latency is what matters.
>
> Since networking will remain separate from OS's, the interface concepts in 
> both really need to be matched to get to that future.
>
> It's why I pushed so hard for UDP, not reliable in-order streams alone. And 
> in my view, though no one every implemented it, those UDP packets will be 
> carring times, essential for synchronization of coordinated operations at all 
> the endpoints of the computation.
>
> I'd love to see that happen before this old guy dies. I think it will make it 
> a whole lot easier to make networked programs work.
>
> Decentralization isn't "blockchain". My thesis, in 1978, talked about one way 
> to decentralize computation, not just data structures. And timing is critical.
>
> Sorry 

Re: [Cerowrt-devel] [Ecn-sane] tsvwg interim meeting sce & l4s thursday 10-12

[Rodney W. Grimes]

> This is a quick reminder that we'll have a virtual interim meeting via
> WebEx on Thursday.  Details are at:
> https://datatracker.ietf.org/doc/agenda-interim-2020-tsvwg-01-tsvwg-01/
> 
> It's from 10:00 to 12:00 America/New_York.

Correction, they updated the time to 9:00 to 11:00 America/New_York.

> DT> It may have been moved up an hour, actually, I'm checking.

It did move up.

> Meeting link:
> https://ietf.webex.com/ietf/j.php?MTID=m76a8ef03619d3194cc8b82f1390788a7
> Meeting number: 648 364 638
> Password: DuyqGcre
> 
> ...
> 
> As a matter of agenda bashing, the chairs just had a quick sync-up and
> we are now thinking to start with first outlining the plans for
> Vancouver, then move the SCE presentation up following that, and then
> going into the L4S status and issues discussion for the remainder of the
> time.  Assuming this works for people, I will update the agenda.
> 
> Anyone who wants to show slides, please send them to me by Wednesday so
> that I can get them posted ahead of the meeting. Thanks.
> 
> 
> -- 
> Make Music, Not War
> 
> Dave T?ht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> ___
> Ecn-sane mailing list
> ecn-s...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Ecn-sane] tsvwg interim meeting sce & l4s thursday 10-12

[Rodney W. Grimes]

> Rod:
> 
> It looks like they also would like to move the SCE preso up front. You
> cool with that? I've set my alarm.

I agenda bashed early as that change has not happened in the offical
posted agenda and we are >24 hours from meeting.  I'll see what or
how the respond, but yes, the guys are aware of the re-order.

It does make sure we get our time allocation...
which has been a real issue.

-- 
Rod Grimes rgri...@freebsd.org
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] my arin NRO board candidacy

[Toke Høiland-Jørgensen]

Dave Taht  writes:

> A while back I decided to run for ARIN's (the american registry of
> internet numbers) NRO board, and attend their conference and election
> next week in dallas texas.
>
> While I decided to run to discuss the ipv4 extensions project, I
> certainly intend to raise issues of direct concern here (bufferbloat,
> binary blobs, wif, 5g, ipv6, middlebox problems) at a pretty high
> level and in a place I've not done so before, in front of people that
> have never heard of them.

Woohoo, go get 'em! If you ever run for the RIPE board, I'll definitely
vote for you! ;)

-Toke

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

On a clean, conducted network I'm getting about 900 us UDP end/end latency
and about 2 ms TCP RTT, no aggregation, 9x2 VHT, small packets,
undersubscribed (1Mbs) offered load for both protocols.   So TCP does seem
to double the latency per the need to fully arbitrate access and send its
ack.

Bob

On Mon, Jun 27, 2016 at 3:18 PM, David Lang  wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> While the 802.11 ack doesn't need to do collision avoidance, it does need
>> to wait a SIFS, send a PHY header and its typically transmitted at lower
>> PHY rate.   My estimate is 40 us for that overhead.  So yes, one would
>> have
>> to get rid of that too, e.g. assume a transmit without a collision
>> succeeded - hopefully negating the need for the 802.11 ack.
>>
>
> don't forget that while there is teh 802.11 ack, there is also the TCP ack
> that will show up later as well.
>
> (It does seem the wired engineers have it much easier per the point/point,
>> full duplex and wave guides.)
>>
>
> yep. even wireless is far easier when you can do point-to-point with
> highly directional antennas. Even if you don't do full duplex as well.
>
> It's the mobility and unpredictability of the stations that makes things
> hard. The fact that Wifi works as well as it does is impressive, given the
> amount things have changed since it was designed, and the fact that
> backwards compatibility has been maintained.
>
>
> David Lang
>
> Bob
>>
>> On Mon, Jun 27, 2016 at 2:09 PM, David Lang  wrote:
>>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>
>>> packet size is smallest udp payload per a socket write() which in turn
>>>
 drives the smallest packet supported by "the wire."

 Here is a back of the envelope calculation giving ~100 microseconds per
 BE
 access.

 # Overhead estimates (slot time is 9 us):
 # o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
 # o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
 # o 5G 20 us
 # o Multimode header 20 us
 # o PLCP (symbols) 2 * 4 us = 8 us
 # o *SIFS 16 us
 # o ACK 40 us


>>> isn't the ack a separate transmission by the other end of the connection?
>>> (subject to all the same overhead)
>>>
>>> #
>>>
 # Even if there is no collision and the CW stays at the aCWmin, the
 average
 # backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16
 µs
 # +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM
 PHY
 # can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
 # for a 1500 byte packet.


>>> well, are you talking a 64 byte packet or a 1500 byte packet?
>>>
>>> But this is a good example of why good aggregation is desirable. It
>>> doesn't have
>>> to add a lot of latency. you could send 6x as much data in 2x the time by
>>> sending 9K per transmission instead of 1.5K per transmission
>>> (+100us/7.5K)
>>>
>>> if the aggregation is done lazily (send whatever's pending, don't wait
>>> for
>>> more data if you have an available transmit slot), this can be done with
>>> virtually no impact on latency, you just have to set a reasonable
>>> maximum,
>>> and adjust it based on your transmission rate.
>>>
>>> The problem is that right now thing don't set a reasonable max, and they
>>> do greedy aggregation (wait until you have a lot of data to send before
>>> you
>>> send anything)
>>>
>>> All devices in a BSSID would have to agree that the second radio is to be
>>>
 used for BSSID "carrier state" information and all energy will be
 sourced
 by the AP serving that BSSID.  (A guess is doing this wouldn't improve
 the
 100 us by enough to justify the cost and that a new MAC protocol is
 required.  Just curious to what such a protocol and phy subsystem would
 look like assuming collision avoidance could be replaced with collision
 detect.)


>>> if the second radio is on a separate band, you have the problem that
>>> propogation
>>> isn't going to be the same, so it's very possible to be able to talk to
>>> the AP
>>> on the 'normal' channel, but not on the 'coordination' channel.
>>>
>>> I'm also not sure what good it would do, once a transmission has been
>>> stepped
>>> on, it will need to be re-sent (I guess you would be able to re-send
>>> immediatly)
>>>
>>>
>>> David Lang
>>>
>>> Bob
>>>



 On Mon, Jun 27, 2016 at 1:09 PM, David Lang  wrote:

 On Mon, 27 Jun 2016, Bob McMahon wrote:

>
> The ~10K is coming from empirical measurements where all aggregation
>
> technologies are disabled, i.e. only one small IP packet per medium
>> arbitration/access and where there is only one transmitter and one
>> receiver.  900Mb/sec is typically a peak-average throughput
>> measurement
>> where max (or near max) aggregation occurs, amortizing the access
>> overhead
>> across multiple packets.
>>
>>
>> so 10K is minimum size packets being t

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

Is there a specific goal in mind?  This seems an AP tx centric proposal,
though I may not be fully understanding it.  I'm also curious as why not
scale in spatial domain vs the frequency domain, i.e. AP and STAs can also
scale using MiMO.  Why not just do that? So many phones today are 1x1, some
2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard
supports 8x8.  (I'm not sure the marginal transistor count increase per
each approach.)  On the AP tx side, MuMIMO is also there which I think is
similar to the DAC proposal.

I'm far from a PHY & DSP expert, but I think the simultaneous AP receive is
the most difficult issue per the power variations, aka SNR.  Each of the
mobile device energies is affected per inverse square law (unless some form
of wave guide is used.)  Hence wi-fi use of time domain slots prior to
transmit (no longer simultaneous in time.)  Particularly needed for devices
that communicate with one another.  Unfortunately, "collocated"
energy/information sources must honor this TDM  even when not communication
with one another per tragedy of the commons.  (Agreed there is no such
thing as a collision so let's redefine it to mean that the receiver is
unable to receive per RF energy "confusion", still a tragedy of the
commons.  I don't know what drives the limits to DSP decode that could
minimize or eliminate  this tragedy.)

At the end of the day, would the ideal network would resemble a wired
ethernet (including ethernet switch fabric) without the waveguides (or
wires/fibers)?  From that perspective, here are some thoughts to the goals

o)  TX op/access to transmit driven to zero.  (Collision avoidance isn't
nearly as good as instantaneous collision detect in this context, though
"collision" should replaced with "confusion")
o)  RX confusion detection time propagated to stop offending TX(s) driven
to zero
o)  Support of different encodings (e..g phy rates) pushes towards virtual
output queueing prior (queuing at the transmitter)
o)  Power per bit xfered towards zero or driven per cost & energy density
of batteries.  Note: Atomic batteries not allowed per humans being involved.
o)  Transistor count (chip cost) per bit moved driven by Moore's law and
those economics
o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to zero

Just some thoughts off the top of my head.  Please do comment and correct.
Thanks in advance for the discussion.

Bob




On Fri, Jun 24, 2016 at 2:24 PM,  wrote:

> Without custom silicon, doing what I was talking about would involve non
> standard MAC power management, which would require all devices to agree.
>
> David Lang's explanation was the essence of what I meant. the transmission
> from access point on multiple channels is just digital addition if the DACs
> have enough bits per sample. to make sure that the signals to the AP are
> equalized, just transmit at a power that makes that approximately true...
> which means a power amp with at most 30 dB of dynamic gain setting. typical
> dynamic path attenuation range (strongest to weakest ratio) among stations
> served by an AP is < 20 dB from my past experiments on well
> operating-installtions, but 25 can be seen in reflection heavy
> environments.-Original Message-
> From: "David Lang" 
> Sent: Fri, Jun 24, 2016 at 1:19 am
> To: "Bob McMahon" 
> Cc: "Bob McMahon" ,
> make-wifi-f...@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net"
> 
> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
> demandfor better wifi
>
> well, with the kickstarter, I think they are selling a bill of goods.
>
> Just using the DFS channels and aggregating them as supported by N and AC
> standards would do wonders (as long as others near you don't do the same)
>
> David Lang
>
> On Thu, 23 Jun 2016, Bob McMahon wrote:
>
> > Date: Thu, 23 Jun 2016 20:01:22 -0700
> > From: Bob McMahon
> > To: David Lang
> > Cc: dpr...@reed.com, make-wifi-f...@lists.bufferbloat.net,
> > "cerowrt-devel@lists.bufferbloat.net"
> >
> > Subject: Re: [Make-wifi-fast] more well funded attempts showing market
> demand
> > for better wifi
> >
> > Thanks for the clarification.   Though now I'm confused about how all the
> > channels would be used simultaneously with an AP only solution (which is
> my
> > understanding of the kickstarter campaign.)
> >
> > Bob
> >
> > On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
> >
> >> I think he is meaning when one unit is talking to one AP the signal
> levels
> >> across multiple channels will be similar. Which is probably fairly true.
> >>
> >>
> >> David Lang
> >>
> >> On Thu, 23 Jun 2016, Bob McMahon wrote:
> >>
> >> Curious, where does the "in a LAN setup, the variability in [receive]
> >>> signal strength is likely small enough" assertion come?   Any specific
> >>> power numbers here? We test with many combinations of "signal strength
> >>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different
> >>> channel conditions.  This incl

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demand for better wifi

[Bob McMahon]

An AP per room/area, reducing the tx power (beacon range) has been my
approach and has scaled very well.   It does require some wires to each AP
but I find that paying an electrician to run some quality wiring to things
that are to remain stationary has been well worth the cost.

just my $0.02,
Bob

On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:

> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide chunks
> would be a huge improvement, not many people are using them (yet), and the
> wide channels let you get a lot of data out at once. If everything is
> within a good range of the AP, this would work pretty well. If you end up
> needing multiple APs, or you have many stations, I expect that you will be
> better off with more APs at lower power, each using different channels.
>
> David Lang
>
>
>
>
> On Thu, 23 Jun 2016, Bob McMahon wrote:
>
> Date: Thu, 23 Jun 2016 12:55:19 -0700
>> From: Bob McMahon 
>> To: Dave Taht 
>> Cc: make-wifi-f...@lists.bufferbloat.net,
>> "cerowrt-devel@lists.bufferbloat.net"
>> 
>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>> demand
>> for better wifi
>>
>>
>> hmm, I'm skeptical.   To use multiple carriers simultaneously is difficult
>> per RF issues.   Even if that is somehow resolved, to increase throughput
>> usually requires some form of channel bonding, i.e. needed on both sides,
>> and brings in issues with preserving frame ordering.  If this is just
>> channel hopping, that needs coordination between both sides (and isn't
>> simultaneous, possibly costing more than any potential gain.)   An AP only
>> solution can use channel switch announcements (CSA) but there is a cost to
>> those as well.
>>
>> I guess don't see any break though here and the marketing on the site
>> seems
>> to indicate something beyond physics, at least the physics that I
>> understand.  Always willing to learn and be corrected if I'm
>> misunderstanding things.
>>
>> Bob
>>
>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht  wrote:
>>
>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht  wrote:
>>>


>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
>>>

 "Portal is the first and only router specifically engineered to cut
 through and avoid congestion, delivering consistent, high-performance
 WiFi with greater coverage throughout your home.

 Its proprietary spectrum turbocharger technology provides access to
 300% more of the radio airwaves than any other router, improving
 performance by as much as 300x, and range and coverage by as much as
 2x in crowded settings, such as city homes and multi-unit apartments"

 It sounds like they are promising working DFS support.

>>>
>>> It's not clear what chipset they are using (they are claiming wave2) -
>>> but they are at least publicly claiming to be using openwrt. So I
>>> threw in enough to order one for september, just so I could comment on
>>> their kickstarter page. :)
>>>
>>> I'd have loved to have got in earlier (early shipments are this month
>>> apparently), but those were sold out.
>>>
>>>
>>>
>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>>>
>>>
>>>
 --
 Dave Täht
 Let's go make home routers and wifi faster! With better software!
 http://blog.cerowrt.org

>>>
>>>
>>>
>>> --
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> http://blog.cerowrt.org
>>> ___
>>> Make-wifi-fast mailing list
>>> make-wifi-f...@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>
>>>
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

packet size is smallest udp payload per a socket write() which in turn
drives the smallest packet supported by "the wire."

Here is a back of the envelope calculation giving ~100 microseconds per BE
access.

# Overhead estimates (slot time is 9 us):
# o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
# o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
# o 5G 20 us
# o Multimode header 20 us
# o PLCP (symbols) 2 * 4 us = 8 us
# o *SIFS 16 us
# o ACK 40 us
#
# Even if there is no collision and the CW stays at the aCWmin, the average
# backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16 µs
# +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM PHY
# can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
# for a 1500 byte packet.

All devices in a BSSID would have to agree that the second radio is to be
used for BSSID "carrier state" information and all energy will be sourced
by the AP serving that BSSID.  (A guess is doing this wouldn't improve the
100 us by enough to justify the cost and that a new MAC protocol is
required.  Just curious to what such a protocol and phy subsystem would
look like assuming collision avoidance could be replaced with collision
detect.)

Bob



On Mon, Jun 27, 2016 at 1:09 PM, David Lang  wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> The ~10K is coming from empirical measurements where all aggregation
>> technologies are disabled, i.e. only one small IP packet per medium
>> arbitration/access and where there is only one transmitter and one
>> receiver.  900Mb/sec is typically a peak-average throughput measurement
>> where max (or near max) aggregation occurs, amortizing the access overhead
>> across multiple packets.
>>
>
> so 10K is minimum size packets being transmitted?or around 200
> transmissions/sec (plus 200 ack transmissions/sec)?
>
> Yes, devices can be hidden from each other but not from the AP (hence the
>> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
>> "carrier state" that matters (at least in infrastructure mode?)  If that's
>> the case, what about a different band (and different radio) such that the
>> strong signal carrying the data could be separated from the the BSSID's
>> "carrier/energy state" signal?
>>
>
> how do you solve the interference problem on this other band/radio? When
> you have other APs in the area operating, you will have the same problem
> there.
>
> David Lang
>
>
> Bob
>>
>> On Mon, Jun 27, 2016 at 12:40 PM, David Lang  wrote:
>>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>
>>> Hi All,
>>>

 This is a very interesting thread - thanks to all for taking the time to
 respond.   (Personally, I now have better understanding of the
 difficulties
 associated with a PHY subsystem that supports a wide 1GHz.)

 Not to derail the current discussion, but I am curious to ideas on
 addressing the overhead associated with media access per collision
 avoidance.  This overhead seems to be limiting transmits to about 10K
 per
 second (even when a link has no competition for access.)


>>> I'm not sure where you're getting 10K/second from. We do need to limit
>>> the
>>> amount of data transmitted in one session to give other stations a chance
>>> to talk, but if the AP replies immediatly to ack the traffic, and the
>>> airwaves are idle, you can transmit again pretty quickly.
>>>
>>> people using -ac equipment with a single station are getting 900Mb/sec
>>> today.
>>>
>>>   Is there a way,
>>>
 maybe using another dedicated radio, to achieve near instantaneous
 collision detect (where the CD is driven by the receiver state) such
 that
 mobile devices can sample RF energy to get theses states and state
 changes
 much more quickly?


>>> This gets back to the same problems (hidden transmitter , and the
>>> simultanious reception of wildly different signal strengths)
>>>
>>> When you are sending, you will hear yourself as a VERY strong signal,
>>> trying to hear if someone else is transmitting at the same time is almost
>>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>>> another 2 orders of magnatude)
>>>
>>> And it's very possible that the station that you are colliding with isn't
>>> one you can hear at all.
>>>
>>> Any AP is going to have a better antenna than any phone. (sometimes
>>> several orders of magnatude better), so even if you were located at the
>>> same place as the AP, the AP is going to hear signals that you don't.
>>>
>>> Then consider the case where you and the other station are on opposite
>>> sides of the AP at max range.
>>>
>>> and then add cases where there is a wall between you and the other
>>> station, but the AP can hear both of you.
>>>
>>> David Lang
>>>
>>>
>>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demand for better wifi

[Bob McMahon]

hmm, I'm skeptical.   To use multiple carriers simultaneously is difficult
per RF issues.   Even if that is somehow resolved, to increase throughput
usually requires some form of channel bonding, i.e. needed on both sides,
and brings in issues with preserving frame ordering.  If this is just
channel hopping, that needs coordination between both sides (and isn't
simultaneous, possibly costing more than any potential gain.)   An AP only
solution can use channel switch announcements (CSA) but there is a cost to
those as well.

I guess don't see any break though here and the marketing on the site seems
to indicate something beyond physics, at least the physics that I
understand.  Always willing to learn and be corrected if I'm
misunderstanding things.

Bob

On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht  wrote:

> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht  wrote:
> >
> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
> >
> > "Portal is the first and only router specifically engineered to cut
> > through and avoid congestion, delivering consistent, high-performance
> > WiFi with greater coverage throughout your home.
> >
> > Its proprietary spectrum turbocharger technology provides access to
> > 300% more of the radio airwaves than any other router, improving
> > performance by as much as 300x, and range and coverage by as much as
> > 2x in crowded settings, such as city homes and multi-unit apartments"
> >
> > It sounds like they are promising working DFS support.
>
> It's not clear what chipset they are using (they are claiming wave2) -
> but they are at least publicly claiming to be using openwrt. So I
> threw in enough to order one for september, just so I could comment on
> their kickstarter page. :)
>
> I'd have loved to have got in earlier (early shipments are this month
> apparently), but those were sold out.
>
>
> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>
>
> >
> > --
> > Dave Täht
> > Let's go make home routers and wifi faster! With better software!
> > http://blog.cerowrt.org
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demand for better wifi

[Bob McMahon]

Curious, where does the "in a LAN setup, the variability in [receive]
signal strength is likely small enough" assertion come?   Any specific
power numbers here? We test with many combinations of "signal strength
variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different
channel conditions.  This includes power variability within the spatial
streams' MiMO transmission.   It would be helpful to have some physics
combined with engineering to produce some pragmatic limits to this.

Also, mobile devices have a goal of reducing power in order to be efficient
with their battery (vs a goal to balance power such that an AP can
receive simultaneously.)  Power per bit usually trumps most other design
goals.  There market for battery powered wi-fi devices drives a
semi-conductor mfg's revenue so my information come with that bias.

Bob

On Thu, Jun 23, 2016 at 1:48 PM,  wrote:

> The actual issues of transmitting on multiple channels at the same time
> are quite minor if you do the work in the digital domain (pre-DAC).  You
> just need a higher sampling rate in the DAC and add the two signals
> together (and use a wideband filter that covers all the channels).  No RF
> problem.
>
> Receiving multiple transmissions in different channels is pretty much the
> same problem - just digitize (ADC) a wider bandwidth and separate in the
> digital domain.  the only real issue on receive is equalization - if you
> receive two different signals at different receive signal strengths, the
> lower strength signal won't get as much dynamic range in its samples.
>
> But in a LAN setup, the variability in signal strength is likely small
> enough that you can cover that with more ADC bits (or have the MAC protocol
> manage the station transmit power so that signals received at the AP are
> nearly the same power.
>
> Equalization at transmit works very well when there is a central AP (as in
> cellular or normal WiFi systems).
>
>
>
> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" 
> said:
>
> > ___
> > Make-wifi-fast mailing list
> > make-wifi-f...@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
> > An AP per room/area, reducing the tx power (beacon range) has been my
> > approach and has scaled very well.   It does require some wires to each
> AP
> > but I find that paying an electrician to run some quality wiring to
> things
> > that are to remain stationary has been well worth the cost.
> >
> > just my $0.02,
> > Bob
> >
> > On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
> >
> >> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide chunks
> >> would be a huge improvement, not many people are using them (yet), and
> the
> >> wide channels let you get a lot of data out at once. If everything is
> >> within a good range of the AP, this would work pretty well. If you end
> up
> >> needing multiple APs, or you have many stations, I expect that you will
> be
> >> better off with more APs at lower power, each using different channels.
> >>
> >> David Lang
> >>
> >>
> >>
> >>
> >> On Thu, 23 Jun 2016, Bob McMahon wrote:
> >>
> >> Date: Thu, 23 Jun 2016 12:55:19 -0700
> >>> From: Bob McMahon 
> >>> To: Dave Taht 
> >>> Cc: make-wifi-f...@lists.bufferbloat.net,
> >>> "cerowrt-devel@lists.bufferbloat.net"
> >>> 
> >>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
> >>> demand
> >>> for better wifi
> >>>
> >>>
> >>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
> difficult
> >>> per RF issues.   Even if that is somehow resolved, to increase
> throughput
> >>> usually requires some form of channel bonding, i.e. needed on both
> sides,
> >>> and brings in issues with preserving frame ordering.  If this is just
> >>> channel hopping, that needs coordination between both sides (and isn't
> >>> simultaneous, possibly costing more than any potential gain.)   An AP
> only
> >>> solution can use channel switch announcements (CSA) but there is a
> cost to
> >>> those as well.
> >>>
> >>> I guess don't see any break though here and the marketing on the site
> >>> seems
> >>> to indicate something beyond physics, at least the physics that I
> >>> understand.  Always willing to learn and be corrected if I'm
> >>> misunderstanding things.
> >>>
> >>> Bob
> >>>
> >>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht 
> wrote:
> >>>
> >>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht 
> wrote:
> 
> >
> >
> 
> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
> 
> >
> > "Portal is the first and only router specifically engineered to cut
> > through and avoid congestion, delivering consistent, high-performance
> > WiFi with greater coverage throughout your home.
> >
> > Its proprietary spectrum turbocharger technology provides access to
> > 300% more of the radio airwaves than any other router, improving
> > performance by 

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demand for better wifi

[Bob McMahon]

Thanks for the clarification.   Though now I'm confused about how all the
channels would be used simultaneously with an AP only solution (which is my
understanding of the kickstarter campaign.)

Bob

On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:

> I think he is meaning when one unit is talking to one AP the signal levels
> across multiple channels will be similar. Which is probably fairly true.
>
>
> David Lang
>
> On Thu, 23 Jun 2016, Bob McMahon wrote:
>
> Curious, where does the "in a LAN setup, the variability in [receive]
>> signal strength is likely small enough" assertion come?   Any specific
>> power numbers here? We test with many combinations of "signal strength
>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different
>> channel conditions.  This includes power variability within the spatial
>> streams' MiMO transmission.   It would be helpful to have some physics
>> combined with engineering to produce some pragmatic limits to this.
>>
>> Also, mobile devices have a goal of reducing power in order to be
>> efficient
>> with their battery (vs a goal to balance power such that an AP can
>> receive simultaneously.)  Power per bit usually trumps most other design
>> goals.  There market for battery powered wi-fi devices drives a
>> semi-conductor mfg's revenue so my information come with that bias.
>>
>> Bob
>>
>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
>>
>> The actual issues of transmitting on multiple channels at the same time
>>> are quite minor if you do the work in the digital domain (pre-DAC).  You
>>> just need a higher sampling rate in the DAC and add the two signals
>>> together (and use a wideband filter that covers all the channels).  No RF
>>> problem.
>>>
>>> Receiving multiple transmissions in different channels is pretty much the
>>> same problem - just digitize (ADC) a wider bandwidth and separate in the
>>> digital domain.  the only real issue on receive is equalization - if you
>>> receive two different signals at different receive signal strengths, the
>>> lower strength signal won't get as much dynamic range in its samples.
>>>
>>> But in a LAN setup, the variability in signal strength is likely small
>>> enough that you can cover that with more ADC bits (or have the MAC
>>> protocol
>>> manage the station transmit power so that signals received at the AP are
>>> nearly the same power.
>>>
>>> Equalization at transmit works very well when there is a central AP (as
>>> in
>>> cellular or normal WiFi systems).
>>>
>>>
>>>
>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" <
>>> bob.mcma...@broadcom.com>
>>> said:
>>>
>>> ___
 Make-wifi-fast mailing list
 make-wifi-f...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/make-wifi-fast
 An AP per room/area, reducing the tx power (beacon range) has been my
 approach and has scaled very well.   It does require some wires to each

>>> AP
>>>
 but I find that paying an electrician to run some quality wiring to

>>> things
>>>
 that are to remain stationary has been well worth the cost.

 just my $0.02,
 Bob

 On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:

 Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide chunks
> would be a huge improvement, not many people are using them (yet), and
>
 the
>>>
 wide channels let you get a lot of data out at once. If everything is
> within a good range of the AP, this would work pretty well. If you end
>
 up
>>>
 needing multiple APs, or you have many stations, I expect that you will
>
 be
>>>
 better off with more APs at lower power, each using different channels.
>
> David Lang
>
>
>
>
> On Thu, 23 Jun 2016, Bob McMahon wrote:
>
> Date: Thu, 23 Jun 2016 12:55:19 -0700
>
>> From: Bob McMahon 
>> To: Dave Taht 
>> Cc: make-wifi-f...@lists.bufferbloat.net,
>> "cerowrt-devel@lists.bufferbloat.net"
>> 
>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>> demand
>> for better wifi
>>
>>
>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
>>
> difficult
>>>
 per RF issues.   Even if that is somehow resolved, to increase
>>
> throughput
>>>
 usually requires some form of channel bonding, i.e. needed on both
>>
> sides,
>>>
 and brings in issues with preserving frame ordering.  If this is just
>> channel hopping, that needs coordination between both sides (and isn't
>> simultaneous, possibly costing more than any potential gain.)   An AP
>>
> only
>>>
 solution can use channel switch announcements (CSA) but there is a
>>
> cost to
>>>
 those as well.
>>
>> I guess don't see any break though here and the marketing on the site
>> seems
>> to indicate something beyond physics, at least the 

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

The ~10K is coming from empirical measurements where all aggregation
technologies are disabled, i.e. only one small IP packet per medium
arbitration/access and where there is only one transmitter and one
receiver.  900Mb/sec is typically a peak-average throughput measurement
where max (or near max) aggregation occurs, amortizing the access overhead
across multiple packets.

Yes, devices can be hidden from each other but not from the AP (hence the
use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
"carrier state" that matters (at least in infrastructure mode?)  If that's
the case, what about a different band (and different radio) such that the
strong signal carrying the data could be separated from the the BSSID's
"carrier/energy state" signal?

Bob

On Mon, Jun 27, 2016 at 12:40 PM, David Lang  wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> Hi All,
>>
>> This is a very interesting thread - thanks to all for taking the time to
>> respond.   (Personally, I now have better understanding of the
>> difficulties
>> associated with a PHY subsystem that supports a wide 1GHz.)
>>
>> Not to derail the current discussion, but I am curious to ideas on
>> addressing the overhead associated with media access per collision
>> avoidance.  This overhead seems to be limiting transmits to about 10K per
>> second (even when a link has no competition for access.)
>>
>
> I'm not sure where you're getting 10K/second from. We do need to limit the
> amount of data transmitted in one session to give other stations a chance
> to talk, but if the AP replies immediatly to ack the traffic, and the
> airwaves are idle, you can transmit again pretty quickly.
>
> people using -ac equipment with a single station are getting 900Mb/sec
> today.
>
>   Is there a way,
>> maybe using another dedicated radio, to achieve near instantaneous
>> collision detect (where the CD is driven by the receiver state) such that
>> mobile devices can sample RF energy to get theses states and state changes
>> much more quickly?
>>
>
> This gets back to the same problems (hidden transmitter , and the
> simultanious reception of wildly different signal strengths)
>
> When you are sending, you will hear yourself as a VERY strong signal,
> trying to hear if someone else is transmitting at the same time is almost
> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
> another 2 orders of magnatude)
>
> And it's very possible that the station that you are colliding with isn't
> one you can hear at all.
>
> Any AP is going to have a better antenna than any phone. (sometimes
> several orders of magnatude better), so even if you were located at the
> same place as the AP, the AP is going to hear signals that you don't.
>
> Then consider the case where you and the other station are on opposite
> sides of the AP at max range.
>
> and then add cases where there is a wall between you and the other
> station, but the AP can hear both of you.
>
> David Lang
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

I appreciate and agree with what you posted, including that a wired network
without guides is not the same as a guide-less mobile network.  I do think
the thought experiment can help set some goal posts and, where the
goalposts don't make sense, some can be thrown out.  Also, there may be new
ones as well per mobility vs tertiary demands.

I ask myself a question, "What happened in 2000 that wi-fi became viable
such that atheros and others were able to form new companies?   Did a
mathematician discover some new math or did a physicist  find a better way
to explain energy as a means for moving information?"  Superposition
certainly applied 50+ years ago and I suspect most physicists understood it
equally well back then.

Hence, wi-fi isn't a triumph of math nor physics but rather an advancement
in engineering, aka the realization of those fields into products useful to
humans.  I suspect the future of wi-fi is more of the same - hence the
desire to set some engineering goal posts.

So to your points (and in the thought experiment context:)

1) Drastic variation in signal strength.  Reality of physics?  Seems yes.
Solvable by math?  I suspect so but could be wrong.  Solvable by
engineering now? Not sure.  In ten years?  Not sure.
2) Hidden transmitters.  Does it really matter?   Superposition applies
hidden or not so will fixing the "receiver confusion" get rid of this issue?
3) a) Variable rates: arguably a huge engineering design mistake for
multiple reasons (though understandably done this way.)
b) Aggregation:  Artifact of media access latency that makes the
transport network incredibly difficult for things like TCP.  Possibly
another eng. design flaw.

Trying to learn from experts so thanks again for including me in these
discussions.

Bob

On Sun, Jun 26, 2016 at 5:00 PM, David Lang  wrote:

> I don't think anyone is trying to do simultanious receive of different
> stations. That is an incredibly difficult thing to do right.
>
> MU-MIMO is aimed at haivng the AP transmit to multiple stations at the
> same time. For the typical browser/streaming use, this traffic is FAR
> larger than the traffic from the stations to the AP. As such, it is worth
> focusing on optimizing this direction.
>
> While an ideal network may resemble a wired network without guides, I
> don't think it's a good idea to think about wifi networks that way.
>
> The reality is that no matter how good you get, a wireless network is
> going to have lots of things that are just not going to happen with wired
> networks.
>
> 1. drastic variations in signal strength.
>
>   On a wired network with a shared buss, the signal strength from all
> stations on the network is going to be very close to the same (a difference
> of 2x would be extreme)
>
>   On a wireless network, with 'normal' omnidirctional antennas, the signal
> drops off with the square of the distance. So if you want to service
> clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4
> orders of magnatude), this is before you include effects of shielding,
> bounces, bad antenna alignment, etc (which can add several more orders of
> magnatude of variation)
>
>   The receiver first normalized the strongest part of the signal to a
> constant value, and then digitizes the result, (usually with a 12-14 bit AD
> converter). Since 1000x is ~10 bits, the result of overlapping tranmissions
> can be one signal at 14 bits, and another at <4 bits. This is why digital
> processing isn't able to receive multiple stations at the same time.
>
> 2. 'hidden transmitters'
>
>   On modern wired networks, every link has exactly two stations on it, and
> both can transmit at the same time.
>
>   On wireless networks, it's drastically different. You have an unknown
> number of stations (which can come and go without notice).
>
>   Not every station can hear every other station. This means that they
> can't avoid colliding with each other. In theory you can work around this
> by having some central system coordinate all the clients (either by them
> being told when to transmit, or by being given a schedule and having very
> precise clocks). But in practice the central system doesn't know when the
> clients have something to say and so in practice this doesn't work as well
> (except for special cases like voice where there is a constant amount of
> data to transmit)
>
> 3. variable transmit rates and aggregation
>
>   Depending on how strong the signal is between two stations, you have
> different limits to how fast you can transmit data. There are many
> different standard modulations that you can use, but if you use one that's
> too fast for the signal conditions, the receiver isn't going to be able to
> decode it. If you use one that's too slow, you increase the probability
> that another station will step on your signal, scrambling it as far as the
> receiver is concerned. We now have stations on the network that can vary in
> speed by 100x, and are nearing 1000x (1Mb/sec to 1Gb

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

While the 802.11 ack doesn't need to do collision avoidance, it does need
to wait a SIFS, send a PHY header and its typically transmitted at lower
PHY rate.   My estimate is 40 us for that overhead.  So yes, one would have
to get rid of that too, e.g. assume a transmit without a collision
succeeded - hopefully negating the need for the 802.11 ack.

(It does seem the wired engineers have it much easier per the point/point,
full duplex and wave guides.)

Bob

On Mon, Jun 27, 2016 at 2:09 PM, David Lang  wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> packet size is smallest udp payload per a socket write() which in turn
>> drives the smallest packet supported by "the wire."
>>
>> Here is a back of the envelope calculation giving ~100 microseconds per BE
>> access.
>>
>> # Overhead estimates (slot time is 9 us):
>> # o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
>> # o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
>> # o 5G 20 us
>> # o Multimode header 20 us
>> # o PLCP (symbols) 2 * 4 us = 8 us
>> # o *SIFS 16 us
>> # o ACK 40 us
>>
>
> isn't the ack a separate transmission by the other end of the connection?
> (subject to all the same overhead)
>
> #
>> # Even if there is no collision and the CW stays at the aCWmin, the
>> average
>> # backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16 µs
>> # +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM PHY
>> # can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
>> # for a 1500 byte packet.
>>
>
> well, are you talking a 64 byte packet or a 1500 byte packet?
>
> But this is a good example of why good aggregation is desirable. It
> doesn't have
> to add a lot of latency. you could send 6x as much data in 2x the time by
> sending 9K per transmission instead of 1.5K per transmission (+100us/7.5K)
>
> if the aggregation is done lazily (send whatever's pending, don't wait for
> more data if you have an available transmit slot), this can be done with
> virtually no impact on latency, you just have to set a reasonable maximum,
> and adjust it based on your transmission rate.
>
> The problem is that right now thing don't set a reasonable max, and they
> do greedy aggregation (wait until you have a lot of data to send before you
> send anything)
>
> All devices in a BSSID would have to agree that the second radio is to be
>> used for BSSID "carrier state" information and all energy will be sourced
>> by the AP serving that BSSID.  (A guess is doing this wouldn't improve the
>> 100 us by enough to justify the cost and that a new MAC protocol is
>> required.  Just curious to what such a protocol and phy subsystem would
>> look like assuming collision avoidance could be replaced with collision
>> detect.)
>>
>
> if the second radio is on a separate band, you have the problem that
> propogation
> isn't going to be the same, so it's very possible to be able to talk to
> the AP
> on the 'normal' channel, but not on the 'coordination' channel.
>
> I'm also not sure what good it would do, once a transmission has been
> stepped
> on, it will need to be re-sent (I guess you would be able to re-send
> immediatly)
>
>
> David Lang
>
> Bob
>>
>>
>>
>> On Mon, Jun 27, 2016 at 1:09 PM, David Lang  wrote:
>>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>
>>> The ~10K is coming from empirical measurements where all aggregation
>>>
 technologies are disabled, i.e. only one small IP packet per medium
 arbitration/access and where there is only one transmitter and one
 receiver.  900Mb/sec is typically a peak-average throughput measurement
 where max (or near max) aggregation occurs, amortizing the access
 overhead
 across multiple packets.


>>> so 10K is minimum size packets being transmitted?or around 200
>>> transmissions/sec (plus 200 ack transmissions/sec)?
>>>
>>> Yes, devices can be hidden from each other but not from the AP (hence the
>>>
 use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of
 the
 "carrier state" that matters (at least in infrastructure mode?)  If
 that's
 the case, what about a different band (and different radio) such that
 the
 strong signal carrying the data could be separated from the the BSSID's
 "carrier/energy state" signal?


>>> how do you solve the interference problem on this other band/radio? When
>>> you have other APs in the area operating, you will have the same problem
>>> there.
>>>
>>> David Lang
>>>
>>>
>>> Bob
>>>

 On Mon, Jun 27, 2016 at 12:40 PM, David Lang  wrote:

 On Mon, 27 Jun 2016, Bob McMahon wrote:

>
> Hi All,
>
>
>> This is a very interesting thread - thanks to all for taking the time
>> to
>> respond.   (Personally, I now have better understanding of the
>> difficulties
>> associated with a PHY subsystem that supports a wide 1GHz.)
>>
>> Not to derail the current discussion, but I am curious to ideas on
>> a

Re: [Cerowrt-devel] spacebee

[Ray Ramadorai]

I'll throw in my 2cents on a couple of these items.  

With respect to launch costs.  If you are not picky about your orbit you can 
get a 3U cubesat into orbit for low 6 figures, this is especially true if you 
have something ready to launch and don't mind waiting for a slot to open up and 
can move quickly.  

I don't buy the idea that SpaceBEE 1,2,3,4 can't be seen by radar.  NORAD and 
others track objects smaller than that and regularly assign COSPAR id's to 
them.  This seems like a bureaucratic not a technical problem.  That having 
been said, getting FCC approval for spectrum for spacecraft is very much about 
talking to the right folks and following the rules.  At Planetary Resources we 
were able to get a license for a spread spectrum radio approved though it did 
require some back and forth with the FCC.  

It's true that most cubesats don't have prop and all are required to provide a 
de-orbit analysis as part of their FCC app.  That having been said almost any 
collision at orbital velocities is going to be destructive to both parties 
regardless of the presences of prop/batteries.  

One thought I have seen floating around out there is that, optical/laser comm, 
by its nature is not currently regulated by the FCC and as such it is 
*possible* to build a stabilized platform that has no RF capability and as such 
would not need an FCC license for launch.  To  date I don't think anyone has 
exercised that loophole but it is early in 2018...  

Ray


-Original Message-
From: Dave Taht [mailto:dave.t...@gmail.com] 
Sent: Tuesday, March 13, 2018 9:53 AM
To: Jim Gettys
Cc: Christopher Robin; cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] spacebee

A couple things on the spacebee.

0) I LOVE the concept. Of late (due to my boat) I'd been digging into the 
evolution of AIS repeaters, and that insanely primitive protocol, and the hacks 
to make that scale over two channels of VHF up into orbit.

1) The costs of launching cubesats has dropped dramatically. I believe this 
particular launch cost about $.5m per 1u device. (I was paying attention due to 
my interest in Planetary Resources' work. Their 6u
arkyd-3 spacecraft was in this payload and is functioning nominally.)

Spacebee - Having a payload 1/4th the size of a cubesat *work* and be useable! 
is a major advance. And is 1/4th the space junk. Worrying about something 
smaller than baseball hitting anything strikes me as control freakery at the 
FCC.

2) Although the FCC denied the application based on having inadaquate radar 
reflectivity, according to their standards, the article states:

"Websites dedicated to tracking operational satellites show the SpaceBees in 
orbits virtually identical to those specified in Swarm’s application." Ground 
stations can only get better.

3) most (all?) 1u spacecraft have no maneuvering capability and half of 
cubesats tend to fail quickly, so there will be an increasing amount of space 
junk in low orbits regardless. But there's nothing to explode on board ('cept 
maybe a battery?), and probably the biggest source of space junk has been 
explosions. Yes, there have been collisions, but the smaller the device, the 
smaller the chance of collision.

4) Flat out bypassing a staid and boring agency, getting the thing launched, 
and proving the concept is just so american! but unless the regulations are 
reformed I could certainly see more and more sats created outside the USA. ITAR 
is a real PITA, and now testing, development, and regulation now dominate over 
launch costs.

5) I'd misread the article, and interpreted part of the denial based on some 
longstanding issues they've had with not allowing spread spectrum radio in 
orbit.

I'd love to see an independent, fast-moving, external and international group 
just start ignoring the FCC on certain matters, or acting in concert to help 
push small sats forward, faster.



On Tue, Mar 13, 2018 at 9:12 AM, Jim Gettys  wrote:
> The issue is that they can't track satellites that small using current 
> radar technology.  They literally move satellites out of the way if 
> there is some possibility of collision.  If there is a collision, then 
> you get lots of debris, that just makes the debris problem worse.
>
> See: https://en.wikipedia.org/wiki/2009_satellite_collision
>
> Certain orbits are much more of an issue than others; for example, low 
> earth orbits decay quickly enough that there is little issue, as the 
> satellites will reenter quickly enough that there is unlikely to be a 
> problem.  Other orbits are seldom used, so there isn't much to run 
> into.
>
> The satellite's vendor proposed using on-board GPS to send its location.
>
> The problem is that if the satellite fails, they would get no information.
> The FCC was unhappy with that.  Launching without solving that 
> objection is a real "no-no".a
>
> Jim
>
>
>
>
> On Mon, Mar 12, 2018 at 4:29 PM, Christopher Robin  wrote:
>>
>> Now I'm not defending the FCC thinking it has gl

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

Hi All,

This is a very interesting thread - thanks to all for taking the time to
respond.   (Personally, I now have better understanding of the difficulties
associated with a PHY subsystem that supports a wide 1GHz.)

Not to derail the current discussion, but I am curious to ideas on
addressing the overhead associated with media access per collision
avoidance.  This overhead seems to be limiting transmits to about 10K per
second (even when a link has no competition for access.)   Is there a way,
maybe using another dedicated radio, to achieve near instantaneous
collision detect (where the CD is driven by the receiver state) such that
mobile devices can sample RF energy to get theses states and state changes
much more quickly?

Thanks,
Bob





On Mon, Jun 27, 2016 at 10:55 AM, Dave Taht  wrote:

> In terms of wifi history... since I go back to the 70s...
>
> was that we did not know how to do it - 73 we had aloha, which begat
> ethernet... and for years progress was slow. Even as late as 91 or so
> a "good" microwave link cost something like 40k an end, and required
> special cooling and permits on so on. Wifi was started as an ipx/spx
> bridge tech that didn't start to get anywhere until the mid 90s.
>
> It was far from obvious at any point that the cost reductions would
> take place that did, there was so much work in the analog domain that
> looked (at the time) resistant to moores law. As for spectrum, finding
> ways to leverage 2.4ghz cost metricom's backers in particular more
> money than I care to think about, and I'm always pointing at how the
> discovery that a more centralized clock and a retransmit at the mac
> layer is what eventually made 802.11b viable. Many other wireless
> ideas have been tried and died - wimax, for example, UWB, for another.
> Bluetooth has evolved into adding "discovery prototol", which was kind
> of unexpected... (there is even 6lopan over bluetooth now). The 5ghz
> spectrum users have tended to adopt their own mac, as has some other
> less popular bands.
>
> While I'm pretty happy that we've got much of the queuing theory for
> fixing 802.11n and 802.1ac nailed now, outstanding problems include
> the hidden station problem, the rise in the background noise levels,
> insufficient channels, and increasingly proprietary standards and
> chipsets, as well as transport, switching and routing protocols
> layered on top originally designed for isochronus transports.
>
> I like to think (or possibly delude myself), that the solutions to
> airtime fairness scheduling now emerging may one day lead to saner
> scheduling around the hidden station problem in particular. Otherwise,
> and elsewhere, there remain a lot of rocks to bang together, and a
> long list of other issues we've captured elsewhere.
>
> I am still periodically reviewing and updating this as we go along, as
> it remains the best central document we have on all that's wrong in
> wifi with some hints as to how to go about fixing them.
>
>
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

Hi Jonathan,
I think in 802.11ax the AP can schedule STAs to some extent so it looks
like that technique is coming soon.  It is a bw tradeoff per the RUs per
user.

Multi-User Uplink Operation

To coordinate uplink MU-MIMO or uplink OFDMA transmissions the AP sends a
trigger frame to all users. This frame indicates the number of spatial
streams and/or the OFDMA allocations (frequency and RU sizes) of each user.
It also contains power control information, such that individual users can
increase or reduce their transmitted power, in an effort to equalize the
power that the AP receives from all uplink users and improve reception of
frames from nodes farther away. The AP also instructs all users when to
start and stop transmitting. As Figure 10depicts, the AP sends a multi-user
uplink trigger frame that indicates to all users the exact moment at which
they all start transmitting, and the exact duration of their frame, to
ensure that they all finish transmitting simultaneously as well. Once the
AP receives the frames from all users, it sends them back a block ACK to
finish the operation.



*Figure 10. Coordinating uplink multi-user operation*




On Mon, Aug 27, 2018 at 12:52 AM Jonathan Morton 
wrote:

> > On 27 Aug, 2018, at 10:06 am, Bob McMahon 
> wrote:
> >
> > How can a centralized device predict the many "end stations'" network
> demand in its time scheduling?
>
> DOCSIS does it by initially giving stations a tiny window into which to
> send requests for time, which are granted by the head-end.  This introduces
> some latency.  Further requests for time can be appended to a real
> transmission, which helps efficiency slightly.
>
> Developing from that model, an AP might initially divide time evenly
> between stations, allowing them to send single large packets or several
> small packets without an explicit request for time - this is good for
> latency.  Along with that packet, the station could indicate to the AP that
> it has a queue of packets waiting, and the AP would take that into account
> when producing its next schedule.  It would also take into account its own
> queue.
>
> It may be possible to combine TDM with orthogonal coding.  Here the AP
> monitors the received signal strength of its stations, and instructs them
> to change power so as to minimise the difference between them.  This
> maximises the SNR for each, should two transmit simultaneously.  The
> tradeoff, of course, is that orthogonal coding permits a reduction in
> waiting to transmit, but requires a reduction in data rate during the
> transmission.  I'm sure other people have better data on that than I do.
>
>  - Jonathan Morton
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

hmm, "going back" to TDM, doesn't that lose the benefits and efficiencies
per statistical multiplexing?   How can a centralized device predict the
many "end stations'" network demand in its time scheduling?

Note: I think with 802.11ax this is happening to some extent per uplink
OFDMA but that requires both time scheduling and transmit power setting so
the AP receives the "simultaneous signals" with similar SINRs.   This is
supposed to help with LBT but not really completely solve it.

Curious if eliminating LBT is possible per a distributed solution (with
partial network awareness) vs having a centralized scheduler (with "full"
network awareness)?

Bob

On Sun, Aug 26, 2018 at 11:26 PM Jonathan Morton 
wrote:

> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
> wrote:
> >
> > Curious to how LBT can be solved at the PHY level and if the potential
> solution sets preserve the end to end principle.
>
> The usual alternatives include TDM, usually coordinated by a master device
> (eg. the AP); full-duplex operation via diplexers and/or orthogonal coding;
> and simply firing off a packet and retrying with exponential backoff if an
> acknowledgement is not heard.
>
> TDM and diplexing are already used by both DOCSIS and LTE.  They are
> proven technology.  However, in DOCSIS the diplexing is greatly simplified
> by the use of a copper channel rather than airwaves, and in LTE the
> diplexer is fitted only at the tower, not in each client - so the tower can
> transmit and receive simultaneously, but an individual client cannot, but
> this is still useful because there are many clients per tower.  Effective
> diplexers for wireless are expensive.
>
> Orthogonal coding is already used by GPS and, in a rather esoteric form,
> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
> GPS, it allows all of the satellites in the constellation to transmit on
> the standard frequency simultaneously, while still being individually
> distinguishable.  The data rate is very low, however, since each
> satellite's signal inherently has a negative SNR (because there's a dozen
> others shouting over it) - that's why it takes a full minute for a receiver
> to get a fix from cold, because it simply takes that long to download the
> ephemeris from the first satellite whose signal is found.
>
> A future version of wifi could reasonably use TDM, I think, but not
> diplexing.  The way this would work is that the AP assigns each station
> (including itself) a series of time windows in which to transmit as much as
> they like, and broadcasts this schedule along with its beacon.  Also
> scheduled would be windows in which the AP listens for new stations,
> including possibly other nearby APs with which it may mutually coordinate
> time.  A mesh network could thus be constructed entirely out of mutually
> coordinating APs if necessary.
>
> The above paragraph is obviously a giant handwave...
>
>  - Jonathan Morton
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

Curious to how LBT can be solved at the PHY level and if the potential
solution sets preserve the end to end principle.

Bob

On Sun, Aug 26, 2018 at 5:26 AM David P. Reed  wrote:

> Baran: I got the year wrong. I remember it as 1993, but it was 1994 CNGN
> speech he made, which is resurrected here:
> https://www.eff.org/pages/false-scarcity-baran-cngn-94
>
> Paul was educated in EE, as was I. So radio made sense to him. Unlike kids
> brought up on the idea that bits are and must be physically discrete
> spatial and temporal mechanical things.
>
> You know, one can have 1/10 of a bit of information, and store it in 1/10
> of a bit of storage. Or transmit a symbol that passes through local noise
> and comes out the other side uncorrupted.
>
> But kids trained in fancy CS depts. assume that bits require clear, empty,
> noiseless, pristine paths. Pure Bullshit. But CS and now many EE depts. and
> the FCC all proselytize such crap
>
> So scarcity is inventedand sustained.
>
> There is a reigning Supreme Court opinion, the law of the land, that says
> that there is by law a "finite number" of usable frequencies, and only one
> transmitter can be allowed to use it at a time. Like legislating that pi =
> 3 in a state, to make math easier.
>
> Except it is totally designed to create scarcity. And the State/Industry
> Nexus maintains it at every turn. It's why lunatic economists claim that
> spectrum is a form of property that can be auctioned. Like creating
> property rights to each acre of the sea, allowing owners to block shipping
> by buying a connected path down the mid Atlantic.
>
> We live in a Science Ignorant world. Intentionally. Even trained pH D.
> Engineers testify before the FCC to preserve these lies.
>
> Yeah, I sound nuts. Check it out.
>
>
> -Original Message-
> From: "Dave Taht" 
> Sent: Sat, Aug 25, 2018 at 5:22 pm
> To: dpr...@deepplum.com
> Cc: bloat-annou...@lists.bufferbloat.net, "bloat" <
> bl...@lists.bufferbloat.net>, "Make-Wifi-fast" <
> make-wifi-f...@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] closing up my make-wifi-fast lab
>
> On Sat, Aug 25, 2018 at 1:04 PM David P. Reed  wrote:
> >
> > WiFi is a bit harder than IP. But you know that.
> >
> > I truly believe that we need to fix the phy/waveform/modulation space to
> really scale up open wireless networking capability. LBT is the basic bug
> in WiFi, and it is at that layer, melow the MAC.
> >
> > I have tried for 20 years now to find a way to begin work at that
> project, by the way. There is also no major donor anywhere to be found for
> that work. Instead, any funds that seem to be appearing get attacked and
> sucked into projects that miss the point, being controlled by folks who
> oppose openness (e.g. WISPs wanting exclusive ownership of a market, such
> as so called SuperWiFi or whitespaces). I did once come close to a useful
> award when I was at MIT Media Lab, from NSF. But after the award, the
> funding was cut by 90%, leaving just enough to support a Master's thesis on
> co-channel sharing, using two 1st Gen USRPs. Using my own funds, spare
> time, and bubblegum and baling wire, I've slowly begun work on extra
> wideband FPGA based sounding-centric sharing in the 10 GHz Ham band. (500
> MHz wide modulation), where I can self certify multiple stations in a
> network.
> >
> > But the point is, I've failed, because there is less than zero support.
> There is active opposition, on top of cluelessness.
> >
> > Paul Baran tried in 1993 to push forward a similar agenda, famously. 99%
> of his concepts died.
>
> Cite?
>
> One of the things that bothers me about packet processing is that
> Donald Davies (the oft uncredited other founder of the concept) wrote
> 11 volumes on this subject. So far as I know, those have vanished to
> history.
>
> Periodically, when I get stuck on something in this field, I fantasize
> that scribbled in the margin of volume 9 was the solution to the
> problem.
>
> > Thanks to Apple, and lots of others, we got WiFi, barely. Industry hated
> that, and vow never to let that ever happen again.
>
> It really was a strange convolution of circumstances that led to wifi.
> When i first got it working in 1998, metricom ruled the world. They
> failed. After that, nobody thought it was feasible at scale until the
> concept of a mac retry emerged to fix the packet loss problem, and APs
> to provide a central clock (best we could do with the DSPs then).  So
> a window emerged (and yes, hugely driven by apple, but also by huge
> popular demand for "wireless freedom") to put "buggy" wireless tech on
> the crap 2.4 band in the hands of the people, it got established and
> made the coffee shop a workplace, and bigcos attempting to wipe it out
> (and largely, in the last few years, succeeding in dislodging it) have
> had an uphill battle.
>
> If metricom had succeeded, or the celluar folk got their
> implementations working only a few years faster, it would be a ver

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

I guess my question is can a WiFi transmitting device rely on primarily
energy detect and mostly ignore the EDCA probability game and rather search
for (or predict) unused spectrum per a time interval such that its digital
signal has enough power per its observed SNR?   Then detect "collisions"
(or, "superposition cases" per the RX not having sufficient SINR) via
inserting silent gaps in its TX used to sample ED, i.e. run energy detect
throughout the entire transmission?  Or better, no silent gaps, rather
detect if there is superimposed energy on it's own TX and predict a
collision (i.e. RX probably couldn't decode its signal) occurred?  If
doable, this seems simpler than having to realize centralized (or even
distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
token rings, etc. and not require media access coordination by things like
APs.

Bob

On Mon, Aug 27, 2018 at 1:34 AM Bob McMahon 
wrote:

> Hi Jonathan,
> I think in 802.11ax the AP can schedule STAs to some extent so it looks
> like that technique is coming soon.  It is a bw tradeoff per the RUs per
> user.
>
> Multi-User Uplink Operation
>
> To coordinate uplink MU-MIMO or uplink OFDMA transmissions the AP sends a
> trigger frame to all users. This frame indicates the number of spatial
> streams and/or the OFDMA allocations (frequency and RU sizes) of each user.
> It also contains power control information, such that individual users can
> increase or reduce their transmitted power, in an effort to equalize the
> power that the AP receives from all uplink users and improve reception of
> frames from nodes farther away. The AP also instructs all users when to
> start and stop transmitting. As Figure 10depicts, the AP sends a multi-user
> uplink trigger frame that indicates to all users the exact moment at which
> they all start transmitting, and the exact duration of their frame, to
> ensure that they all finish transmitting simultaneously as well. Once the
> AP receives the frames from all users, it sends them back a block ACK to
> finish the operation.
>
>
>
> *Figure 10. Coordinating uplink multi-user operation*
>
>
>
>
> On Mon, Aug 27, 2018 at 12:52 AM Jonathan Morton 
> wrote:
>
>> > On 27 Aug, 2018, at 10:06 am, Bob McMahon 
>> wrote:
>> >
>> > How can a centralized device predict the many "end stations'" network
>> demand in its time scheduling?
>>
>> DOCSIS does it by initially giving stations a tiny window into which to
>> send requests for time, which are granted by the head-end.  This introduces
>> some latency.  Further requests for time can be appended to a real
>> transmission, which helps efficiency slightly.
>>
>> Developing from that model, an AP might initially divide time evenly
>> between stations, allowing them to send single large packets or several
>> small packets without an explicit request for time - this is good for
>> latency.  Along with that packet, the station could indicate to the AP that
>> it has a queue of packets waiting, and the AP would take that into account
>> when producing its next schedule.  It would also take into account its own
>> queue.
>>
>> It may be possible to combine TDM with orthogonal coding.  Here the AP
>> monitors the received signal strength of its stations, and instructs them
>> to change power so as to minimise the difference between them.  This
>> maximises the SNR for each, should two transmit simultaneously.  The
>> tradeoff, of course, is that orthogonal coding permits a reduction in
>> waiting to transmit, but requires a reduction in data rate during the
>> transmission.  I'm sure other people have better data on that than I do.
>>
>>  - Jonathan Morton
>>
>>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

Hi Luca,

What is non private spectrum defined as per  "I don't yet see how a non
private spectrum can be shared  w/o LBT."

Thanks,
Bob




On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello <
luca.muscarie...@gmail.com> wrote:

> Jonathan,
>
> Not that giant handwaving though.
> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The almost
> is necessary as it operates in 2.4/5Ghz bands.
> Similar to what you describe, and is coming very soon in shipping
> products.
>
> RTS/CTS is still a LBT to create a window where TDM can be done.
> I don't yet see how a non private spectrum can be shared  w/o LBT.
>
> On the other hand, medium sharing is one thing, the other thing is
> capacity.
> There is no way to efficiently share a medium if this is used close to its
> theoretical capacity.
>
> Capacity as #of stations per band including #SSID per band. Today scaling
> can be achieved
> with careful radio planning for spatial diversity or dynamic bean forming.
>
> When you approach capacity with WiFi you only see beacon traffic and
> almost zero throughput.
> Cannot forget Mobile World Congress where you can measure several
> thousands of SSIDs on 2.4
> and several hundreds of SSID in 5GHz. But even LTE was very close to
> capacity.
>
> Dave,
> Having air time fairness in open source is a significant achievement. I
> don't see a failure.
>
> Luca
>
>
> On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton 
> wrote:
>
>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon 
>> wrote:
>> >
>> > Curious to how LBT can be solved at the PHY level and if the potential
>> solution sets preserve the end to end principle.
>>
>> The usual alternatives include TDM, usually coordinated by a master
>> device (eg. the AP); full-duplex operation via diplexers and/or orthogonal
>> coding; and simply firing off a packet and retrying with exponential
>> backoff if an acknowledgement is not heard.
>>
>> TDM and diplexing are already used by both DOCSIS and LTE.  They are
>> proven technology.  However, in DOCSIS the diplexing is greatly simplified
>> by the use of a copper channel rather than airwaves, and in LTE the
>> diplexer is fitted only at the tower, not in each client - so the tower can
>> transmit and receive simultaneously, but an individual client cannot, but
>> this is still useful because there are many clients per tower.  Effective
>> diplexers for wireless are expensive.
>>
>> Orthogonal coding is already used by GPS and, in a rather esoteric form,
>> by MIMO-grade wifi.  IMHO it works rather better in GPS than in wifi.  In
>> GPS, it allows all of the satellites in the constellation to transmit on
>> the standard frequency simultaneously, while still being individually
>> distinguishable.  The data rate is very low, however, since each
>> satellite's signal inherently has a negative SNR (because there's a dozen
>> others shouting over it) - that's why it takes a full minute for a receiver
>> to get a fix from cold, because it simply takes that long to download the
>> ephemeris from the first satellite whose signal is found.
>>
>> A future version of wifi could reasonably use TDM, I think, but not
>> diplexing.  The way this would work is that the AP assigns each station
>> (including itself) a series of time windows in which to transmit as much as
>> they like, and broadcasts this schedule along with its beacon.  Also
>> scheduled would be windows in which the AP listens for new stations,
>> including possibly other nearby APs with which it may mutually coordinate
>> time.  A mesh network could thus be constructed entirely out of mutually
>> coordinating APs if necessary.
>>
>> The above paragraph is obviously a giant handwave...
>>
>>  - Jonathan Morton
>>
>> ___
>> Bloat mailing list
>> bl...@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

ok thanks, that's helpful.  I guess I thought if astrophysicists can direct
image exoplanets

a WiFi device should be able to detect superposition  - though, talk about
some giant hand waving! ;)

Bob

On Mon, Aug 27, 2018 at 12:45 PM Jonathan Morton 
wrote:

> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon 
> wrote:
> >
> > I guess my question is can a WiFi transmitting device rely on primarily
> energy detect and mostly ignore the EDCA probability game and rather search
> for (or predict) unused spectrum per a time interval such that its digital
> signal has enough power per its observed SNR?   Then detect "collisions"
> (or, "superposition cases" per the RX not having sufficient SINR) via
> inserting silent gaps in its TX used to sample ED, i.e. run energy detect
> throughout the entire transmission?  Or better, no silent gaps, rather
> detect if there is superimposed energy on it's own TX and predict a
> collision (i.e. RX probably couldn't decode its signal) occurred?  If
> doable, this seems simpler than having to realize centralized (or even
> distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
> token rings, etc. and not require media access coordination by things like
> APs.
>
> The software might be simpler, but the hardware would need to be
> overspecified to the point of making it unreasonably expensive for consumer
> devices.
>
> Radio hardware generally has a significant TX/RX turnaround time, required
> for the RX deafening circuits to disengage.  Without those deafening
> circuits, the receivers would be damaged by the comparatively vast TX power
> in the antenna.
>
> So in practice, it's easier to measure SNR at the receiver, or indirectly
> by observing packet loss by dint of missing acknowledgements returned to
> the transmitter.
>
>  - Jonathan Morton
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

I thought that RTS/CTS would handle the case of hidden nodes, i.e. a device
that fails to successfully transmit can resort to RTS/CTS to get the
receiver to reserve time for it.  Also, lack of a RX ack seems ok to
trigger MAC level retransmits.

It seems the LBT bug is the collision avoidance overheads when it isn't
needed, i.e. no other energy would cause the RX PHY to fail its decode and
the EDCA backoffs had no benefit, stochastic or otherwise.   Optimizing
that out is said to be not possible from local information only and per
"shared" spectrum.

Bob


On Mon, Aug 27, 2018 at 3:33 PM David Lang  wrote:

> On Mon, 27 Aug 2018, Jonathan Morton wrote:
>
> > So in practice, it's easier to measure SNR at the receiver, or
> indirectly by
> > observing packet loss by dint of missing acknowledgements returned to
> the
> > transmitter.
>
> Also, there may be other transmitters that the recipient of the packets
> can hear
> that you cannot hear, so it's not possible to detect colliding
> transmissions
> directly in all cases.
>
> This is another trap that digital/wired people fall into that doesn't
> really
> apply in the analog/radio world.
>
> David Lang
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

Hmm, not sure I understand the distinction.   CTS per the AP informs those
other transmitters to stay quiet per the CTS NAV.  I may be
misunderstanding things.  Thanks for the continued discussions.  It helps
to better thoroughly understand the issues.

Bob

On Mon, Aug 27, 2018, 6:52 PM David Lang  wrote:

> On Mon, 27 Aug 2018, Bob McMahon wrote:
>
> > I thought that RTS/CTS would handle the case of hidden nodes, i.e. a
> device
> > that fails to successfully transmit can resort to RTS/CTS to get the
> > receiver to reserve time for it.  Also, lack of a RX ack seems ok to
> > trigger MAC level retransmits.
>
> the problem isn't getting the receiver to reserve time for it, it's
> getting the
> other transmitter(s) to not step on it when it transmits. Those other
> transmitters may belong to different people, sharing a channel with your
> system
> and nothing else.
>
> David Lang
>
> > It seems the LBT bug is the collision avoidance overheads when it isn't
> > needed, i.e. no other energy would cause the RX PHY to fail its decode
> and
> > the EDCA backoffs had no benefit, stochastic or otherwise.   Optimizing
> > that out is said to be not possible from local information only and per
> > "shared" spectrum.
> >
> > Bob
> >
> >
> > On Mon, Aug 27, 2018 at 3:33 PM David Lang  wrote:
> >
> >> On Mon, 27 Aug 2018, Jonathan Morton wrote:
> >>
> >>> So in practice, it's easier to measure SNR at the receiver, or
> >> indirectly by
> >>> observing packet loss by dint of missing acknowledgements returned to
> >> the
> >>> transmitter.
> >>
> >> Also, there may be other transmitters that the recipient of the packets
> >> can hear
> >> that you cannot hear, so it's not possible to detect colliding
> >> transmissions
> >> directly in all cases.
> >>
> >> This is another trap that digital/wired people fall into that doesn't
> >> really
> >> apply in the analog/radio world.
> >>
> >> David Lang
> >>
> >
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

Minimizing power is rule #2 per Paul Banan.

SOME KINDERGARTEN RULES (written in 1994)

   To take the fullest advantage of our new technology with its sharing
   of a common resource requires that our smart transmitters and
   receivers cooperate. This may sound complicated, but the rules to make
   maximum effective use of the shared band are simple -- primarily a
   matter of common decency in sharing resources. The rules are somewhat
   similar to those you learned in kindergarten, assuming you lived in a
   tough neighborhood.

   Rule #1. Keep away from the big bullies in the playground. (Avoid the
   strongest signals.)

   Rule #2. Share your toys. (Minimize your transmitted power. Use the
   shortest hop distances feasible. Minimize average power density per
   Hertz.)

   Rule #3. If you have nothing to say, keep quiet.

   Rule #4. Don't pick on the big kids. (Don't step on strong signals.
   You're going to get clobbered.)

   Rule #5. If you feel you absolutely must beat up somebody, be sure to
   pick someone smaller than yourself. (Now this is a less obvious one,
   as weak signals represent far away transmissions; so your signals will
   likely be attenuated the same amount in the reverse direction and
   probably not cause significant interference.)

   Rule #6. Don't get too close to your neighbor. Even the weakest
   signals are very strong when they are shouted in your ear.

   Rule #7. Lastly, don't be a cry baby. (If you insist on using obsolete
   technology that is highly sensitive to interfering signals, don't
   expect much sympathy when you complain about interfering signals in a
   shared band.)

Bob


On Thu, Aug 30, 2018 at 12:12 PM bkil  wrote:

> Full-duplex still needs some work, but there is definite progress:
> http://www.ti.rwth-aachen.de/~taghizadehmotlagh/FullDuplex_Survey.pdf
>
> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/TR-1.pdf
> https://sing.stanford.edu/fullduplex/
>
> https://spectrum.ieee.org/tech-talk/telecom/wireless/new-full-duplex-radio-chip-transmits-and-receives-wireless-signals-at-once
> http://fullduplex.rice.edu/research/
>
> On Mon, Aug 27, 2018 at 9:46 PM Jonathan Morton 
> wrote:
>
>> > On 27 Aug, 2018, at 10:11 pm, Bob McMahon 
>> wrote:
>> >
>> > I guess my question is can a WiFi transmitting device rely on primarily
>> energy detect and mostly ignore the EDCA probability game and rather search
>> for (or predict) unused spectrum per a time interval such that its digital
>> signal has enough power per its observed SNR?   Then detect "collisions"
>> (or, "superposition cases" per the RX not having sufficient SINR) via
>> inserting silent gaps in its TX used to sample ED, i.e. run energy detect
>> throughout the entire transmission?  Or better, no silent gaps, rather
>> detect if there is superimposed energy on it's own TX and predict a
>> collision (i.e. RX probably couldn't decode its signal) occurred?  If
>> doable, this seems simpler than having to realize centralized (or even
>> distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
>> token rings, etc. and not require media access coordination by things like
>> APs.
>>
>> The software might be simpler, but the hardware would need to be
>> overspecified to the point of making it unreasonably expensive for consumer
>> devices.
>>
>> Radio hardware generally has a significant TX/RX turnaround time,
>> required for the RX deafening circuits to disengage.  Without those
>> deafening circuits, the receivers would be damaged by the comparatively
>> vast TX power in the antenna.
>>
>> So in practice, it's easier to measure SNR at the receiver, or indirectly
>> by observing packet loss by dint of missing acknowledgements returned to
>> the transmitter.
>>
>>  - Jonathan Morton
>>
>> ___
>> Make-wifi-fast mailing list
>> make-wifi-f...@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab

[Bob McMahon]

Agreed that incentives are non trivial.   I found this article about bike
share redistribution interesting:

New York's bike share system pays rider to make it run better


Bob

On Thu, Aug 30, 2018 at 1:36 PM bkil  wrote:

> Yes, I've read that part in the past. These are very good rules of
> thumb, but there are many inefficiencies to cope with.
>
> Note that not all wireless users are "rude" on purpose. It's just that
> if you want to keep in touch with your relatives in the nearby town,
> you use the minimal needed power for the given circumstances that
> happens to be a large amount (point to point).
>
> 1a.
> Let's focus on a point to point link first. Omni antennas would
> trivially interfere with our own neighborhood as well while working a
> long link. However, because not everyone has roof access, space for a
> large aerial or money for an expensive one, using an omni would be
> considered a local optimum for many.
>
> 1b.
> Let's assume that we are a good citizen using more expensive highly
> directional antennae and we live at the perimeter. Considering that
> the reception angle of the most practical ones should be 10-20
> degrees, this probably easily illuminates the perimeter of the
> neighboring town. That wouldn't be deadly interference from that
> distance, but it means that it's not scalable in the sense that not
> everyone living at the perimeter could communicate with their
> respective relative in the neighboring town. It would need a high
> level of sophistication to achieve that. It would be much more
> efficient and cost effective if these people cooperated and pooled in
> resources to build only a handful of well-placed high power
> transcievers that they digitally shared with each other using low
> power and inexpensive last mile access technologies. But as the old
> saying goes, "The common horse is worst shod." So it is cleanest if we
> simply pay for equipment and maintenance, and a new telco is born.
> Then as competition intensifies, the spectrum gets clogged up, etc.
>
> 1c
> If we aren't fortunate enough to live at the perimeter, we need to
> cooperate with hops towards the perimeter. It is energetically the
> most efficient to have directional links between each of them, but
> that requires 2-3 antennae at each node. The ones at the perimeter
> definitely need at least two. For one who lives at the perimeter and
> only communicates with the neighboring town, it is a local optimum to
> not purchase and operate two sets of antennae, cables, radios and
> other tools. Without incentives, taking this to the extreme creates a
> disconnected ring of perimeter around the town who point outwards. So
> in worst case, ones in the middle would again need to up their power
> again to work the distance.
>
> 2.
> To achieve hop optimization, have we reached a level of social
> sophistication and digital literacy where we can mesh with everything
> and anyone in sight? I feel that to be a stretch, but let's pretend
> that we have. Now the "feasible" part is still problematic.
> Let's stick with the above scenario of inter-town links or sparsely
> populated areas. If there is nobody to mesh with, we need to
> artificially deploy and maintain intermediate nodes for this purpose.
> Who will pay for this? If nobody, it is not feasible. See above point.
> The local optimum of each user is to not deploy intermediate nodes,
> and we have reached the tragedy of the commons again.
>
> And we didn't even consider "rude" users analogue to an uninvited
> guest who gobbles all your snacks when dropping by. These are only a
> minority, but they take plenty. Though UWB wasn't there yet in 1994,
> it's feasible today. Just imagine if a school deployed a 1GHz UWB
> transciever on UHF to stream their backups or research data all day
> over the air because it is less expensive (free) compared to cables.
> It would not be feasible to peer with any intermediate hop because
> nobody has such expensive and advanced hardware, so they'd happily
> operate a point to point link to the nearby town (or partner
> institution?). That would definitely spoil the fun for many along the
> route and no amount of LBT can fix that. Also they could have decide
> to use >100GHz instead, but there is no incentive if the whole
> spectrum is free, as higher frequencies propagate worse and equipment
> costs more.
>
> So all in all, without incentives, system spectral efficiency doesn't
> come naturally - you have to work for it. Hard.
> I'm not saying that we should give up, but it takes much more than a
> few sentences to come up with rules that really work in real life
> situations when scaled up. There are pro and contra in many methods of
> spectrum allocations, no doubt about that, but I don't feel that there
> exists one clear "best" method that we are purposefully neglecting.
>
> Of course at the same time, scalable u

[Cerowrt-devel] Which mDNS package for modern OpenWrt

[Rich Brown]

Can anyone give advice about the best mDNS package to install these days? There 
seem to be several contenders: mdnsutils, avahi, olsrd-mod-mdns, and umdns... 

Thanks.

Rich
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] ath10k test of openwrt head

[Dave Taht]

On Mon, Mar 30, 2020 at 3:35 AM Toke Høiland-Jørgensen  wrote:
>
> Dave Taht  writes:
>
> > well, aqm is engaging, but waaay too late - 2-3 sec latencies on a
> > given 10mbit wifi test.
>
> So this would be without AQL, right?

Well I thought the code was in that build which is what triggered me
to try. Turned out it landed a few hours later.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5c57d15aed3ed7fd5ed077833044660df52c1bf4


hours later.
>
> -Toke



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] eero gains competition in plumewifi

[Dave Taht]

wow this was an old message thread. plume had last I looked 3
different firmware versions and had been unable to make 'em work with
prior versions of aql

On Mon, Mar 30, 2020 at 4:21 AM Erkki Lintunen  wrote:
>
> On 06/20/2016 09:16 AM, Dave Taht wrote:
> > I sure wish I knew how they are implementing diversity routing and if
> > they are bothering to pay attention to make-wifi-fast
> >
> > https://www.plumewifi.com/
>
>
> Quite a staffing for a startup, the web site lists 46 names and
> positions from which 26 are named as engineers. Wondering if they
> already are in the business of WiFi chip and RF engineering, which
> enable them to do some "magic" to make a network of their own from the
> plumewifi plugs. On staffing resources this isn't on par with Eero, I think.
>
> - Erkki
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] tuning up the ath10k in the ubnt products

[Dave Taht]

As debris from the original project, I had a half dozen ubnt mesh
(pro, lite, mesh) boxes, "bricked", and I'd felt at the time the only
way to bring them back to life was to solder a header onto each and
recreate them via the serial port. I'd disassembled a bunch but my
tired old eyes wouldn't let me get the dang pins back on easily.

It turns out that the "reflash the OEM firmware" method,  "just
works". (see near the bottom of:
https://openwrt.org/toh/ubiquiti/unifiac ) -

w00t! now that the basic AQL support has landed (yesterday) for the
ath10k-ct in openwrt I was kind of inspired to do a build of my own,
folding back in things I cared about that aren't in the default build
(babel, dnsmasq-dnssec).

The PTSD from all that time "having to build the donuts'... barely had
time to kick in. time for some comparative benchmarks!

and who knows? perhaps I'll (we'll?) get around to

* cutting the codel target to something less on 5ghz
* Fiddling with sce and trying out the optimizations in fq_codel_fast
* Getting back on top of the iwl (specifically ax200) products
* poking into multi-core shaping
* etc (for a large value of etc. Has source specific ipv6 RA landed
anywhere yet? dns-sd?)


...

Elsewhere... Trying to get more ubnt edgerouter folk to try cake...

https://www.reddit.com/r/Ubiquiti/comments/fqmrxt/smart_queue_speed_setting/

https://www.reddit.com/r/HomeNetworking/comments/fp70rh/combatting_bufferbloat/

Thx lochnair for getting the build server back up

On Mon, Mar 30, 2020 at 8:33 AM Dave Taht  wrote:
>
> On Mon, Mar 30, 2020 at 3:35 AM Toke Høiland-Jørgensen  wrote:
> >
> > Dave Taht  writes:
> >
> > > well, aqm is engaging, but waaay too late - 2-3 sec latencies on a
> > > given 10mbit wifi test.
> >
> > So this would be without AQL, right?
>
> Well I thought the code was in that build which is what triggered me
> to try. Turned out it landed a few hours later.
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5c57d15aed3ed7fd5ed077833044660df52c1bf4
>
>
> hours later.
> >
> > -Toke
>
>
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] ath10k test of openwrt head

[Dave Taht]

I just wanted to say I just tested that last openwrt patch... and it
was *beautiful*. I went from where
a load test could crack 3 seconds on the uap mesh router... and
disable the babel protocol, to 20ms

/me wipes away tear of joy

On Mon, Mar 30, 2020 at 8:33 AM Dave Taht  wrote:
>
> On Mon, Mar 30, 2020 at 3:35 AM Toke Høiland-Jørgensen  wrote:
> >
> > Dave Taht  writes:
> >
> > > well, aqm is engaging, but waaay too late - 2-3 sec latencies on a
> > > given 10mbit wifi test.
> >
> > So this would be without AQL, right?
>
> Well I thought the code was in that build which is what triggered me
> to try. Turned out it landed a few hours later.
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5c57d15aed3ed7fd5ed077833044660df52c1bf4
>
>
> hours later.
> >
> > -Toke
>
>
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel