Scheduling task with heavy tail distributions Eddie Aronovich

Heavy tail dist.

Some properties… Infinitive variance (for infinitive mean) Infinitive variance (for infinitive mean) Tiny fraction (usually < 1%) requests comprise over half of total load ! Tiny fraction (usually < 1%) requests comprise over half of total load !

Some more properties Expectation paradox: E[X|X>k] ~ k (declining hazard rate) Expectation paradox: E[X|X>k] ~ k (declining hazard rate) Mass-count disparity (for n>2) Mass-count disparity (for n>2)

What is it good for ? Files size (in both – file systems & web) & data files transferred over the net Files size (in both – file systems & web) & data files transferred over the net I/O traces of fs, disk etc. I/O traces of fs, disk etc. Process time, Session time Process time, Session time Name servers & popularity of web sites Name servers & popularity of web sites

Why are they difficult to deal with ? M/G/1 queue length is proportional to second moment of service time. M/G/1 queue length is proportional to second moment of service time. Have no closed form Laplace transformation => systems must be numerically evaluated Have no closed form Laplace transformation => systems must be numerically evaluated

Some implementations… Scheduling web servers Scheduling web servers Routing & Switching Routing & Switching Load sensitive routing Load sensitive routing

How web server works ? Name resolution Name resolution Session establishments Session establishments Request Request Reply Reply End of session End of session The network is the bottleneck !

Some important knowledge Each computer is identified by address. Each computer is identified by address. Each application is a computer is identified by port number Each application is a computer is identified by port number Socket = {ip-addr, port number} Session = source socket : dest socket File descriptor – identifies socket / session

Default Linux model Socket1 {process} Socket2 {process} Socket3 {process} Socket4 {process} fairly feed single priority queue NIC

Shortest Remaining Processing Time (proposed model) Socket1 {process} {1 st prio. Que.} Socket2 {process} {2 nd prio. Que.} Socket3 {process} Socket4 {process} {3 rd prio. Que.} feed first feed third feed second NIC

Size cut-offs The following are rules-of-thumb: 50% of request <= X 1 50% of request <= X 1 1%-5% of requests > X n 1%-5% of requests > X n The middle cut are less important The middle cut are less important

Evaluated metrics Mean response time Mean response time Mean slowdown (normalized response time) Mean slowdown (normalized response time) Mean response time as a function of request size Mean response time as a function of request size

Some results….

Why does it work ? We know the file size (reply) a-priory We know the file size (reply) a-priory Short requests should wait short time Short requests should wait short time Linux is easy to be changed Linux is easy to be changed

What is next ? Distributed processing Distributed processing Task assigment Task assigment TAGS TAGS