For some time, UserSwitch has suffered from abysmal performance due
to rx and tx offload settings. In the latest Ubuntu 16.04/Linux 4.4
kernel, it simply doesn't work with the default settings, since
packets with bad TCP checksums are generated at one end, passed through
the user switch, and dropped at the other. It doesn't seem to be
something we can fix in UserSwitch itself although it may be possible
to do something in the C code of the Stanford reference switch and
CPqD switch.
Previously the standard OpenFlow poort (6653) that Controller()
may be listening at would conflict with the default listenPort
for switch 20 (usually UserSwitch 20), breaking waitConnected()
and disconnecting that switch from the network in general.
Fixes#668
It's very useful to be able to pass parameters to tests.
Unfortunately, our previous --test argument syntax didn't
permit it, because , was used as a delimiter for multiple
tests. With this change, we change , to become a delimiter
for arguments, as it is with other options to mn. For now,
we introduce + as a separator, as it is legal in filenames
and therefore shouldn't conflict with special characters
used by Unix shells.
We also reorganize mn a bit to make it hopefully slightly
clearer.
Unfortunately pexpect() seems to be timing out with a 30 second
timeout rather than the 600 seconds we are passing in. How
could this even be working normally? It is puzzling. We are
going to try specifying the timeout in the spawn() call.
Also if the test fails, we use %e format for readability.
With a 1 ms delay, the performance tests periodically fails
under nested virtualization, which is how we are testing it.
Increasing the delay should make the effect (lower TCP
data rates as latency increases, due to TCP's congestion
control algorithm) more pronounced and robust.
If we want to observe a monotonic affect, we should
make sure that we are in fact CPU limited where it
matters. In this case, we are CPU limiting the hosts,
and the iperf client uses a lot of CPU. We need to
reduce the CPU allocation so that iperf is in fact
CPU bound.
We also correct the CPU allocation so that the client
and server each receive 50% of the total. Previously
we were specifying the per-host CPU allocation, so
45% meant we were allocating 90% of the overall CPU,
which seems a bit confusing. On the other hand, now
at 40% each host gets 20% of the CPU, which could also
be considered slightly confusing!
Although the client transmit rate is going to be the
limiting factor, we still measure the received data
rate at the server, because that is more interesting
than the initial burst of buffering at the client.
Measuring at the server becomes more important as
we reduce the iperf time.
The output is also changed slightly, and the test has
been updated appropriately.
Although we could use print() from __future__, this messes
up scripts which use examples as modules.
The simple, if not nicest for 2.7, solution is to use
info(), output() and other mininet.log functions. The disadvantage
is that we may have to adjust things if we change info() to
add automatic newlines, but we can burn that bridge in Mininet
3.x.
Presumably daemons, race conditions, or ephemeral processes
can cause the ps output to vary slightly. We allow up to
two differing lines to account for this.
Fixes#651
The version string changed in tshark 2.0.2 in Ubuntu 16.
Perhaps we should just check for the version string itself
to be more robust but this is probably OK for now.
This makes the mid-level net.add*() API symmetric.
You can now delete hosts, switches, controllers and links using
a new net.del*() API, as well as del net[ 'nodename' ].
Previously we were using both ip link and ifconfig - not only is
this inconsistent and redundant, but it also broke when newer
ip link changed the reported names of certain interfacs to
"h1-eth0@36:".
Fixes#592
It's a bad idea for all Mininet VMs to share the same SSH keys.
Certainly users can regenerate their own keys, but it's better
if we don't ship a key and simply regenerate it on boot.
Keeping "use" for now even though it seems harder to remember
than "run". And the build/test options are probably much
clearer being inline in the help.
This is more complicated than it should be. We are also relying on
the fact that waitOutput should eat extra prompts most of the time.
Still not perfect - it's hard to get this exactly right, and we
should try to make it easier!
Fixes#589
It appears that read() has been blocking for some time,
so for now it makes sense to change the documentation to
match the functionality!
It's not entirely clear if monitor() expects this functionality.
However, with the current blocking read() semantics, it should
definitely return (and not call read()) on a poll timeout.
So, we now return the poll() result from waitReadable() (which
should have done this already probably) and check it. In the
fullness of time, we still need to revisit the whole I/O API
and make sure that it is consistent, sane, correctly documented,
and used correctly in the examples.
See #588 for more comments.
I'm not sure whether we really need to turn off ip_forward before
flushing iptables, but it might possibly be useful to avoid certain
unexpected behavior.
The justification for this is that 1) the options are
already documented in the API documentation and 2) the
class names are fairly self-explanatory, so adding short
descriptions doesn't add much.
In the future, however, we could add a short description
by simply using the first line or sentence of the docstring;
note that docstrings would have to be canonicalized, which
they aren't now.
When I changed the switch implementations to call super().stop(),
I neglected to include a Switch.stop() method which didn't call
terminate(). This broke switch s1 stop and s1.stop().
Fixes#497
Bob Lantz