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 competition.
On Tue, Jul 6, 2021 at 6:46 AM Ben Greear <gree...@candelatech.com
<mailto:gree...@candelatech.com>> wrote:
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-in udp, 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 7/2/21 4:28 PM, Bob McMahon wrote:
> 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 techniques to
actual
> traffic could be useful. Hence the question around what exact telemetry
is useful to apps making socket write() and read() calls.
>
> Bob
>
> On Fri, Jul 2, 2021 at 10:07 AM Dave Taht <dave.t...@gmail.com
<mailto:dave.t...@gmail.com> <mailto:dave.t...@gmail.com
<mailto:dave.t...@gmail.com>>> wrote:
>
> In terms of trying to find "Quality" I have tried to encourage folk
to
> both read "zen and the art of motorcycle maintenance"[0], and
Deming's
> work on "total quality management".
>
> My own slice at this network, computer and lifestyle "issue" is
aiming
> for "imperceptible latency" in all things. [1]. There's a lot of
> fallout from that in terms of not just addressing queuing delay, but
> caching, prefetching, and learning more about what a user really
needs
> (as opposed to wants) to know via intelligent agents.
>
> [0] If you want to get depressed, read Pirsig's successor to
"zen...",
> lila, which is in part about what happens when an engineer hits an
> insoluble problem.
> [1] https://www.internetsociety.org/events/latency2013/
<https://www.internetsociety.org/events/latency2013/>
>
>
>
> On Thu, Jul 1, 2021 at 6:16 PM David P. Reed <dpr...@deepplum.com
<mailto:dpr...@deepplum.com> <mailto:dpr...@deepplum.com
<mailto:dpr...@deepplum.com>>> wrote:
> >
> > Well, nice that the folks doing the conference are willing to
consider that quality of user experience has little to do with signalling rate at the
> physical layer or throughput of FTP transfers.
> >
> >
> >
> > But honestly, the fact that they call the problem "network
quality" suggests that they REALLY, REALLY don't understand the Internet isn't the
hardware or
> the routers or even the routing algorithms *to its users*.
> >
> >
> >
> > By ignoring the diversity of applications now and in the future,
and the fact that we DON'T KNOW what will be coming up, this conference will
likely fall
> into the usual trap that net-heads fall into - optimizing for some
imaginary reality that doesn't exist, and in fact will probably never be what users
> actually will do given the chance.
> >
> >
> >
> > I saw this issue in 1976 in the group developing the original
Internet protocols - a desire to put *into the network* special tricks to optimize
ASR33
> logins to remote computers from terminal concentrators (aka remote
login), bulk file transfers between file systems on different time-sharing
systems, and
> "sessions" (virtual circuits) that required logins. And then trying to exploit
underlying "multicast" by building it into the IP layer, because someone
> thought that TV broadcast would be the dominant application.
> >
> >
> >
> > Frankly, to think of "quality" as something that can be "provided" by "the
network" misses the entire point of "end-to-end argument in system design".
> Quality is not a property defined or created by The Network. If you
want to talk about Quality, you need to talk about users - all the users at all
times,
> now and into the future, and that's something you can't do if you
don't bother to include current and future users talking about what they might
expect to
> experience that they don't experience.
> >
> >
> >
> > There was much fighting back in 1976 that basically involved "network
experts" saying that the network was the place to "solve" such issues as
quality,
> so applications could avoid having to solve such issues.
> >
> >
> >
> > What some of us managed to do was to argue that you can't "solve"
such issues. All you can do is provide a framework that enables different uses to
> *cooperate* in some way.
> >
> >
> >
> > Which is why the Internet drops packets rather than queueing
them, and why diffserv cannot work.
> >
> > (I know the latter is conftroversial, but at the moment, ALL of
diffserv attempts to talk about end-to-end applicaiton specific metrics, but
never, ever
> explains what the diffserv control points actually do w.r.t. what
the IP layer can actually control. So it is meaningless - another violation of the
> so-called end-to-end principle).
> >
> >
> >
> > Networks are about getting packets from here to there,
multiplexing the underlying resources. That's it. Quality is a whole different thing.
Quality can
> be improved by end-to-end approaches, if the underlying network
provides some kind of thing that actually creates a way for end-to-end
applications to
> affect queueing and routing decisions, and more importantly getting
"telemetry" from the network regarding what is actually going on with the other
> end-to-end users sharing the infrastructure.
> >
> >
> >
> > This conference won't talk about it this way. So don't waste your
time.
> >
> >
> >
> >
> >
> >
> >
> > On Wednesday, June 30, 2021 8:12pm, "Dave Taht" <dave.t...@gmail.com
<mailto:dave.t...@gmail.com> <mailto:dave.t...@gmail.com
<mailto:dave.t...@gmail.com>>> said:
> >
> > > The program committee members are *amazing*. Perhaps, finally,
we can
> > > move the bar for the internet's quality metrics past endless,
blind
> > > repetitions of speedtest.
> > >
> > > For complete details, please see:
> > > https://www.iab.org/activities/workshops/network-quality/
<https://www.iab.org/activities/workshops/network-quality/>
> > >
> > > Submissions Due: Monday 2nd August 2021, midnight AOE (Anywhere
On Earth)
> > > Invitations Issued by: Monday 16th August 2021
> > >
> > > Workshop Date: This will be a virtual workshop, spread over
three days:
> > >
> > > 1400-1800 UTC Tue 14th September 2021
> > > 1400-1800 UTC Wed 15th September 2021
> > > 1400-1800 UTC Thu 16th September 2021
> > >
> > > Workshop co-chairs: Wes Hardaker, Evgeny Khorov, Omer Shapira
> > >
> > > The Program Committee members:
> > >
> > > Jari Arkko, Olivier Bonaventure, Vint Cerf, Stuart Cheshire, Sam
> > > Crowford, Nick Feamster, Jim Gettys, Toke Hoiland-Jorgensen,
Geoff
> > > Huston, Cullen Jennings, Katarzyna Kosek-Szott, Mirja
Kuehlewind,
> > > Jason Livingood, Matt Mathias, Randall Meyer, Kathleen Nichols,
> > > Christoph Paasch, Tommy Pauly, Greg White, Keith Winstein.
> > >
> > > Send Submissions to: network-quality-workshop...@iab.org
<mailto:network-quality-workshop...@iab.org>
<mailto:network-quality-workshop...@iab.org
<mailto:network-quality-workshop...@iab.org>>.
> > >
> > > Position papers from academia, industry, the open source
community and
> > > others that focus on measurements, experiences, observations and
> > > advice for the future are welcome. Papers that reflect
experience
> > > based on deployed services are especially welcome. The
organizers
> > > understand that specific actions taken by operators are
unlikely to be
> > > discussed in detail, so papers discussing general categories of
> > > actions and issues without naming specific technologies,
products, or
> > > other players in the ecosystem are expected. Papers should not
focus
> > > on specific protocol solutions.
> > >
> > > The workshop will be by invitation only. Those wishing to attend
> > > should submit a position paper to the address above; it may
take the
> > > form of an Internet-Draft.
> > >
> > > All inputs submitted and considered relevant will be published
on the
> > > workshop website. The organisers will decide whom to invite
based on
> > > the submissions received. Sessions will be organized according
to
> > > content, and not every accepted submission or invited attendee
will
> > > have an opportunity to present as the intent is to foster
discussion
> > > and not simply to have a sequence of presentations.
> > >
> > > Position papers from those not planning to attend the virtual
sessions
> > > themselves are also encouraged. A workshop report will be
published
> > > afterwards.
> > >
> > > Overview:
> > >
> > > "We believe that one of the major factors behind this lack of
progress
> > > is the popular perception that throughput is the often sole
measure of
> > > the quality of Internet connectivity. With such narrow focus,
people
> > > don’t consider questions such as:
> > >
> > > What is the latency under typical working conditions?
> > > How reliable is the connectivity across longer time periods?
> > > Does the network allow the use of a broad range of protocols?
> > > What services can be run by clients of the network?
> > > What kind of IPv4, NAT or IPv6 connectivity is offered, and are
there firewalls?
> > > What security mechanisms are available for local services, such
as DNS?
> > > To what degree are the privacy, confidentiality, integrity and
> > > authenticity of user communications guarded?
> > >
> > > Improving these aspects of network quality will likely depend on
> > > measurement and exposing metrics to all involved parties,
including to
> > > end users in a meaningful way. Such measurements and exposure
of the
> > > right metrics will allow service providers and network
operators to
> > > focus on the aspects that impacts the users’ experience most
and at
> > > the same time empowers users to choose the Internet service
that will
> > > give them the best experience."
> > >
> > >
> > > --
> > > Latest Podcast:
> > >
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
<https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/>
> > >
> > > Dave Täht CTO, TekLibre, LLC
> > > _______________________________________________
> > > Cerowrt-devel mailing list
> > > cerowrt-de...@lists.bufferbloat.net
<mailto:cerowrt-de...@lists.bufferbloat.net> <mailto:cerowrt-de...@lists.bufferbloat.net
<mailto:cerowrt-de...@lists.bufferbloat.net>>
> > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
<https://lists.bufferbloat.net/listinfo/cerowrt-devel>
> > >
>
>
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
<https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/>
>
> Dave Täht CTO, TekLibre, LLC
> _______________________________________________
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
<mailto:make-wifi-f...@lists.bufferbloat.net>
<mailto:make-wifi-f...@lists.bufferbloat.net
<mailto:make-wifi-f...@lists.bufferbloat.net>>
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
<https://lists.bufferbloat.net/listinfo/make-wifi-fast>
>
>
> This electronic communication and the information and any files
transmitted with it, or attached to it, are confidential and are intended solely
for the
use of
> the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy laws, or
otherwise
> restricted from disclosure to anyone else. If you are not the intended
recipient or the person responsible for delivering the e-mail to the intended
recipient,
> you are hereby notified that any use, copying, distributing,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited. If you
> received this e-mail in error, please return the e-mail to the sender,
delete it from your computer, and destroy any printed copy of it.
>
> _______________________________________________
> Starlink mailing list
> starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink
>
--
Ben Greear <gree...@candelatech.com <mailto:gree...@candelatech.com>>
Candela Technologies Inc http://www.candelatech.com
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of
the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise
restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient,
you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you
received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
