1 ms (20%)
40=40:0:0:0:0:0:0:0 0
[ 1] 9.00-9.20 sec 40.0 KBytes 1.63 Mbits/sec 200.665 ms (20%)
40=40:0:0:0:0:0:0:0 0
[ 1] 0.00-10.00 sec 400 KBytes 328 Kbits/sec
402=402:0:0:0:0:0:0:0
Bob
On Thu, Oct 28, 2021 at 9:04 AM Christoph Paasch wrote:
>
>
> > On Oct 26, 2021,
:0 0
[ 1] 0.-10.0031 sec 400 KBytes 328 Kbits/sec
104=104:0:0:0:0:0:0:0
Bob
On Tue, Oct 26, 2021 at 6:12 PM Eric Dumazet wrote:
>
>
> On 10/26/21 4:38 PM, Christoph Paasch wrote:
> > Hi Bob,
> >
> >> On Oct 26, 2021, at 4:23 PM, Bob McMahon <mailto:bob.mcma
t; On Oct 25, 2021, at 9:24 PM, Eric Dumazet
> wrote:
> >
> >
> >
> > On 10/25/21 8:11 PM, Stuart Cheshire via Bloat wrote:
> >> On 21 Oct 2021, at 17:51, Bob McMahon via Make-wifi-fast <
> make-wifi-f...@lists.bufferbloat.net> wrote:
> >>
>
side the TCP traffic. The requirement
> for this to work is that the TWAMP packets are placed in the same queue(s)
> as the TCP traffic, and that the impact of measurement traffic is small
> enough so as not to interfere too much with your TCP results.
> Just my two cents, hope it's h
has been to
measure first write() to final read() and compute the e2e delay. This
requires clock sync on the ends. (We're using ptp4l with GPS OCXO
atomic references for that but this is typically only available in some
labs.)
Bob
On Mon, Oct 25, 2021 at 8:11 PM Stuart Cheshire wrote:
&
--- Begin Message ---
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
--- Begin Message ---
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
handing out money, SpaceX is foolish not to apply for
> it.
>
> David Lang
>
> On Tue, 10 Aug 2021, Jeremy Austin wrote:
>
> > Date: Tue, 10 Aug 2021 12:33:11 -0800
> > From: Jeremy Austin
> > To: dick...@alum.mit.edu
> > Cc: Cake List ,
> > Make-Wi
are doomed to fail I suspect that it is in
> calibration where the major difference in performance between vendors’’
> products can be found :^
>
>
>
> It’s complicated …
>
>
> --
>
> *From:* Bob McMahon [mailto:bob.mcma...@broadcom.c
; a complex function causes.
>
> Hope this helps ... probably a bit more than you really wanted to know as
> queuing theorists, but ...
>
> -Original Message-
> From: Starlink [mailto:starlink-boun...@lists.bufferbloat.net] On Behalf
> Of
> Rodney W. Grimes
> Sent:
--- Begin Message ---
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
variable range and variable mixing is a step towards closing the gap.
Bob
On Sat, Aug 7, 2021 at 10:07 PM Dick Roy wrote:
>
>
>
> --
>
> *From:* Starlink [mailto:starlink-boun...@lists.bufferbloat.net] *On
> Behalf Of *Bob McMahon
> *Sent:* Monday
wrote:
>
>
>
> --
>
> *From:* Starlink [mailto:starlink-boun...@lists.bufferbloat.net] *On
> Behalf Of *Bob McMahon
> *Sent:* Monday, August 2, 2021 8:23 PM
> *To:* David Lang
> *Cc:* starl...@lists.bufferbloat.net; Make-Wifi-fast; Cake List;
>
[mailto:starlink-boun...@lists.bufferbloat.net] On Behalf
> Of
> David Lang
> Sent: Monday, August 2, 2021 9:31 PM
> To: Bob McMahon
> Cc: starl...@lists.bufferbloat.net; Make-Wifi-fast; Cake List;
> co...@lists.bufferbloat.net; cerowrt-devel; bloat
> Subject: Re: [Starlink] [Cake]
x27;re
> talking 10s to low 100s of feet, not miles)
>
> David Lang
>
> On Mon, 2 Aug 2021, Bob McMahon wrote:
>
> > fair enough, but for this "RF emulator device" being able to support
> > distance matrices, even hollow symmetric ones, is much better than wh
tation, you don't adjust it's receive
> sensitivity.
>
> David Lang
>
> On Mon, 2 Aug 2021, Bob McMahon wrote:
>
> > Date: Mon, 2 Aug 2021 20:23:06 -0700
> > From: Bob McMahon
> > To: David Lang
> > Cc: Ben Greear ,
> > Luca Muscarie
ut you need to have a way
> to
> configure your lab to include them before you consider any
> settings/algorithm
> ready to try in the wild.
>
> David Lang
>
> On Mon, 2 Aug 2021, Bob McMahon wrote:
>
> > We find four nodes, a primary BSS and an adjunct one quite goo
--- Begin Message ---
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 s
--- Begin Message ---
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'
--- Begin Message ---
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 mat
it.) But the story is not over as
> much work has yet to be done to develop the algorithms that can properly
> deal with congestion in the sense that this email chain continues to
> discuss it.
>
> Best,
> Len
>
>
>
>
>
>
>
> On Jul 13, 2021, at 10:49 AM,
ook like something in between.
> https://burntchrome.blogspot.com/2016/09/iperf3-and-microbursts.html
>
>
>
> I'll let others try to figure out how build and tune the knobs, but the
>> data acquisition and
>> visualization is something we might try to accomplish. I
s "nerd language" that is beyond human comprehension.) This
cli 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 vi
eve they are
> >> difficult to reproduce (we are always talking about very short TCP
> flows -
> >> the infinite TCP flow that converges to a steady behavior is purely
> >> academic).
> >>
> >> By the way, Little's law is a strong tool when it comes to average
1617.3326146 or if behind a paywall
> https://www.dcs.warwick.ac.uk/~florin/lib/sigmet19b.pdf
>
>
> Amr Rizk (amr.r...@uni-due.de)
> University of Duisburg-Essen
>
> -Ursprüngliche Nachricht-
> Von: Bloat Im Auftrag von Ben Greear
> Gesen
www.dcs.warwick.ac.uk/~florin/lib/sigmet19b.pdf
>
>
> Amr Rizk (amr.r...@uni-due.de)
> University of Duisburg-Essen
>
> -Ursprüngliche Nachricht-
> Von: Bloat Im Auftrag von Ben Greear
> Gesendet: Montag, 12. Juli 2021 22:32
> An: B
ng we might try to accomplish. I have a feeling
> I'm
> > not the
> > first person to think of this, howeverprobably someone already has
> done
> > such
> > a thing.
> >
> > Thanks,
> > Ben
> >
> > On 7/12/21 1:04 PM, Bob McMahon
oweverprobably someone already has
> done such
> a thing.
>
> Thanks,
> Ben
>
> On 7/12/21 1:04 PM, Bob McMahon wrote:
> > I believe end host's TCP stats are insufficient as seen per the "failed"
> congested control mechanisms over the last decad
r just ping 8.8.8.8 which is
> 20ms from everywhere due to
> $magic).
>
> Endpoints could also triangulate a bit if needed, using some anchor points
> in the network
> under test.
>
> Thanks,
> Ben
>
> On 7/12/21 11:21 AM, Bob McMahon wrote:
> > iperf 2 supports OWD
--- Begin Message ---
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 gi
--- Begin Message ---
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 s
n Sat, Jul 10, 2021 at 12:51 PM Bob McMahon
wrote:
> "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
;> Where does the Poisson assumption come from? Well, like many theorems,
>> it is the simplest tractable closed form solution - it creates a simplified
>> view, by being a "single-parameter" distribution (the parameter is called
>> lambda for a Poisson distributio
many theorems,
>> it is the simplest tractable closed form solution - it creates a simplified
>> view, by being a "single-parameter" distribution (the parameter is called
>> lambda for a Poisson distribution). And the analysis of a simple queue
>> with poisson arriva
Tuesday, July 6, 2021 9:46am, "Ben Greear"
> said:
>
> > Hello,
> >
> > I am interested to hear wish lists for network testing features. We make
> test
> > equipment, supporting lots
> > of wifi stations and a distributed architecture, with built
ers, or mostly
> just radio manufacturers such
> as BCM?
>
> In case someone has one of these that has a sane API, I'd consider adding
> automation support
> to drive it while running throughput or RvR or whatever other types of
> tests seem interesting.
>
> Thanks,
s pricing offlist if you
> wish.
>
> Thanks,
> Ben
>
> On 7/6/21 1:43 PM, Bob McMahon wrote:
> > 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 spa
p, tcp,
> ipv6, http, ... protocols,
> and open to creating/improving some of our automated tests.
>
> I know Dave has some test scripts already, so I'm not necessarily looking
> to reimplement that,
> but more fishing for other/new ideas.
>
> Thanks,
> Ben
>
> On
--- Begin Message ---
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.
--- Begin Message ---
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 inter
et 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.
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
>
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 overh
hip-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
l 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 unre
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
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
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
tion (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
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
ision
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 smalle
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 th
uming 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 s
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 McMah
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
channe
otocol
> 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, &quo
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 stre
structure 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,
> 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, whic
stalltions, 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
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.
61 matches
Mail list logo
