Here's a way to analyze the results of a test.  First I'll tell you how to
eyeball what is happening from the output files, and then how to generate
graphs to look at.

OUTPUT FILES

There are three (kinds of) output files worth looking at: the output from
the global scheduler (media-net/mmsched/gs.out), from the local schedulers
(ls7771.out, etc.), and from the video receiver (trace5000.out).

Global scheduler output
-----------------------

The global scheduler output prints records that indicate the state of links
and the network configuration.  The format of a record is

  Time Event arg1 arg2 ... etc.

That is, all records begin with the time that event took place, followed by
the name of the event.  The events are:

RECONFIG -- this is when the configuration of the network (that is, the
assignment of operations to nodes) has changed.  The first argument is the
utility value being used, and the second is a list of hosts on which
assignments are placed.  For example:

  0.000000 RECONFIG 1.00 pc1.pc2.pc3

This indicates that at time 0, a RECONFIG took place.  Utility 1.0 could be
achieved, and nodes pc1, pc2, and pc3 were assigned to.

BWUPDATE -- this is when a message has been received from a local scheduler
that indicates the current bandwidth usage for a link has reached a ceiling
(i.e. there is insufficient bandwidth available).  The first argument is the
link name, the second and third are the actual bandwidth usage, and the
fourth is the attempted usage; this fourth will always be greater than the
second and third.

BWREPORT -- this is when a message has been received from a local scheduler
that indicates the current bandwidth usage for a link under normal
operation. The first argument is the link name, the second is the assumed
maximum available bandwidth, and the third is the bandwidth currently being
used.  This will always be <= the maximum.

BWCREEP -- this is a note that the global scheduler is "creeping" the
bandwidth, assuming (hoping?) that more is available.  The first argument is
the link name, and the second is assumed amount available.

Looking at the trace5001c.out file (excerpted below), we can see that at
time zero, the path goes through node C (pc3).  Almost immediately (time
1.019), we discover that not enough bandwidth is available on link
192.168.2.3, so the GS reschedules and switches to go through node D (pc4),
using link 192.168.1.3.  Now enough bandwidth is available, and things go
OK.  As time goes on, the GS "creeps" the bandwidth on the link
192.168.2.3.  Later on, another reconfig happens.  Perhaps you can read the
file and try to interpret the events that are occurring; it would be a good
exercise.  See if things are changing as you expect they would; if not, ask
why. 

Local scheduler output
----------------------

In these files, you should at the least see reconfigurations occurring.  The
lines beginning with CONN are connections between LS nodes, used for
exchanging data, and the lines beginning with HTTP are those indicating a
reconfiguration message coming from the global scheduler (after an accept,
it prints out the XML of the configuration).  Every RECONFIG will show the
configuration in the appropriate ls*.out file, and you should see the CONN
connections go down and back up as a result.  There may be other diagnostic
messages too.

Trace output
------------

This shows the actual frames received at the video player.  This should be
self explanatory: it shows the sequence number of the frame, its size in
bytes, the time it was received, the bandwidth at the time, the kind of
frame (I, P, or B), the temporal reference, and finally whether the frame
could be decoded.

In this case, it looks like a bunch of frames were being dropped at the
end.  Not sure what's going on here; perhaps something isn't working right.
I also see that in local scheduler files, frames are;t able to be dropped
properly by priority.

GRAPHS

...