SEQ 158157 1 438 11701 <= sequential connection vector; start time (usecs); no. of epochs; subset id; global id; w 64240 17520 <= window sizes (initiator and acceptor) r 8074 <= RTT (usecs.) l 0.000000 0.000000 <= loss rates > 527 <= a_1 in bytes t 9616 <= ta_1 in usecs < 4589 <= b_1 in bytes
You should have a UNC side (one tmix instance) and an Internet side (another tmix instance). The UNC side controls the initiator side of connection initiated from UNC and the acceptor side of connection initiated from the Internet. The Internet side should control the other side of these connections. The tmix instance of the UNC side produces traffic in the inbound and in the outboud direction, and the same is true for the tmix instance of the Internet side (since the two instances talk to each other).
CINIT SIDE CRECV SIDE
a from cinit
b from crecv
cinit conns initiated \ ---> / crecv conns initiated
| |
| ------------------------ |
| |
crecv conns accepted / <--- \ cinit cons accepted
b from cinit
a from crecv
I'd say yes. Tmix is generating traffic from a collection of connection descriptions (i.e. connection vector) which includes a relative start time. The program works hard to start connections exactly at the time they are expected to start. For example, if you set tmix to start at 11 AM, and the collection of connections includes one connection with a relative start time of 120 seconds and another one with a relative start time of 180 seconds, tmix will start these connections at exactly 11:02 and 11:03 AM. This means that the two tmix instances must share the same absolute start time, i.e., 11 AM. Otherwise, one of them will start too early, before the other side is ready to accept connections and generate traffic. Given the low quality of PC clock, hosts running tmix should have their clocks synchronized right before an experiment.
Note however that this does not mean that perfect clock synchronization is required. In my experiments, I work with 42 machines, which I synchronize using NTP right before the experiment (using a simple ntpdate -s). This provides a rough synchronization in the order of milliseconds, which the program can accommodate just fine. So yes, in your experiments, it is important to synchronize the clocks of the two hosts you are using. Otherwise, one instance will start generating traffic before the other one is even listening for connections. It is also important that the configuration files of all of your tmix instances are set to the same start time and that this start time is in the future, or the program gets confused. When I ran a test, I first ran ntpdate in the two hosts, and then I use a little script that is something like
START=`date -v +3S "+%H:%M:%S"` tmix -s $START host1.conf rsh $HOST tmix -s $START host2.conf
Here -s is use to overwrite the start time in the configuration files (host1.conf and host2.conf). This sets the start time of the two tmix instances exactly to three seconds in the future. Something like this should always work, and eliminate any timing issues. You could also change the start times by hand in configuration files, but this editing becomes cumbersome when you run several times. During the real experiments in the lab, with the 42 machines, the experiment management program, treplay.pl, generates, prior to the experiment, 42 configuration files with the same start time.