Standby reservations are sometimes not available when using all three reservation modes.

Where all three reservation modes are available (Immediate, Queued and Scheduled), Signup Clients with can act in an unexpected fashion. They do not always allow Standby reservations.
 
 For example, if a PC is reserved for 4PM, it may display "Waiting for X" at 3:30, when you would expect it to that it is available for 30 minutes.

This is an expected result of an issue associated with using all three reservation modes together. This problem occurs when a queue has to fit around a set reservation time. Queued users have no control over whether or not they are willing to accept a reservation for a shorter than normal session. Because of this, PCs that have Scheduled reservations pending on them will become unavailable for Queued or Immediate reservations in advance of the Scheduled reservation starting.

Once the amount of time left before the start of a Scheduled reservation is less than the Maximum Reservation Duration, the PC goes into “pre-reserved” state. While pre-reserved, the PC cannot be assigned to users waiting in the queue, but is available to the user who made the Scheduled reservation. The Scheduled user has the option of starting their session early (although this will not allow them to have a longer session—they will finish early as well).

For example, on a site where the Maximum Reservation Duration is 30 minutes, User A books a PC for a 30-minute session starting at 11:30. After 11.00, once the current user logs off the PC, it goes into “pre-reserved” state, and will no longer accept Queued reservations. User A may log on any time between 11:00 and 11:30.

More details:

When a Scheduled reservation exists, the time available on that machine will eventually be less than that of a normal session (e.g. the normal duration for a PC is 1 hour, but there is now only 30 minutes available on that machine). However, because the SignUp system doesn't know exactly when a Queued reservation is going to start (because it depends on when the most recent user logs off), it could get assigned to a machine which may only have 10 minutes left before the next Scheduled reservation is due to start on it.

Once a user is added to the queue, it is assumed that they want a full 60 minute duration and that the machines with less time are not suitable for that, so the machines go into the pre-reserved state. (It was expected that scheduled reservation users would probably turn up a few minutes early to be sure they were there when their reservation started, so scheduled reservation users can log on early if they arrive early. Their reservation will be moved forward if they log on early - it won't give them a longer duration.) You can recognize a pre-reserved state by the fact that there is no Unclaimed Session Timeout counting down on the screen. This countdown will start showing on the screen once the clock hits the official start time of the session.

There were two main requirements for the system: that it be simple to understand and use, and that it be fair. The reasoning for the pre-reserved state was that queue-jumping was an issue - the system needs to ensure that those that ask for a PC first, get one first. If a queue already exists and a user logs off a machine which does not have a full duration available before the next scheduled reservation is due to start, then it did not seem fair to allow a user who has just walked in off the street to walk up and use the shorter duration PC (as an Immediate reservation) ahead of people who have been waiting in the queue (and, as mentioned, offering a short duration to a patron waiting in the queue could be too complicated for some patrons to understand). A further complication to this was that if we did implement some way of allowing users to choose whether they accepted some sort of shorter duration (e.g. if we gave them this choice at the time of adding themselves to the queue), then if some users were assigned short duration PCs ahead of other users who chose not to accept them, then there could be the appearance of queue-jumping, and we had seen in certain sites that the 'appearance' of queue-jumping (even if there wasn't really any) was a distinct problem and caused much trouble. While we considered the option of giving users a choice of taking short durations at the time they made their queued reservation, it was thought it would have made creating a reservation far too complicated - e.g. how would we determine from the user how short was acceptable (when in most cases this wouldn't even be an issue), etc. And then the same 'bubbling' problem would arise in the situations where the duration between logoff of one user and start time of the next scheduled reservation was shorter than the minimum that the next queued user was prepared to accept.

Going back to the comment about ensuring that new users just walking in were not able to use short duration machines ahead of those patiently waiting in the queue... the question could be asked, well, why not let those waiting in the queue use the machines while they wait for their queued reservation. Unfortunately, there was a need to stop abuse of the system whereby a user adds themselves multiple times to the queue - reserving large chunks of time (and machines) ahead of other users. To deal with this, a rule had to be created that once a user was in the queue they could not use a machine or add themselves to the queue again until they had used or cancelled their existing queued reservation. So, it would not be possible for an existing queued user to use a short duration machine as they were already in the queue.