EECS 489 Lab 8: Weighted Fair Queueing
This assignment is due on Friday,
15 April 2016, 6 pm.
One of the main tool to provide resource isolation, either for
performance guarantee or infrastructure virtualization, is fair
queueing (FQ), otherwise known as generalized processing
sharing (GPS). In this lab, we implement a simplified weighted
fair queueing (WFQ) scheduler. The main simplification we make is to
assume that once a flow (or job) has started, the flow never goes
idle. If a flow can go idle, when it resumes service, we would need
to compute the scheduling round at which service is resumed. This
computation is complicated by the arrival and departure of other flows
during this flow's idle time. Everytime a flow arrives or departs, it
stretches or shrinks the duration of a scheduling round by changing
the total allocated resources. Hence to compute the round at which a
flow resumes service we would have to keep track of the changes in
scheduling round during its idle time. This is known as "round
catchup" in the literature. By assuming that a flow doesn't go idle,
we avoid doing "round catchup" in our implementation.
Another assumption we make is that once a packet starts transmission
we do not pre-empt it to serve another newly arriving packet with a
smaller finish time. This assumption implies that we account for
flow arrivals and departures only between packet transmissions.
We continue to build on our UDP-based client-server code. This code
base does not implement flow control, reliable delivery, nor rate
control. As usual, you're provided with a skeleton code and a
reference Linux binary executable of the server--called refwfqdb
The client is the same one used in Lab7. The implementation of WFQ
requires you to modify only the server code. The provided
Makefile builds netimg and wfqdb. You can
support code and copy the files to your
working folder for Lab7 (you may want to save a copy of your Lab7
Makefile, imgdb.h, and imgdb.cpp before
overwriting them with the ones for this lab). Access to the support
code is available only to students who have turned in PA3 or decided
not to do so. As usual, you can search for
the string "YOUR CODE HERE" in the code to find places where your code
must go. You may also want to consult the lecture notes on WFQ and PA4 walk-through. Your implementation of the server must
interoperate with the provided client.
Recall that the client's -r command-line option is used to
specify the flow's rate, in Kbps. The server in this lab takes three
optional command-line arguments -l, -g, and -f.
The -l argument allows you to specify the server's link rate,
in Mbps, ranging from 1 to 10. The -g argument allows you to
specify the minimum number of flows that must be initiated before
transmission starts. Transmission will not start unless either this
many number of flows have been initiated or if total reserved rate has
reached link capacity. We call this "gated start." Without gated start,
a flow could easily finish transmission before we could start a second one.
The -f option and its associated imgdb::frac member
variable are used in PA4 and will be described in the PA4 spec.
The default values of the command line options can be found in
Weighted Fair Queueing (WFQ)
Your first task is to complete the code in imgdb::handleqry() to
add a new flow. When a new flow is to be added, first look for an
empty slot in the flow table to hold the flow. Also check that
the link still have enough capacity to serve the flow's reserved rate.
If the new flow cannot be accommodated, send back to the client an
imsg_t packet with im_type set to
NETIMG_EFULL. Otherwise, increment the flow count and total
reserved rate of the scheduler and call Flow::init() to
initialize the flow. This task should take about 10 lines of code.
To send a packet, you first compute the finish time of each flow's
next segment. Complete the 1-line computation for next finish time in
Flow::nextFi() (Task 2). [To avoid unnecessary arithmetic,
we can assume that the finish times computed are multiplied by 128
(1024/8), i.e., the segment size can be in bytes instead of Kbits.]
Then determine, in imgdb::sendpkt(), the flow with the
smallest next finish time and call Flow::sendpkt() on the
flow to send the next packet (Task 3). This task should take about 10
lines of code.
Your last task (Task 4) is to call Flow::done() when the flow
has finished sending, as indicated by the return value of
Flow::sendpkt(). When a flow has finished sending, decrement
the scheduler's flow count and deduct the flow's reserved rate from
the scheduler's total reserved rate. This is a 2-line task for a
total of less than 25 lines of code for this whole lab.
Testing Your Code
Unfortunately you may not always be able to see the effect of the
scheduling order on the displayed images. You would have to rely on
the server's transmission log instead. The code for logging packet
transmission at the server is part of the support code provided to
you. Do not modify this code.
% wfqdb -g 2
which starts the server with the default link rate of 10 Mbps and
gated start set to 2 flows. Then run two instances of netimg
on two different shells/windows:
% netimg -s localhost:<port> -q ShipatSea.tga -r 256
(The display of the two instances of netimg may be on top of
each other; drag the top image display window aside to view the other
display window.) The two transmissions should complete about the same
time (a few hundred microseconds apart) with the BlueMarble flow
(flow 1) completing before the ShipatSea flow (flow
0). Observing the server's transmission log, you should see that
multiple BlueMarble flow's packets are sent for each ShipatSea
After quitting the two instances of netimg (you can leave the
imgdb running), start two new instances of netimg:
% netimg -s localhost:<port> -q BlueMarble2004-08.tga -m 8192 -r 1024
% netimg -s localhost:<port> -q ShipatSea.tga -r 128
You should see the BlueMarble flow completing much later (well, by a
millisecond or so) than the ShipatSea flow and that multiple ShipatSea
flow's packets are sent for each BlueMarble flow's.
% netimg -s localhost:<port> -q BlueMarble2004-08.tga -m 8192 -r 128
To incorporate publicly available code in your solution, or to pass
off the implementation of an algorithm as that of another are both
considered cheating in this course. If you can not implement a
required algorithm, you must inform the teaching staff when turning in
Your submission must compile and run without errors on CAEN
eecs489 hosts using the provided Makefile, unmodified, without any additional libraries or
Your "Lab8 files" comprises your imgdb.cpp.
To turn in your Lab8, upload a zipped
tarball of your Lab8 files to the CTools Drop Box. Keep your own backup copy! The timestamp on your
uploaded file is your time of submission. If this is past the
deadline, your submission will be considered late. You are allowed
multiple "submissions" without late-policy implications as
long as you respect the deadline. We highly recommend that you use a
private third party repository such as github
or M+Box or Dropbox or Google Drive to keep the back up copy of your
submission. Local timestamps can be easily altered and cannot be used
to establish your files' last modification times (-10 points). Be
careful to use only third-party repository that allows for
private access. To put your code in publicly accessible
third-party repository is an Honor Code
Turn in ONLY the files you have modified. Do
not turn in support code we provided that you haven't modified (-4 points).
Do not turn in any binary files (object, executable, dll,
library, or image files) with your assignment (-4 points). Your code
must not require other additional libraries or header files other
than the ones listed in the Makefile (-10 points).
Do remove all printf()'s or
cout's and cerr's and any other logging statements
you've added for debugging purposes. You should debug using a
debugger, not with printf()'s. If we can't understand the
output of your code, you will get zero point.