> On 12 Jul, 2021, at 11:04 pm, Bob McMahon via Make-wifi-fast
> wrote:
>
> "Flow control in store-and-forward computer networks is appropriate for
> decentralized execution. A formal description of a class of "decentralized
> flow control algorithms" is given. The feasibility of maximizing po
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 st
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 conne
I have seen some performance tests that do explicit DNS timing tests separate
from other throughput/latency tests.
Since DNS uses UDP (even if it then falls back to TCP in some cases), UDP
performance (and especially probability of loss at congested links) is very
important.
David Lang
On M
UDP is better for getting actual packet latency, for sure. TCP is
typical-user-experience-latency though,
so it is also useful.
I'm interested in the test and visualization side of this. If there were a way
to give engineers
a good real-time look at a complex real-world network, then they hav
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 store-and-forward computer
Measuring one or a few links provides a bit of data, but seems like if someone
is trying to understand
a large and real network, then the OWD between point A and B needs to just be
input into something much
more grand. Assuming real-time OWD data exists between 100 to 1000 endpoint
pairs, has
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 wri
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 (p
On Monday, July 12, 2021 9:46am, "Livingood, Jason"
said:
> I think latency/delay is becoming seen to be as important certainly, if not a
> more direct proxy for end user QoE. This is all still evolving and I have to
> say is a super interesting & fun thing to work on. :-)
If I could manag
> 2) Users are pissed off, because they clicked on a web page, and got nothing
> back. They retry on their screen, or they try another site. Meanwhile, the
> underlying TCP connection remains there, pumping the network full of more
> packets on that old path, which is still backed up with packet
11 matches
Mail list logo
