Solutions for Homework 1 Gabriela Barrantes ========================================================================== 1.1 If n es the number of bits per character (smoe of you used my suggestion of 7 bits, and some used the regular 8 bits), then the typist is generating (400 chars/minute)(n bits/char)(1/60 min/sec) =~ 6.67 n bits/sec = 53.33 bits/sec using 8 bits and = 46.66 bits/sec using 7 bits The efficiency is simply the comparison of the typing rate (if you assume that characters are sent as soon as typed) with the total transmission rate: (using 7 bits) ( 46.7 bits/sec ) / (9.6 x 10^3 bits/sec) =~ 0.0048 Which means that you are using less than 0.5 % of the channel capacity. If you used 8 bits, the same calculation would have given you 0.0055, which is slightly more than the 0.5% that was stated in the question. Anyway is a very small percentage, and showing the bandwidth waste was all the point of the exercise. -------------------------------------------------------------------------- 1.2 Again, ignoring the 1 to 5 rate reference (nobody sent me any useful suggestions about the interpretation of THAT statement), and comparing rate to rate, just as in the previous exercis, we find out that the maximum number of simultaneous users we can squeeze inthe 9.6 Kbps is Using 7 bits: ( (9600 bits/sec)/channel) / ( (46.7 bits/sec)/user ) =~ 205 users/channel Using 8 bits: =~ 180 users/channel ----------------------------------------------------------------------------- Addendum to 1.2 Packet headers can introduce very high overheads. Remember that the only USEFUL work you are doing is sending the data. All the rest is just bureaucracy. So, if each packet introduces a 10% header overhead , even if the channel is completely filled up with packets, 10% of the capacity will be irremisibly lost. So, instead of having 9.6 Kbps (that's the raw rate), what you have really available for data transmissions is a 8.64 Kbps rate. So, using the same calculations of the main problem, we will get 185 users with 7 bits characters, and 162 users with 8 bits characters. Only to get a feeling of how important is not to forget this overhead, consider that an ATM packet is 53 bytes long, of which the header occupies 5 bytes. That is nearly a 10% header overhead (not counting the header overhead of other protocols that are encapsulated into the 48 bytes left). --------------------------------------------------------------------------- 1.3 This problem could have been stated in several ways. (a) The first decision was to interpret the position of the 16 bits: Let n be the number of packets to send If the 16 bits are additional to the P bits/packet, then n = ceiling ( (B /P) ) If the 16 bits are part of the P bits/packet then n = ceiling ( (B / (P-16)) ) In any case, it has to be ceiling because you actually send only a positive integer number of packets. (You can't send 34.7 packets: you will send 35) (b) The second decision was to interpret what to do with the last packet Let d be the total number of bits that would be transmitted IF packets have fixed size (the last packet will be padded to length P or P-16) Then: d = n * P if the 16 bits are part of P d = n * (P+16) if not If packets have variable size Then: d = B + (16 * n) Between each pair of packets there is a 10 * 10^(-3) sec gap, and there would be n - 1 gaps. Finally, the total transmission time is [(d / 10000)] + [( 10 ^ (-2) ) * (n - 1)] packet transmission interpacket gap total time ---------------------------------------------------------------------- 1.5 First of all, notice that the first question refers to the VERY SPECIFIC pair of trees shown in figure 1.17. It is not a general case question, so it should be solved for THIS case. Let's see: General case: Average length = E[length of encoding] = sum [ (lenght of encoding for letter) * P(letter) ] (all letters in specific alphabet) This is simply from the standard definition of average for discrete sets. For this case: Fixed encoding Average lenght = 3* P(a) + 3 * P(b) + ... + 3 * P(h) = 3 * sum [P(a) + ... + P(h)] = 3 * 1 = 3 bits/letter (Well, this is kind of redundant, because we already knew that the length was fixed, so the average had to be that fixed lenght) Variable encoding Average length = 3 * (5/14) + 4 * (2/14) + 2 * (1/2) = 37/14 =~ 2.64 bits/letter So, we have shown that the variable lenght encoding is smaller IN THIS CASE than the fixed lenght encoding. Now, for the second part of the exercise use that: (a) If there are N letters, all equally likely (P(x) == P(y) for all x,y in the alphabet), then the probability of using any one of them is (obviously) 1/N (b) The minimal lenght encoding is H = - sum (p(k) * log 2 p(k)) k From (a) and (b), H = - sum (1/N) log 2 (1/N) k=1 to N = -(N/N)log 2 (1/N) = log 2 N done! ---------------------------------------------------------------------------- 1.6 First question: Is the scheme feasible? Answer: Why not? Seriuosly: you have all bought/downloaded for free music in exactly the same format. Of course is feasible. However, you have to consider that the USER has to have enough bandwidth at his last-mile link, or he/she will find it extremely costly to download from your (or any other) site. This is why most sites offer the product for download, but ALSO offer the possibility of sending the CD. Another consideration is the bandwidht for accesing YOUR site. Have you ever entered one of those very popular, but small enterprise, sites? The access becomes a nightmare, and they start loosing customers because it is almost impossible to reach them. In this specific case, you need to provide enough bandwidth not only for access, but also for browsing (maybe playing small music clips) and downloading. Second question: Communication bandwidht? Again, we are not facing a probabilistic problem here. Evidently, if we were to model it correctly, we will have to take queuing into account, but we'll dispense with that for the time being. What we want to figure out, is that how much bandwidht PER USER will we need so it won't take him more than 10 minutes to download a CD. That is easy to calculate: First: 700 MB = 700 * 8 * 10^6 bits = 5600 Mbits Second: 10 min = 10 * 60 sec = 600 sec Finally: 5600 Mbits / R (bits/sec) < 600 sec => 5600 * 10^6 / 600 < R => R > 9.33 Mbps So, we need AT LEAST 9.33 Mbps PER USER. Third question: Is this idea profittable? In a 45 Mbps link, you can sell 45/9.33 = ~ 4 CDs each 10 minutes, or 24 CDs per hour (assuming full link occupancy). Given that the link costs $20000 and each CD sells by $20, the store needs to sell 1000 CDs a month to break even. This represents around 14 CDs per hour, which is below maximum link occupancy, but is close to 60% of the link capacity. If the store is capable of selling 1000 or more CDs per month, the scheme is feasible and (marginally) profittable. In fact, the extra capacity will allow users to browse the store, and access it easily, which will be good for the store's name. I am assuming 24 hour days, however, which is not realistic. Fourth question: Other business opportunities? With the actual boom of ecommerce, you should have had no problem coming with more examples: software downloads, digital libraries, video stores, etc. ---------------------------------------------------------------------------- 1.7 The first part was a research question, so I will grade the accuracy of your (very samll) research. The second part, has to do with remote access, and each of you could have answered according to your specific case. Some of you are not paying, but using UNM's free (bandwidth and modem restricted) access, some of you connect through Technet and some use any other ISP, so the answer can vary widely. ---------------------------------------------------------------------------- 7. Some precalculations: 7 GB = 7 * 8 * 10^9 bits = 56 Gbits 3 tapes = 3 * 56 Gbits = 168 Gbits 18 Km/h = 18 km / 60*60 sec = 0.005 Km/sec Velocity = Distance/Time => Time = Distance / Velocity Data rate = 168 Gbits/ Time sec So, we want to find a distance d, such that ( 168 * 10 ^ 9 bits) / [ (d Km)/ (0.005 Km/sec)] > 155 * 10^6 bits/sec Solving... (168 * 10 ^ 9 * 0.005 / d ) bits/sec > 155 * 10^ 6 (bits/sec) (168 * 10 ^ 9 * 0.005 / 155 * 10^ 60 > d d < 5.41 Km So, the answer is that for distances smaller than 5.41 Km it is better to go biking with the tapes. Main disadvantage? It was a one-way transmission, the tapes could toast in the sun, may be lost, etc. Also, a 155 Mbps line delivers its rate constantly: How many people on bikes do we have? And what about the delay?