The web interface: through which users are authenticated and interacted with the broader system functionality, including selecting the rigs to which they wish to gain access.
The scheduling server: is the middleware that manages the scheduling processes of the RL rigs, including tracking the state of rigs and assigning them to users. It is responsible for managing the running sessions according to the allocated times as well as logging all events and activities.
The rig client: This component provides a software abstraction of each rig and converts abstract requests from the scheduling server into rig specific actions.
3.3.1 Reservation (Calendar Booking) This form of access request allows users to make a reservation that provides guaranteed access to a rig (or one of a pool of rigs) at a specified time. The resource allocations occur as follows:
1. A user attempts to log into the Sahara server, is authenticated, and is then provided with a list of the rigs (and pools of rigs) for which they have authorization.
2. The user selects a particular rig (or pool of rigs) and then is presented with the current status of the rig and the option to either make a reservation or to queue for access (see Fig. 3).
3. If the user selects “reserve,” then the reservation page appears with the available time slots (see Fig. 4).
If the user selected an individual rig, then the periods shown as unavailable will be those where the specified rig is explicitly reserved, is marked as being offline during that time, or because the pool to which it belongs has the same number of reservations as there are available rigs. In some cases, this rig may be shown as available, but may be tentatively allocated to a user who made a reservation for any rig within the rig pool. In this case, the system is able to attempt to move that previous reservation to a different rig from the pool before confirming the reservation. If this fails, the system will attempt to the next best reservation time the user can create.
If the user selected a rig pool then the periods shown as unavailable will only be those where the number of reservations is the same as the number of available rigs.
Once the user selects a period for a reservation, if the period is longer than the maximum allowed for this class of user then the time is reduced to the maximum.
4. Once a time slot is selected, the reservation is created, a confirmation message appears, and an e-mail message is sent to the user with the reservation details. The rig reservation page will show the reserved time slots (colored in gray) for all future accesses. The system can be configured to limit the number of active reservations that can be made by a user, and to block the user from making more than one concurrent reservation across multiple rig types.
5. When a user is logged in, and they have a pending reservation (within a configurable amount of time) their primary screen changes to provide them with a countdown to the start of their session. As soon as their reservation time arrives, the user is allocated to the rig, the rig page appears, and the experiment session commences.
3.3.2 Priority Queuing Queuing supports “on demand” requests from users, providing “soonest available” access to a selected rig (or collection of rigs). The basic logic for the queuing process is the same for the first two steps of a reservation-based access, and then proceeds as follows:
1. The user selects the “queue” option (see Fig. 3). The request is placed in the queue, with associated information indicating which rig (or collection of rigs) they have requested access to, the default usage time specified for their user class, and any other relevant parameters. The user is provided with information as to their current position within the queue (see Fig. 6).
2. When any rig becomes available, Sahara scans through the queue looking for the first request from among those that are the highest priority, and which satisfies the following criteria:
a. The request is either for the available rig, or for a pool which contains the available rig; and
b. The request can be completed prior to the next reservation for this resource (i.e., the next reserved session for this resource is no sooner than the current time plus the default usage time for this user on this rig);
Note that this allocation strategy ensures that a rig will only be allocated to a user in the queue when it can be guaranteed that they will have the full amount of time to which they are entitled, if they choose to use it.
3. Once a user is allocated to a rig, the rig page will appear and the experiment session will be started, including a timer counting the session time defined by the system.
In both types of scheduling, once a rig has been allocated, the rig session will be immediately commenced. If the user is currently logged in, then they will be redirected to the relevant rig access page. If they are not logged in, and they remain not logged in for a configurable amount of time (typically 10 minutes), then the session times out and the rig is returned to the available pool. The session is also considered to have ended when the user explicitly terminates their session or is inactive for a configurable amount of time, or the allowed session time is completed and no further extensions are allowed (a session can usually be extended a finite number of times if there is no queued user who wishes to use the rig or no pending booking for that rig).
The above descriptions imply a number of dependencies between the queuing and booking algorithms. For example, consider the case of a user in a queue waiting for access to a specific rig. The user cannot be allocated to the rig even if it is currently available unless their session (at maximum length allowed) is guaranteed to be complete before any pending booking comes due. This interdependence can therefore, potentially, lead to time periods where a rig is idle even though it is currently the subject of usage demands. An analysis of how serious an issue this is will be presented in Section 4.
- Total number of requests = 1,415
- Reservation-based requests = 353
- Queue-based requests = 1,062
- Total number of successful allocations = 700
- Reservation-based rig allocations = 353
277 were used, 76 timed-out
- Queue-based rig allocations = 347
176 requests allocated without a wait
171 requests allocated after waiting
715 requests terminated before being allocated
Total rig usage time = 333 hrs 03 mins
Average allocations per active student = 7.46
Minimum student use = 1 session / 10 min 01 sec
Maximum student use = 49 sessions / 16 hrs 35 mins
25 students used the rigs for more than 5 hrs each.
1. A listing of all reservations that were made for the relevant rigs and, where a reservation was not canceled, the rig session that corresponded to the redemption of this reservation;
2. A list of all allocated rig sessions, including: which rig was accessed; when the session was requested; when it commenced; when it ended; and why the session was terminated (by user request, due to an idle time out, or for some other reason); and
3. A set of information on the rig types, user classes, permissions, rig capabilities, and so on.
Total time: 92.00 hours
In use or pending allocation: 74.90 hours
In active use: 46.64 hours (62 percent of usage time)
Idle use: 9.18 hours (12 percent of usage time)
Waiting: 19.08 hours (26 percent of usage time)
1. No allowance: Removal of the time allowance at the commencement of a session. The current Sahara implementation provides a configurable period (typically 10 minutes) during which a session will not be canceled if the user is either idle or has not yet logged in to the system. This means, for example, that a user who has a reservation at 3:00 pm will have until 3:10 pm to log in and commence their session before the session is canceled (though if they log in after 3:00 pm, the session would still be limited to completion by 4:00 pm). We could remove this period, so that if a user is not logged in at the commencement of a reserved session, then it will be immediately canceled, leaving the full period for a different user. While this would be beneficial, and would have minimal effect on the user experience, it only addresses part of the problems identified above. There are still many cases where a student may be logged in but idle (e.g., they may have left their computer) or complete an experiment very quickly, resulting in very short sessions, and the associated problem arising from a subsequent gap until the next reservation that is large, but not quite a full time slot.
2. FReduce: Allocation strategy modified to include forced reduction in maximum session duration for queued users. In this approach, the system can choose to allocate shorter periods than the normal session length (up to some maximum reduction in session length) in circumstances where this facilitates system performance. In the above scenario, at 3:10 pm the reservation is canceled, and then the queued user could be allocated a shorter 50 minute session rather than the normal default 60 minutes session. This is possible the simplest of the solutions and ensures a greater utilization of available rig time and minimization of queue lengths and waiting times, but at the expense of compromising the amount of time available to individual users.
3. OReduce: Allocation strategy modified to include optional reduction in maximum session duration for queued users. This is similar to the above approach but the user is given a choice as to whether they will accept the shorter session. When a shorter time window becomes available (the 50 minute window from 3:10 to 4:00 pm in the above example) users in the queue, who are nominally entitled to a longer period, are sequentially asked whether they would like to accept this shorter period until one is found who will accept the session. In many cases, they may know that they are able to complete the experiment quickly and would be willing to accept a shorter time slot if one is available in preference to waiting for a slot that guarantees their maximum time allocation. While requiring a more complex set of user interactions, it has the benefit that it does not force a user to accept a shorter session, and hence allows sessions of almost any length to be offered to users.
4. Delay: Allocation strategy modified to include possible delay of commencement of reserved sessions by up to a configurable amount. This involves modifying the interpretation of reservations so that they represent an approximate time at which a rig will be made available, rather than a guaranteed time (much like a reservation to see a doctor, where you arrive at the appointment time, and may need to then wait a “short” amount of time before the doctor is able to see you). If we have the flexibility to delay the start of the 4:00 pm booking until 4:10 pm, then the queued use can be allocated at 3:10 pm and still have the full 60 minute session (if they need it). In many cases, it would be likely that the queued user would complete the experiment in less time than the maximum allowed, and the 4:00 pm booking may not end up being affected at all.
5. Both: Allocation strategy modified to include both the option of a reduced length session and the possible delay of commencement of reserved sessions (as described above).
For reservation-based accesses
- Where a user failed to redeem a reservation in the original case study, they will also fail to redeem the reservation in the simulations;
- Where a user redeemed a reservation, in the simulations their session time will be the same as for the case study.
For queue-based accesses
- When a user queued for access, but failed to redeem a session once allocated, the same situation will apply in the simulations. In the case where this user is offered a shorter session, they will not respond to the offer.
- When a user queued for access and subsequently made use of an allocated session, their usage time in the simulation will remain the same. If they are offered a session that is shorter than the maximum, then their probability of accepting the offer will be modeled as follows:
where is the length of the session offered to the student, is the actual time that the student took in the real case study, and is the normal session time that is allocated (usually 1 hour in the case study). The parameter adjusts the likelihood that a student will accept the offer (and for our simulations, we set ). This formula results in users always accepting any offer when , and never accepting any session offer when .
Average queue length;
Average time spent waiting in queue;
Proportion of time a rig was not allocated while there were users waiting in a queue.
For the OReduce and Both algorithms, the number of times the option of a reduced length session was accepted, and the average reduction in maximum allowed time.
For the Delay and Both algorithms, the number of times the commencement of a reservation was delayed, and the average delay.
At time 1,036, we have three queued users. With the original allocation strategy there was only 50 minutes between the end of the reservation at 1,036:10 and the commencement of the next reservation at 1,037:00, and so none of the three queued users were allocated. In the modified strategy, each of the three was offered a shorter session (50 mins, 40 and 30 mins, respectively) and all three accepted, thereby reducing the queue length and wait time. A similar situation occurred at time 1,049.
At time 1,051, again a 50 minute session was offered to a queued user, who accepted the offer and subsequently used the rig for 27 minutes. This contrasts to the queued user at time 1,044, who was offered a 50 minute session at time 1,044:10 but declined the offer, subsequently using the rig for a full 60 minutes at 1,048:10.
At time 1,043:17, a queued user arrives, and there is only 43 minutes until the reservation at 1,044. With the original strategy, this user cannot be allocated, but in the modified algorithm, the reservation can be delayed by up to 20 minutes, and so the queued user is immediately allocated. This user uses the rig for a full 60 minutes, and so the user with the reservation at 1,044 is delayed until 1,044:17.
At time 1,036:10, the next reservation was in 50 minutes, at 1,037:00, but given the option of a delay, this created the possibility of a 70 minute session—10 minutes longer than the default 60 minutes. Consequently, a queued user was allocated to the rig. This session subsequently only lasted 10 minutes and so there was no resultant delay to the reservation at time 1,037. A similar situation occurs at time 1,051:10, though in this case the resultant user uses the rig for 25 minutes—again with no resultant delay to the reservation. This appears to be the predominant situation—i.e., a potential delay that does not eventuate.
The author is with the School of Information Technologies, The University of Sydney, Building J12, Camperdown, NSW 2006, Australia.
Manuscript received 14 May 2012; revised 18 Oct. 2012; accepted 9 Dec. 2012; published online 15 Jan. 2013.
For information on obtaining reprints of this article, please send e-mail to: firstname.lastname@example.org, and reference IEEECS Log Number TLT-2012-05-0070.
Digital Object Identifier no. 10.1109/TLT.2013.5.
1. Each discrete item of experimental apparatus is often referred to, within the RL literature, as a rig and a collection of functionally identical rigs is referred to as a pool.
2. See http://www.labshare.edu.au/.
David Lowe received the BE (hons.), PhD, and GradCert (higher education) degrees. He is the associate dean (education) and a professor of software engineering at the Faculty of Engineering and IT, The University of Sydney. He is also the CEO of the not-for-profit organization The LabShare Institute, and president of the Global Online Laboratory Consortium. He has active research interests in the areas of real-time control of embedded systems in the web environment, and remote access to, and control of, physical laboratory systems. He has published widely, including more than 150 papers and three books. He is a senior member of the IEEE.