Changes between Version 17 and Version 18 of Documentation/bAccountManagement/aScheduler
- Timestamp:
- Oct 18, 2013, 10:30:34 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Documentation/bAccountManagement/aScheduler
v17 v18 1 = Scheduling and Reservation=1 == Scheduling and Reservation == 2 2 3 == Reservations==3 === Reservations === 4 4 5 5 As this is a wireless testbed, it is difficult to run multiple experiments without interference. Therefore, we currently only support one experiment at a time on the individual grid. In Orbit speak, a grid is a set of nodes together with the controlling console which can be used to run experiments. In the present setup, the testbed consists of a single large grid (main grid) with 400 nodes and an array of sandboxes i.e. "grids" with only 2 nodes and a console, which are development and test environments intended to reduce the time experimenters need on the main grid. Ideally, experimenters develop their software (application programs, routing protocols, measurement instrumentation, etc.) on off-site machines and then use the sandboxes for integration with the orbit environment and orbit software infrastructure. Once the experiment runs successfully in the sandbox environment, it can be moved to the main grid. … … 19 19 Reservations slots are approved by the scheduling service based on the [wiki:Documentation/Scheduling#ReservationApprovalPolicies two stage approval policy]. Once it has been approved, the color for that slot will be changed to dark blue and approval email notification message will be sent to the requester and requester will be able to access the console of the resource whose reservation was just approved. 20 20 21 == Conflicts==21 === Conflicts === 22 22 23 23 It is possible to ask for a particular slot even if other user already made a reservation for it. The procedure is the same as for requesting an empty slot except that the resulting color changes to red once there are multiple simultaneous (conflicting) reservations as shown in Figure 2. … … 26 26 ||Figure 2: Scheduling Conflicts|| 27 27 28 == Reservation Approval Policies==28 === Reservation Approval Policies === 29 29 30 30 Reservation approval process is based on a two stage algorithm. In the first (pre-approval) stage, scheduling requests received before noon will be pre-approved for the following day. For example, if it is Tuesday morning before noon, and you ask for 4 to 6 in the evening Wednesday, you will know for sure whether you have this time by 2 in the afternoon on Tuesday. Users are limited to two hours a day of pre-approved time on the main grid. … … 32 32 For the reservations that are made less than twelve hours in advance or for ones that are more than 2 hours a day, the slots will be automatically approved at the beginning of the slot (second or just-in-time approval stage). 33 33 34 == Conflict Resolution==34 === Conflict Resolution === 35 35 36 36 Conflicts will be resolved based on how much time you've already used over the last two weeks. Those who have used less time on the main grid in the last two weeks will be more likely to have their requests approved for the conflicting slots. Exception is when user already has an approved slot. We are trying to give slots to as much people as we can during a day.
