Re: [Bloat] [Make-wifi-fast] waves podcast is out

Fronthaul networks, preferably fiber, to a 20+ year concentrator (not a 802.3 switch) at the same location of an electrical panel. Get rid of the SoC and AP which is basically a Sun workstation with NICs and use remote radio heads (or in switch speak, port ASICs.) This design will work for 50+

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

Stuart's analogy seems better to me as it allows people to do something else while waiting for an under-provisioned resource. And they may decide that the wait isn't worth it at all. If the constraint moves to "entering into the store" or "arrival rate to the grocery store doors" then the queue

Re: [Bloat] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

Thanks Toke. Bob On Wed, Nov 23, 2022 at 5:50 AM Toke Høiland-Jørgensen wrote: > Bob McMahon writes: > > > Does the TSQ code honor no-aggregation per voice access class or > > TCP_NODELAY where the app making the socket write calls knows that the > WiFi > > aggregation isn't likely helpful?

Re: [Bloat] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

Does the TSQ code honor no-aggregation per voice access class or TCP_NODELAY where the app making the socket write calls knows that the WiFi aggregation isn't likely helpful? Sorry, my Linux stack expertise is quite limited. Bob On Tue, Nov 22, 2022 at 12:53 PM Toke Høiland-Jørgensen wrote: >

Re: [Bloat] [Make-wifi-fast] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

I don't know Qualcomm's offerings but here are some from Broadcom. https://www.broadcom.com/products/wireless/wireless-lan-infrastructure/bcm67263 The BCM4916 forwarding plane is done with a network processor and doesn't run Linux. Linux may be used to build the forwarding tables and this is

Re: [Bloat] [Make-wifi-fast] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

Some main purposes of the WiFi CPU is 802.3 to 802.11 L2 translational bridging and handling 802.11 protocols for things like association. Most forwarded packets don't hit the main CPU anymore. This first sw to hw transition occurred decades ago with real internet routers (equipment that run IGPs

Re: [Bloat] [Make-wifi-fast] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

An AP's radio complex may have a CPU but that doesn't mean it is the standard linux stack as most think of it. Many consider this as part of "firmware" which can be Linux, a Linux derivative or other. Also, there are some levels of wired/wireless forwarding plane integration done at the hardware

Re: [Bloat] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

Thanks for sharing this. Curious about how the xTSQ value can be set? Can it be done with sysctl? *We continue our analysis by using the ms-version of TSQ patch, which enables the tune of the TSQ size allowing each TCP variant to enqueue more than 1 ms of data at the current TCP rate. In

Re: [Bloat] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat

Hi All, I just wanted to say thanks for this discussion. I always learn from each and all of you. Bob On Thu, Oct 20, 2022 at 12:40 PM Sebastian Moeller wrote: > Hi Dave, > > > > On Oct 20, 2022, at 21:12, Dave Taht via Rpm > wrote: > > > > On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via

Re: [Bloat] [Make-wifi-fast] [Rpm] The most wonderful video ever about bufferbloat

The demo is nice but a way to measure this with full statistics can be actionable by engineers. I did add support for tcp write time with histograms, where setting TCP_NOTSENT_LOWAT, can give a sense of the network responsiveness as the writes will await the select() indicating the pipeline has

Re: [Bloat] [Make-wifi-fast] [Rpm] The most wonderful video ever about bufferbloat

Intel has a good analogous video on this with their CPU video here going over branches and failed predictions. And to Stuart's point, the longer pipelines make the forks worse in the amount of in-process bytes that need to be thrown away. Interactivity, in my

Re: [Bloat] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat

*[SM] How does that generalize to internet access links? My gut feeling is that an FQ scheduler comes close.* Probably not possible. Current fiber SFP 100Gs optics are the most economic per the SERDES/Laser interface. Any other SFP is suboptimal, probably for the next decade. Then there are still

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

I agree with Stuart that there is no reason for shared lines in the first place. It seems like a design flaw to have a common queue that congests in a way that impacts the one transmit unit as the atomic forwarding plane unit. The goal of virtual output queueing

Re: [Bloat] [Rpm] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

With full respect to open source projects like OpenWRT, I think from an energy, performance & going forward perspective the AP forwarding plane will be realized by "transistor engineers." This makes the awareness around bloat by network engineers needed even more because those design cycles take

Re: [Bloat] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

ives to a self-fulfilling prophecy - that's why the >>> tests >>> >have to come up with artificial conditions that can't be simply >>> defined.) >>> >>> Hrm, so the RRUL test, while not the end all of bufferbloat/working >>> conditions tests, is not th

Re: [Bloat] [Rpm] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

I agree that bufferbloat awareness is a good thing. The issue I have is the approach - ask consumers to "detect it" and replace a device with a new one, that may or may not, meet all the needs of the users. Better is that network engineers "design bloat out" from the beginning starting by

Re: [Bloat] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

y flows to emulate > DASH 'streaming', and a horde of small greedy flows that mostly end inside > the initial window and slow start. But at its core existing RRUL already > gives a useful estimate on how a link behaves under saturating loads all > the while being relatively simple. >

Re: [Bloat] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

y solution that drives to a self-fulfilling prophecy - that's why the tests have to come up with artificial conditions that can't be simply defined.) Bob On Mon, Oct 10, 2022 at 3:57 PM David Lang wrote: > On Mon, 10 Oct 2022, Bob McMahon via Bloat wrote: > > > I think conflating bufferblo

Re: [Bloat] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

I think conflating bufferbloat with latency misses the subtle point in that bufferbloat is a measurement in memory units more than a measurement in time units. The first design flaw is a queue that is too big. This youtube video analogy doesn't help one understand this important point. Another

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

Sure thing. Defining some multivariate signals using "non-bulk flow" or "realistic" traffic scenarios that could be automated (and a proxy for user QoE) would be very useful for L2 driver, MAC/PHY, and AP scheduling engineers allowing them to provide the best quality packet forwarding plane

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

Thanks Neal. You might want to check out the flows released as iperf 2. Basically instantiate flows and run them. There typically is a controller running python3 (v 3.10 or better) that uses ssh pipes to DUTs. The design is event driven

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

Hi Neal, These look like steady-state bulk flow tests unless I'm missing something. Bob On Sun, Aug 28, 2022 at 11:43 AM Neal Cardwell wrote: > Sure. For testing these kinds of properties of the BBR algorithm we use > various transperf test cases. The transperf tool is something Soheil Hassas

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

Curious to what you're doing during development, if you can share? Thanks, Bob On Sat, Aug 27, 2022 at 7:44 AM Neal Cardwell wrote: > Hi Bob, > > Good question. I can imagine a number of different techniques to generate > and measure the traffic flows for this kind of study, and don't have any

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

Hi Neal, Any thoughts on tooling to generate and measure the traffic flows BBR is designed to optimize? I've been adding some low duty cycle support in iperf 2 with things like --bounceback and --burst-period and --burst-period

Re: [Bloat] [Make-wifi-fast] marketing wifi and broadband in the c-suite

Thanks for sharing this. It's interesting that the focus is still on speed and not so much on latency/responsiveness. *In addition to navigating the competitive landscape, BSPs must also continually hone theirmarketing messages to attract and recruit new subscribers. As Figure 10

Re: [Bloat] [Make-wifi-fast] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency

Thanks for pointing out the congestion window. Not sure why it doesn't increase. I think that takes a stack expert ;) The run below with rx window clamp does seem to align with linux blocking the writes. Yes, in the previous runt the worst cases were 5.121ms which does align with the RTT. As a

Re: [Bloat] [Make-wifi-fast] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency

This is linux. The code flow is burst writes until the burst size, take a timestamp, call select(), take second timestamp and insert time delta into histogram, await clock_nanosleep() to schedule the next burst. (actually, the deltas, inserts into the histogram and user i/o are done in another

Re: [Bloat] [Make-wifi-fast] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency

I'm confused. I don't see any blocking nor partial writes per the write() at the app level with TCP_NOTSENT_LOWAT set at 4 bytes. The burst is 40K, the write size is 4K and the watermark is 4 bytes. There are ten writes per burst. The S8 histograms are the times waiting on the select(). The

Re: [Bloat] [Starlink] [Make-wifi-fast] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency

Hi Bjørn, I find, when possible, it's preferred to take telemetry data of actual traffic (or reads and writes) vs a proxy. We had a case where TCP BE was outperforming TCP w/VI because BE had the most engineering resources assigned to it and engineers did a better job with BE. Using a proxy

Re: [Bloat] [Make-wifi-fast] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency

Thanks Stuart this is helpful. I'm measuring the time just before the first write() (of potentially a burst of writes to achieve a burst size) per a socket fd's select event occurring when TCP_NOT_SENT_LOWAT being set to a small value, then sampling the RTT and CWND and providing histograms for

[Bloat] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency

Hi All, Sorry for the spam. I'm trying to support a meaningful TCP message latency w/iperf 2 from the sender side w/o requiring e2e clock synchronization. I thought I'd try to use the TCP_NOTSENT_LOWAT event to help with this. It seems that this event goes off when the bytes are in flight vs have

Re: [Bloat] Relentless congestion control for testing purposes

hmm, this looks interesting to a test & measurement guy. Can it be done with a setsockopt? I might want to add this as an iperf2 option, particularly if it's broadly available, Thanks, Bob On Fri, Oct 1, 2021 at 9:22 AM Luigi Rizzo wrote: > On Wed, Sep 29, 2021 at 1:17 AM Dave Taht wrote: > >

Re: [Bloat] [Starlink] [Cerowrt-devel] Little's Law mea culpa, but not invalidating my main point

Hi All, I do appreciate this thread as well. As a test & measurement guy here are my conclusions around network performance. Thanks in advance for any comments. Congestion can be mitigated the following ways o) Size queues properly to minimize/negate bloat (easier said than done with tech like

Re: [Bloat] [Starlink] Anhyone have a spare couple a hundred million ... Elon may need to start a go-fund-me page!

sorry about that The below was written two decades ago and we're still fiddling around with fraudband. Hey, today in 2021, comcast will sell a select few 2 Gb/s symmetric over a fiber strand using a juniper switch, leased of course, designed in 2011. Talk about not keeping up with modern mfg of

Re: [Bloat] [Starlink] [Cake] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

This amplitude only channel estimate shown was taken from radios connected using conducted equipment or cables. It illustrates how non-ideal conducted equipment based testing is, i.e. our signal processing and MCS rate selection engineers aren't being sufficiently challenged! The cost of $2.5K

Re: [Bloat] [Starlink] [Cake] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

The slides show that for WiFi every transmission produces a complex frequency response, aka the h-matrix. This is valid for that one transmission only. The slides show an amplitude plot for a 3 radio device hence the 9 elements per the h-matrix. It's assumed that the WiFi STA/AP is stationary

Re: [Bloat] [Make-wifi-fast] [Starlink] [Cake] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

Some people put them on roombas. Doesn't work well inside these http://ramseytest.com/index.php On Sun, Aug 8, 2021 at 11:48 AM Jonathan Morton wrote: > > On 8 Aug, 2021, at 9:36 pm, Aaron Wood wrote: > > > > Less common, but something I still see, is that a moving station has > continual

Re: [Bloat] [Starlink] [Cake] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

We have hundreds of test rigs in multiple labs all over geography. Each rig is shielded from the others using things like RF enclosures. We want reproducibility in the RF paths/channels as well as variability. Most have built fixed rigs using conducted equipment. This is far from anything real. A

Re: [Bloat] [Starlink] [Cake] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

Thanks - your wording is more accurate. The path loss matrix is hollow symmetric while the RF channel is reciprocal. The challenge comes when adding phase shifters. Then it's not just a path loss matrix anymore. Bob On Sat, Aug 7, 2021 at 10:04 PM Dick Roy wrote: > > > >

Re: [Bloat] [Starlink] [Cake] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

The four nodes being connected per a five branch tree using variable attenuators on the branches can produce hidden nodes quite readily. The solutions for the attenuations are straight forward per being given the desired distance matrices. The challenging part is supporting distance matrices that

Re: [Bloat] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

Another thing to keep in mind is we're using a poor man's version of emulating "passive channels" so the device transmit powers can provide power asymmetry. The distance matrix is about the h-matrices (as shown early in the slides.) Even with that though, the h-matrix elements aren't likely

Re: [Bloat] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

fair enough, but for this "RF emulator device" being able to support distance matrices, even hollow symmetric ones, is much better than what's typically done. The variable solid state phase shifters are 0-360 so don't provide real time delays either. This is another "something is better than

Re: [Bloat] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

The distance matrix defines signal attenuations/loss between pairs. It's straightforward to create a distance matrix that has hidden nodes because all "signal loss" between pairs is defined. Let's say a 120dB attenuation path will cause a node to be hidden as an example. AB CD

Re: [Bloat] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

I found the following talk relevant to distances between all the nodes. https://www.youtube.com/watch?v=PNoUcQTCxiM Distance is an abstract idea but applies to energy into a node as well as phylogenetic trees. It's the same problem, i.e. fitting a distance matrix using some sort of tree. I've

Re: [Bloat] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

We find four nodes, a primary BSS and an adjunct one quite good for lots of testing. The six nodes allows for a primary BSS and two adjacent ones. We want to minimize complexity to necessary and sufficient. The challenge we find is having variability (e.g. montecarlos) that's reproducible and

Re: [Bloat] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

That distance matrices manage energy between nodes. The slides show a 5 branch tree to realize 4 nodes (and that distance matrix) and a diagram for 11 degrees of freedom for 6 nodes (3 BSS) The python code will compute the branch attenuations based on a supplied distance matrix. There will of

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

Thanks for this. I plan to purchase the second volume to go with my copy of volume 1. There is (always) more to learn and your expertise is very helpful. Bob PS. As a side note, I've added support for TCP_NOTSENT_LOWAT in iperf 2.1.4 and it's

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

Just an FYI, iperf 2 uses a 4 usec delay for TCP and 100 usec delay for UDP to fill the token bucket. We thought about providing a knob for this but decided not to. We figured a busy wait CPU thread wasn't a big deal because of the trend of many CPU cores. The threaded design works well for this.

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

i option sets the socket option and causes the use of select for writes (vs a write spin loop.) Thanks in advance for any suggestions here, Bob On Wed, Jul 14, 2021 at 6:27 PM Holland, Jake wrote: > From: Bob McMahon via Bloat > > Date: Wed,2021-07-14 at 11:38 AM > > One

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

Thanks for this. I find it both interesting and useful. Learning from those who came before me reminds me of "standing on the shoulders of giants." I try to teach my kids that it's not so much us as the giants we choose - so choose judiciously and, more importantly, be grateful when they provide

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

"the infinite TCP flow that converges to a steady behavior is purely academic" We find this to be mostly true. Sadly, the tools such as iperf drove to this condition. While still useful, not realistic. We added, in iperf 2, the ability to test TCP bursts (--burst-size and --burst-period) over

Re: [Bloat] [Cake] Little's Law mea culpa, but not invalidating my main point

Agreed that UDP is important but it's also much easier to test and debug for WiFi coders. We find it's the connect() and TCP control loop that challenges WiFi logic systems on end hosts. APs are a whole different story per things like OFDMA. Nothing is simple anymore it seems. Reminds me of the

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

We in WiFi find UDP, while useful, also has severe limitations. The impact to the TCP control loop matters a lot for things like aggregation. Visualizations can be useful but also a bit limiting. We use stats techniques such as PCA which is more mathematical and less visual. We find syscall

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

To be clear, it's a OS write() using a socket opened with TCP and the final OS read() of that write. The write size is set using -l or --length. OWD requires --trip-times option. Bob On Mon, Jul 12, 2021 at 11:21 AM Bob McMahon wrote: > iperf 2 supports OWD and gives full histograms for TCP

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

iperf 2 supports OWD and gives full histograms for TCP write to read, TCP connect times, latency of packets (with UDP), latency of "frames" with simulated video traffic (TCP and UDP), xfer times of bursts with low duty cycle traffic, and TCP RTT (sampling based.) It also has support for sampling

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

One example question is, if it seems useful to control and queuing theory experts to feedback the non-parametric OWD distributions to the sending device's transport layer control loop? We find kolmogorov-smirnov distance matrices as useful for clustering non-parametric distributions and chose to

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

"Analyzing that is really difficult, and if we don’t measure and sense, we have no hope of understanding, controlling, or ameliorating such situations." It is truly a high honor to observe the queueing theory and control theory discussions to the world class experts here. We simple test guys must

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

A bit off topic per the control and queueing theory discussion; a four second latency is going to fail our regression automation rigs. Way too many WiFi users, particularly for games, require sub few hundreds of milliseconds and sometimes even much lower. A TCP connect() getting behind a 4 second

Re: [Bloat] [Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

Thanks very much for this response. I need to dig in a bit more for sure. iperf 2 will give every UDP packet's OWD (if the clocks are sync'd) and will also provide TCP write to read latencies, both supported in histogram forms. So that's raw samples so to speak. I'm hooking up some units across

Re: [Bloat] [Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

I can't speak for others. I've been successful in early prototyping using one for simplistic off-diagonal h-matrix testing, i.e. varying the h-matrix condition numbers. I see this as a small step in the right direction for conductive, automated, and reproducible testing. Developing a system that

Re: [Bloat] [Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

Sorry, I should have been more clear. Not a fixed butler matrix but a device with solid state, programmable, phase shifters, 0 - 360 degrees. It's a way to create multiple phy channels and affect and vary the off diagonal elements of a MIMO H-matrix using conducted parts. Then automation software

Re: [Bloat] [Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

The four part attenuator part would be more interesting to me if it also had a solid state phase shifters. This allows for testing 2x2 MIMO testing per affecting the spatial stream eigen vectors/values. Bob PS. The price per port isn't competitive. Probably a good idea to survey the market

Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

I think we need the language of math here. It seems like the network power metric, introduced by Kleinrock and Jaffe in the late 70s, is something useful. Effective end/end queue depths per Little's law also seems useful. Both are available in iperf 2 from a test perspective. Repurposing test

Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

I think even packets are a network construct. End/end protocols don't write packets. They mostly make writes() and reads and have no clue about packets. Except for, of course, UDP which you know everything about being the original designer. Agreed the telemetry is most interesting and a huge

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

ok, though I see that as accuracy in the first derivative more than inaccurate precision that mitigates the need for "ground truths." Bob On Tue, May 18, 2021 at 3:29 PM David Lang wrote: > precision without accuracy is having clocks that may differ from each > other by a > few seconds, but

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

The idea of precision without accuracy seems an issue. Curios about that. Bob On Mon, May 17, 2021 at 11:31 PM Neil Davies wrote: > Matt > > This is such a great idea that the Broadband Forum has been working on it > for a couple of years now - see TR452.1 >

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

hmm, it seems kinda like the speed of causality applied to computers that share information in order to proceed Bob On Wed, May 12,

Re: [Bloat] [Ecn-sane] [Make-wifi-fast] D* tcp looks pretty good, on paper

For that run it was two nodes each using 8 core (16 hyperthreads) systems running Fedora 30 each with a spectracom GPS disciplined OCXO over pcie. The two nodes are connected via a single 10G switch with 10G copper. I use this rig as part of iperf 2 development. I haven't published any results

Re: [Bloat] [Make-wifi-fast] D* tcp looks pretty good, on paper

Could be interesting to use an isochronous traffic profile as well as take histograms, using the actual end/end frame latency instead of RTT. This does require clock sync. CLIENT SPECIFIC OPTIONS*--isochronous[=**fps*:*mean*,*stdev**]*send isochronous traffic with frequency frames per second and

Re: [Bloat] [Make-wifi-fast] D* tcp looks pretty good, on paper

FYI, one can try this out using iperf 2.1 with --trip-times . This gives end/end delay at the application level. One can use --trip-times when clocks are sync'd to get the write to read latencies which

Re: [Bloat] [Make-wifi-fast] [Cake] dslreports is no longer free

--- Begin Message --- Sorry for being a bit off topic but we find average latency not all that useful. A full CDF is. The next best is a box plot with outliers which can be presented parametrically as a few numbers. Most customers want visibility into the PDF tail. Also, we're moving to socket