Final Report for Dismal Prospects
CS 4500, Spring 2008
24 April 2008
- Product-Related Information
- Current Status of Product
- Product is stable and ready for basic use: delay, bandwidth, link up/down.
- Current agent supports RED/GRED queueing. Our agent does not yet, but
was outside scope of project. Support can be easily added. Was not added
due to time constraints.
- Agent was never tested in a Linux delay node configuration. There are
other parts of the Emulab architecture that would need to be changed to
support a Linux delay node, and they were outside the scope of the project.
No change to the new agent should be required to support this configuration.
- Recommended Work
- Adding support for packet loss rate and RED/GRED queues needs to be
added before it can replace the current agent.
- Modification of Emulab to support a Linux delay node.
- Currently only FreeBSD 5.4 is supported (possibly later revisions as
well). Supporting older revisons should be possible, but will require
- Advice to Teams Continuing this Project
- Project Team Information
- Management Objectives and Priorities
- Our management objectives and
priorities have not changed from those expressed in the project plan. We used
the Emulab wiki, cvs repository, and defect tracking tools to manage our
project. We worked closely with the client to ensure that client needs were
met. We also made sure that the final result is usable as a replacement for
the existing Emulab delay agent.
- Final Team Structure
- Jon Duerig was responsible for the design and implementation of the
front-end. Ryan Jackson was responsible for the back-end implementation.
- Both of us reviewed each others' work to make sure there were no
obvious design or implementation problems.
- No changes to team structure would be necessary if starting the
- The team structure works as long as the interfaces between the modules
has been clearly defined. If interface changes become necessary, they
need to be noted and discussed.
- Both of us fulfilled our roles and participated in the project. We
each had other responsibilities (family, work, class, or personal) that
sometimes made communication and collaboration difficult due to scheduling
- Schedule and Planning
- We had no problem sticking to our weekly meeting with each other and
- Code reviews were not as formal or regular as specified in the
- We used the Emulab wiki to help us track our progress and document
project goals. Our weekly management reports were a very helpful
tool for this purpose.
- We could have been more formal with our scheduling. We tended to
be pretty lax with internal (not class) deadlines due to outside
scheduling constraints. Sticking to our schedule would have made
things less stressful and helped us meet both internal and class
- Support Functions
- Our Quality Assurance functions were handled by both of us, mainly
through testing of each component as well as performing regular
system tests at each milestone.
- We used the Emulab wiki for defect tracking, although it was not
extremely formalized. Due to the lack of formal defect tracking,
most issues were not known to the other team members. Using the
Emulab bug tracking system would have helped us keep track of
each others' issues.
- Working With the Client
- We had a good relationship with the client. Discussing project
progress during our weekly meetings always went well. The client
was always consulted when making major design or implementation
changes. The client also provided us wil all the information on
the Emulab architecture that we needed during the course of the
- We could have improved the relationship with the client if we had
better scheduling practices. Sometimes meetings with the client
had to be cut short for various reasons. Working more closely with
the client's schedule would have helped.
- Work With Project Mentors
- Working with a mentor was good. It helped us to understand where
our design or implementation may have problems or may not meet
the client's needs.
- Make sure to discuss major design and implementation ideas with
your project mentor. It helps to eliminate bad or faulty ideas
early on instead of later during implementation.
- Other Issues
- Feedback From the Mentors
- We fulfilled the requirements for the project, but more features will need to be added before our implementation is ready to replace the existing implementation.
- We spent too much time exploring the problem space and working out the abstract design before starting on the actual code.
- We should have spent more time refining the requirements so that we didn't spend time designing for non-existant needs, such as having the front-end and back-end be separate processes.
- Three General Pieces of Advice
- If at all possible, try to have more than two people in your group. We
were both busy with other things this semester, causing problems in
scheduling and communication.
- Make sure to have code and design reviews. This will help to reduce
design flaws and bugs.
- If you use test-driven development, make sure you have good tests and
that you can easily automate them. Use the tests on each component
and during development to help eliminate lurking bugs later on.