1 / 28

Shuo-Yen ’ s Research Log

Shuo-Yen ’ s Research Log. Period: 2004/1 ~ 2004/6 Topic: Request Scheduling for Differentiated QoS at Website Gateway. Weekly Report 1/5 ~ 1/11 1/12 ~ 1/18 2/2 ~ 2/8 2/9 ~ 2/15 2/16 ~ 2/22 2/23 ~ 2/29 3/1 ~ 3/7 3/8 ~ 3/14 3/15 ~ 3/21 3/22 ~ 3/28. 3/29 ~ 4/4 4/5 ~ 4/11 4/12 ~ 4/18

sevita
Download Presentation

Shuo-Yen ’ s Research Log

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Shuo-Yen’s Research Log Period: 2004/1 ~ 2004/6 Topic: Request Scheduling for Differentiated QoS at Website Gateway

  2. Weekly Report 1/5 ~ 1/11 1/12 ~ 1/18 2/2 ~ 2/8 2/9 ~ 2/15 2/16 ~ 2/22 2/23 ~ 2/29 3/1 ~ 3/7 3/8 ~ 3/14 3/15 ~ 3/21 3/22 ~ 3/28 3/29 ~ 4/4 4/5 ~ 4/11 4/12 ~ 4/18 4/19 ~ 4/25 4/26 ~ 5/2 5/3 ~ 5/9 5/10 ~ 5/16 5/17 ~ 5/23 5/24 ~ 5/30 5/31 ~ 6/6(Active) Contents • Bi-Quarterly Research Schedule • Thesis Status

  3. Bi-Quarterly Research Schedule

  4. Weekly Report (1/5 ~ 1/11) • Last week • Design algorithm: server capacity issues • Handle lab account: Half-year settlement • Status: Almost done. (Except some people whose account was deposited from III.) • This week • Pseudo code of scheduling and probing algorithm • Present current research work at group meeting • Notes (click mouse please)

  5. Weekly Report (1/5 ~ 1/11) <Notes> Regarding server capacity issues, we have great improvement through the discussion with Ching-Ming last week. We found the influences on server capacity are twofold: CPU and HD (or NIC). The server is CPU-intensive when the response size is small since the CPU is busy at processing requests. On the other hand, the server is HD- (or NIC-) intensive when the response size is large. At that moment, CPU is not the bottleneck but the HD (or NIC) is. Above findings are according to a test report of AdvanTech e-Server from NBL. Under such hypotheses, the release controller can be designed in accordance with these two factors: 1) maximum transactions per second a server can sustain and 2) maximum throughput a sever can pump. They can be obtained by our probing algorithm described below. Besides, the gateway always records current numbers of transactions and throughput. When the response size of a coming request is small, the admission is made according to current number of transactions of the server. Similarly, when the response size of a coming request is large, the admission is made according to current throughput of the server. How can we judge the response size is “small” or “large”? Fortunately, there is a threshold of response size between these two conditions according to the test report. Hence, the probing algorithm has to probe not only the maximum transactions and maximum throughput but the threshold of response size. At first, the gateway sends as many requests of the same response size as it can. Record maximum transactions per second the server can sustain and maximum throughput the sever can pump. Then do the same procedure repeatedly under different response size. Results would be similar to those figures listed next page. Then we can get the numbers we want.

  6. Weekly Report (1/5 ~ 1/11) – Appendix • Take the figures as an example: • Maximum transactions per second the server can sustain is around 3000 (bounded by CPU); • Maximum throughput the sever can pump is around 100 Kbps (bounded by NIC); • Threshold of response size between these two conditions is around 4096 bytes.

  7. Weekly Report (1/12 ~ 1/18) • Last week • Finish grade MCN homework ch.4 & ch.5 • Invigilate MCN final exam • Grade MCN final exam • Present thesis work at group meeting • This week • Finish grade MCN final exam • Consider the issue of utilizing server capacity

  8. Weekly Report (2/2 ~ 2/8) • This week • Setup development testbed on NetBSD. • Install and dig “webfd”. • Goal: Understand the code structure of “webfd”. The next step is to integrate our algorithm into it.

  9. Weekly Report (2/9 ~ 2/15) • Last week • Setup development testbed on NetBSD. • Install and dig “webfd”. • Goal: Understand the code structure of “webfd”. The next step is to integrate our algorithm into it. • This week • Implement classifier into “webfd” to classify packets to different queues according to their source IP addresses.

  10. Weekly Report (2/16 ~ 2/22) • Last week • Trace different versions of webfd. • webfd-i2: a newer version of webfd-i revised by Chun-Ying, also is the version I have to revise. • webfd-i-YiHsiang: another version of webfd-i revised by Yi-Hsiang (to support Web QoS at edge device). • This week • Continue classifier implement • Note • Last week I spent most of time tracing the code of webfd. The purpose of tracing Yi-Hsiang’s code is to refer to his way to implement the algorithm into webfd. This week I will speed up the progress of my implementation.

  11. Weekly Report (2/23 ~ 2/29) • Last week • Continue classifier implement • This week • DRR scheduler implement • Note (click mouse please)

  12. Weekly Report (2/23 ~ 2/29) <Notes> Before implementing scheduler into webfd, we found some significant issues. To make DRR run correctly, each request must be processed for some time before sending out. Thus, we changed the way to determine whether a request can be sent out. The original algorithm uses a token bucket to reflect the CPU/IO capacity of the Web server. But we left the token rate out of consideration. Therefore, whenever a request is coming, it will be sent out immediately if there is enough tokens. For this reason, Shih-Chiang suggested that we can manipulate the processing time of Web server at the gateway. The following below describes how the processing time can be calculated. Recalled that by way of probing mechanism, we can get two important data of server capacity. One is the maximum processing rate (assume Mr requests/sec), the other is the maximum throughput (assume Mb bytes/sec). Besides, assume the response size of the coming request Rn is S bytes. Then the estimative processing time of this request is: NextSendTn = 1/Mr + S/Mb Here we call the result as “next sending time” represents the request Rn will be sent out immediately, but the next request Rn+1 will be sent out after NextSendTn seconds. We use such way to make the scheduler run correctly.

  13. Weekly Report (3/1 ~ 3/7) • Last week • Scheduler implementation • Decide what figures should be put into the thesis to show our evaluation results • This week • Continue scheduler implementation • Construct testing environment • A low-end Web server • Many IPCs with WebBench installed • Start benchmark and get initial results • Prepare presentation of numerical results

  14. Weekly Report (3/8 ~ 3/14) • Last week • Continue scheduler implementation • Construct testing environment • A low-end Web server • Many IPCs with WebBench installed • Prepare presentation of numerical results • This week • Start benchmark and get initial results • Prepare detailed outline • Notes • The implementation work had great progress last week. Our request scheduling algorithm has been integrated with webfd. This week I will do some benchmark to see if the results could conform with our expectation.

  15. Weekly Report (3/15 ~ 3/21) • Last week • Implement function for tuning server capacity. • Start benchmark and get initial results. • Prepare outline. • This week • Write chapter 1: Introduction • Accuracy benchmark. • Notes • Last week I have finished the scheduler implementation. In addition, the server capacity can be tuned to make the scheduler operates properly. The next step is to evaluate the accuracy of the algorithm. In the meanwhile, I have to finish chapter 1 writing in this week.

  16. Weekly Report (3/22 ~ 3/28) • Last week • Write chapter 1: Introduction • External benchmark (enable WebQ) • This week • External benchmark (disable WebQ) • Internal benchmark (time decomposition) • Write chapter 2: Problem Statement

  17. Weekly Report (3/29 ~ 4/4) • Last week • Try Avalanche. (It is not suitable for our benchmark, because it cannot gather results from individual clients.) • External benchmark – all items • This week • Finish writing chapter 2: Problem Statement • Re-test some imperfect results

  18. Weekly Report (4/5 ~ 4/11) • Last week • Finish writing chapter 2: Problem Statement • Re-test some imperfect results • This week • Write chapter 3: System Architecture and Scheduling Algorithm of QoS Website Gateway

  19. Weekly Report (4/12 ~ 4/18) • Last week • Finish writing chapter 3: System Architecture and Scheduling Algorithm of QoS Website Gateway • This week • Write chapter 4: Implementation and Evaluation • Extra benchmark • “aggregate throughput” under different # of concurrent connections between GW and server • “server idle period : busy period” under different # of concurrent connections between GW and server • time compositions inside the program

  20. Weekly Report (4/19 ~ 4/25) • Last week • Re-test ALL items • New results correct the error of throughput collapse when page size is too large • Extra benchmark • “aggregate throughput” under different # of concurrent connections between GW and server • Results show that the throughput is almost the same under different # of concurrent connections between GW and server • This week • Modify chapter 3 according to Ching-Ming’s suggestions • Write chapter 4: Implementation and Evaluation • Extra benchmark • “server idle period : busy period” under different # of concurrent connections between GW and server • time compositions inside the program • Prepare midterm of Statistics (Thur.)

  21. Weekly Report (4/26 ~ 5/2) • Last week • Modify chapter 3 according to Ching-Ming’s suggestion • Write chapter 4: Implementation and Evaluation • Refine presentation slides • Prepare and take midterm of Statistics • Handle lab account up to Q1 and Q2 • This week • Finish writing chapter 4 : Implementation and Evaluation • Write chapter 5: Conclusion and Future Work • Finish all external and internal benchmark items

  22. Weekly Report (5/3 ~ 5/9) • Last week • Finish writing chapter 4 : Implementation and Evaluation • Write chapter 5: Conclusion and Future Work • This week • Finish writing chapter 5: Conclusion and Future Work • Finish internal benchmark

  23. Weekly Report (5/10 ~ 5/16) • Last week • Revise the solution to the server-probing issue • Polish the slides • Present to ITRI-CCL • This week • Revise thesis writing ch1 ~ ch4 • Test time composition of processing a request at the server • Timestamp on: • t1: First packet of 1st receiving request • t2: Last packet of 1st sending response • t3: First packet of 2nd receiving request • We want to know: (idle time) / (processing time) • idle time: t3 – t2 • processing time = t2 – t1 • Finish writing chapter 5: Conclusion and Future Work

  24. Weekly Report (5/17 ~ 5/23) • Last week • Revise thesis writing ch1 ~ ch4 • Finish writing chapter 5: Conclusion and Future Work • Test time composition of processing a request at the server • Timestamp on: • t1: First packet of 1st receiving request • t2: Last packet of 1st sending response • t3: First packet of 2nd receiving request • Results: • idle time = t3 – t2 < 0, which means the server was not idle for waiting the next request • Web service meeting at ITRI-CCL • This week • Write abstract and order the references • Re-organize the whole thesis according to the formal format

  25. Weekly Report (5/24 ~ 5/30) • Last week • Write abstract and order the references • Re-organize the whole thesis according to the formal format • Revise chapter 4 and chapter 5 according to Ching-Ming’s suggestions • This week • Revise the whole thesis according to Dr. Lai’s suggestions • Web service meeting at ITRI-CCL (Fri.)

  26. Weekly Report (5/31 ~ 6/6) • Last week • Revise the whole thesis according to Dr. Lai’s suggestions • Web service meeting at ITRI-CCL (Fri.) • This week • Thesis proofreading • Revise the slides

  27. Thesis Status

  28. To be continued…

More Related