--- Begin Message ---
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.
--- 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
--- 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 ---
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
--- 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
--- 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 gives full
--- Begin Message ---
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
--- Begin Message ---
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.
--- Begin Message ---
I believe end host's TCP stats are insufficient as seen per the "failed"
congested control mechanisms over the last decades. I think Jaffe pointed
this out in 1979 though he was using what's been deemed on this thread as
"spherical cow queueing theory."
"Flow control in
--- Begin Message ---
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
--- Begin Message ---
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.
--- Begin Message ---
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()
--- Begin Message ---
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
--- Begin Message ---
"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
--- Begin Message ---
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
--- Begin Message ---
"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
--- Begin Message ---
"Control at endpoints benefits greatly from even small amounts of
information supplied by the network about the degree of congestion present
on the path."
Agreed. The ECN mechanism seems like a shared thermostat in a building.
It's basically an on/off where everyone is
--- Begin Message ---
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
--- 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
--- Begin Message ---
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.
--- 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)
--- 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
--- Begin Message ---
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
--- Begin Message ---
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:
>
>
>
>
--- Begin Message ---
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
--- Begin Message ---
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
--- 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
--- Begin Message ---
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!
--- Begin Message ---
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
--- Begin Message ---
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
--- 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
--- Begin Message ---
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
--- Begin Message ---
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
--- Begin Message ---
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
--- Begin Message ---
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
--- Begin Message ---
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
--- Begin Message ---
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
--- Begin Message ---
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
--- Begin Message ---
Ok, adding support for TCP_WINDOW_CLAMP and TCP_NOTSENT_LOWAT into iperf 2
seems useful for TCP WiFi latency related testing. These option names are
quite obfuscated. I can't see many but some ultimate networking geeks
knowing what these actually do.
Here are some proposed
39 matches
Mail list logo
