|
|
|
|
|
|
Architecture
Below diagram shows one possible scheduler architecture.
Data structures will contain the dynamic information about the current allocation requests. Allocator - on receiving allocation request - will put up the allocation requests in Data structures. Deallocator will remove the allocation requests from Data structures - on receiving request for deallocation. Scheduler engine will check Data structures every Δt. It then - based on scheduling logic - will allocate the upcoming bucket from resource queue to appropriate user.
Fig 1.2
Data Structures
We will begin our analysis with Data Structures (being the central point). As there are classes of services (CR, VR, and HPVR), we can have three queues, one to each class. It is easy to see that these queues itself can be prioritised: HPVR - priority 1, CR - priority 2, VR - priority 3.
Fig 1.3
As you can see in above diagram, we have prioritised list of classes. Each class queue contain list of allocation requests. A allocation request would contain two parameters "Allocation Criterion" and "User ID". Before. Note that this allocation request is not same as that is given to allocator. Allocator logic converts original allocation request - which is made in terms of certain service parameters (just like QoS parameters) - into appropriate internal per bucket allocation request or requests. So the allocation requests maintained by data structures are more of internal (per bucket) allocation requests. This point would be more clear as we proceed.
|
|
|
|
|
|
|
|
|
|
|
