stability or stabilizability? seidman’s fcfs example revisited
DESCRIPTION
Stability or Stabilizability? Seidman’s FCFS example revisited. José A.A. Moreira Agilent Technologies Germany. Carlos F.G. Bispo Instituto de Sistemas e Robótica Portugal. Outline. Motivation Proposed Solution Active Idleness Time Window Controller Simulation Results Conclusions. - PowerPoint PPT PresentationTRANSCRIPT
Stability or Stabilizability?Seidman’s FCFS example revisited
José A.A. MoreiraAgilent Technologies
Germany
Carlos F.G. BispoInstituto de Sistemas e Robótica
Portugal
MED2002 - Lisbon, Portugal 2
Outline
• Motivation
• Proposed Solution– Active Idleness
– Time Window Controller
• Simulation Results
• Conclusions
MED2002 - Lisbon, Portugal 3
Motivation – The system
• Multi-class, Non-Acyclic Queuing network– Random service times
– Random external inter-arrival times
– Diferent types of customers• Each type has a deterministic routing
• Same type may visit a server more than once
• Each service a different class
• Each class a different service distribution– Not a Jackson network
MED2002 - Lisbon, Portugal 4
Motivation – The control policies
• Open networks– No adimission policy
– Scheduling policy
• Scheduling policy– Distributed: buffer priority; ESPT; FCFS; etc.
– Non-idling or work conserving
– No preemption
MED2002 - Lisbon, Portugal 5
Motivation – The stability condition
• Assume all classes are uniquely numbered– k = 1, 2, ..., K– Let k be the first moment of the service for class k
• Each server operates over a subset of all classes• Each class has an associated type of customer for
wich an external arrival rate is defined– Let k be the first moment for the arrival rate of class k
• Then the traffic intensity condition is k c(i) k k < 1, for all i = 1, 2, ..., S
MED2002 - Lisbon, Portugal 6
Motivation – The problem
• Is the traffic intensity condition sufficient or simply a necessary condition for stability?– It is sufficient for Jackson networks
• Service distribution associated with the server, not the customer
• FCFS as the scheduling policy– It seems sufficient for acyclic networks– But, some examples of unstable non-acyclic networks
• Lu-Kumar example (’91); Seidman’s example (’94); Dai’s example (’95)
MED2002 - Lisbon, Portugal 7
Motivation – Seidman’s example I
• FCFS as the scheduling policy
• Originally presented with deterministic processing times and inter-arrival intervals
MED2002 - Lisbon, Portugal 8
Motivation – Seidman’s example II
• Our simulation results in a stochastic setting
Server #1Server #2Server #3Server #4Sum of customers at each server
X-axis goes up to 40,000 periods
Y-axis goes up to 20,000 customers
MED2002 - Lisbon, Portugal 9
Motivation – Consequences
• After these examples, the answer seems to be– The traffic intensity condition is NOT a sufficient
stability condition for general queuing networks.
• However,– Most authors focused on non-idling policies– From the static and deterministic scheduling theory we
know that their equivalent to non-idling policies may not contain the optimal solution
– Clear-a-Fraction policies with Backoff resorts to idling policies to establish stability (Kumar & Seidman, ‘90)
MED2002 - Lisbon, Portugal 10
Proposed solution – Active Idleness I
• Why determine if a network is stable under all non-idling policies?
• Or, why determine regions for which some topologies are stable for all non-idling policies?
• Why not asking if a network is stabilizable?– That is, can a given policy be changed to make the
network stable?
– Is this property intrinsic to the pair network/policy or just a property of the network?
MED2002 - Lisbon, Portugal 11
Proposed solution – Active Idleness II
• By using non-idling policies we are forcing idleness due to lack of customers– Burstiness in the arrival and services times is allowed
to freely spread trough the network
• Actively resort to idleness– That is, allow a server to stay idle in the presence of
customers
– Take the server’s past history to provide a measure of global state of the network
MED2002 - Lisbon, Portugal 12
Proposed solution – TW Controller I
• The Time Window Controller is an implementation of the Active Idleness concept– Define a finite size window of time looking into the past history of each
class
• Tk [0, [– Define a maximum fraction of time each server operates over each class
during that window
• fkmax [0, 1]
– Compute the fraction actually used through exponential smoothing
• fktwithk [0, 1]– Use original policy only on classes not exceeding their fraction
MED2002 - Lisbon, Portugal 13
Proposed solution – TW Controller II
• Classes exceeding their maximum fraction are blocked– If all costumers waiting belong to blocked classes, the
server will remain idle
– Idleness is kept until a new customer from a non blocked class arrives or until one of the blocked classes present drops below its maximum time fraction
• Controller filters burstiness on individual classes• The filtering procedure is local
MED2002 - Lisbon, Portugal 14
Proposed solution – TW Controller III
• What is good for an individual server is not necessarily good for the network– Idleness is bad for a single server when customers are
present– Local scheduling policies are based on what is good for
a single server• Getting rid of waiting customers
– Active Idleness hurts single servers to preserve the network
• Past history of a single server is a measure of load to remaining servers
MED2002 - Lisbon, Portugal 15
Simulation results – Seidman’s example
• Choice of parameters for the Controller– All fractions add up to 1 at each server
– Each fraction is sligthly above the long term needs
MED2002 - Lisbon, Portugal 16
Simulation results – Buffer trajectories
• Red line – the original trajectories
• Blue line – the modified trajectories
Server #1Server #2Server #3Server #4Sum of customers at each server
X-axis goes up to 40,000 periods
Y-axis goes up to
1,000 customers
MED2002 - Lisbon, Portugal 17
Simulation results – Active Idleness
• There is no Active Idleness on the original system, but Passive Idleness accounts for a huge capacity waste
• The modified system has a significant reduction of Passive Idleness at the expense of a very small amount of Active Idleness
MED2002 - Lisbon, Portugal 18
Conclusions I
• Consequences– The traffic intensity condition is sufficient to ensure stabilizability,
if processing times have upper bounds and original policy is non-idling
– Stabilizability is intrinsic to the network’s topology
– Optimal controller is stable
• Limitations– We can construct a provably stabilizing controller if all services
have an upper bound
• Leaves out Markovian systems, but not critical for real life systems
MED2002 - Lisbon, Portugal 19
Conclusions II
• Features– The maximum time fractions can add up to more than
one– Performance gains even when the original is already
stable
• Future– Characterize the performance measures as functions of
the parameters – convex?; unimodal?; etc.– Design an optimization package to tune the TW
Controller
Stability or Stabilizability?Seidman’s FCFS example revisited
José A.A. [email protected]
Carlos F.G. [email protected]
http://www.isr.ist.utl.pt
MED2002 - Lisbon, Portugal 21
Dai’s example
Acrobat DocumentDai’s network Acrobat DocumentPerformance
Acrobat DocumentIdlenessAcrobat DocumentParameters