[ee122] bug fix for solution to Homework #2 problem 3(d)

vern at cs.berkeley.edu vern at cs.berkeley.edu
Thu Oct 11 08:59:33 PDT 2007


The original solutions had an error, which has now been fixed.  I've
appended diffs, and updated the PDF at the same URL as before.

My thanks to Rick Schmidt for spotting this, and apologies for not getting
it correct originally.

		Vern


Index: hw2_soln.tex
===================================================================
--- hw2_soln.tex	(revision 113)
+++ hw2_soln.tex	(working copy)
@@ -17,7 +17,11 @@
 
 \begin{centering}
 \begin{Large}
-Solutions for Homework \#2\\[0.2in]
+Solutions for Homework \#2\footnote{
+Version 2, Oct 11 2007: Fixes an incorrect solution for Problem 3(d).
+Our apologies, and kudos to Rick Schmidt for spotting the error.
+}
+\\[0.2in]
 \end{Large}
 
 \begin{large}
@@ -275,23 +279,38 @@
 	For a 122,000~byte file, this results in 3~full window's worth of
 	packets, followed by 6~more packets (the last of which is a partial
 	packet, again of size 820~bytes).
-	We employ the method used above to calculate the total transfer time
+
+	We might employ the method used above to calculate the total transfer time
 	and corresponding throughput. The 84$^{\mbox{th}}$ packet belongs
-	to the sequence \#6, \#32, \#58, \#84.  As established above, each
-	full-sized packet has a transmission time of 1~msec, so we will begin
-	transmission of packet \#6 at time 5~msec.
+	to the sequence \#6, \#32, \#58, \#84.  However, a subtlety arises,
+	as follows.  When the ACK for packet \#1 arrives, it allows us to
+	send packet \#27 (since the window is 26~packets in size).  Note that
+	this occurs \emph{while we are still in the process of transmitting
+	packet \#26}, because 26~packets represent a bit \emph{more} data
+	than required to keep the forward path continuously busy.
 
-	Packet \#84 will be sent 3 RTTs later:
-	$$
-		T_{84} = T_{6} + 3 \cdot~\mbox{RTT} = 5 + 3 \cdot 25.027 = 80.08~\mbox{ms}
-	$$
+	We can see this effect by considering that we start sending
+	packet \#26 at a time 25~msec after we began sending packet \#1
+	(since each packet has a transmission time of 1~msec).  We will
+	finish transmitting packet \#26 at time 26~msec.  However, the
+	RTT for this path is 25.027~msec.  Thus, the ACK arrives shortly
+	after we have \emph{begun} sending packet \#26, and before we
+	have finished doing so.
+
+	This means that we send packet \#27 directly after we finish sending
+	packet \#26, so at time 26~msec, rather than at time we would
+	calculate based on the RTT.
+
+	Therefore, a window of 26~packets means that every packet goes
+	out 1~msec after its predecessor.  In particular, we start sending
+	packet \#84 at time 83~msec.
 	The time required to transmit \#84 and receive its ACK added to the send
 	time of \#84 gives us the total transmission time:
 	$$
-		T_{84} + T_{\mbox{partial}} + T_{\mbox{ack}} = 104.681\mbox{ms}
+		T_{84} + T_{\mbox{partial}} + T_{\mbox{ack}} = 83 + 24.6 = 107.6\mbox{ms}
 	$$
-	Throughput is therefore $122000\mbox{B} / 104.681~\mbox{ms} =
-	1.165445~\mbox{MBps} = 9.32356~\mbox{Mbps}$.  It's not the full
+	Throughput is therefore $122000\mbox{B} / 107.6~\mbox{ms} =
+	1.133829~\mbox{MBps} = 9.070632~\mbox{Mbps}$.  It's not the full
 	12~Mbps because we spend about half an RTT waiting for the first
 	data packet to arrive at the receiver, and another half an RTT
 	waiting for the final ack to arrive back at the sender.


More information about the ee122 mailing list