1

Shuo-Yen’s Research Log

Period: 2004/1 ~ 2004/6

Topic: Request Scheduling for Differentiated QoS at Website Gateway

2

Contents

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)

Bi-Quarterly Research Schedule Thesis Status

3

Bi-Quarterly Research Schedule

1/1 6/30

2/1 3/1 4/1 5/1 6/1

6/1Revised thesissent to the oral

exam committeemembers

5/15Complete draft

5/1Partial draft

1/26 - 3/31Implementation & Benchmarking

4/1 - 5/30Thesis writing

1/1 - 1/15Algorithm Design

1/9Present proposal

2/29Initial results

3/31Complete results

and detailed outline6/11

Oral exam

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

Traffic

0

20,000

40,000

60,000

80,000

100,000

120,000

64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072

File Size (Bytes)Th

rou

gh

pu

t (K

bp

s)

HTTP 1.1Incoming

HTTP 1.1Outgoing

HTTP 1.0Incoming

HTTP 1.0Outgoing

Max. Successful Transaction per Second

0

500

1,000

1,500

2,000

2,500

3,000

3,500

64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072

File Size (Bytes)

Rate

(Tr

an

sacti

on

s/S

ec.)

HTTP 1.1

HTTP 1.0

Take the figures as an example:1) Maximum transactions per second the server can sustain is around 3000 (bounded by

CPU);2) Maximum throughput the sever can pump is around 100 Kbps (bounded by NIC);3) 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

Writing

Revision# of

pages# of

wordsChing-Ming Advisors

Abstract 1 194

Chapter 1Introduction

3 769

Chapter 2Problem Statement

4 972

Chapter 3System Architecture of the QoS Website

Gateway7 1517

Chapter 4Implementation and Evaluation

8 928

Chapter 5Conclusion and Future Work

2 427

References2

(22 items)

460

TOTAL 27 5267

28

To be continued…