stats for Raith reservations in the coming week.

Mark Topinka mtopinka at stanford.edu
Sun Feb 1 22:10:36 PST 2004


Hi everyone. I liked and am following Dan's suggestion to compile stats on 
Raith usage to help us decide on a reasonable policy.  I've compiled stats 
on the usage logged into coral as of right now for the next week from 
8:30pm 2/1/2004 through 8:30pm 2/8/2004.   I've also included a quick 
analysis of what a 10hr or 8hr cap on reservations would buy us.  I wanted 
to get this to people so that those who are interested could become 
familiar with the numbers before the town-hall meeting tomorrow.   By the 
way, just to avoid misunderstandings, an "8 or 10 hour cap / 2week on 
RESERVATIONS" is not the same as an "8 or 10 hour cap / 2week on 
USAGE".   Now, no policy we come up with will be *perfect*!  But, that 
said, I'm in favor of making an 8 hour cap with a 2 week 
reservation-horizon policy, because I think the numbers in this spreadsheet 
show that this policy would open up enough time in the reservation schedule 
to allow people to make reservations in a more sane fashion (ending the 
current every-30-minutes-reservation ridiculousness), and I believe this 
policy would also result in a fair allocation of hours among users.  Again 
(sorry for repeating myself) this WILL NOT limit people to 8 hours of usage 
per 2 weeks.  I hopefully can explain myself more fully tomorrow.



If you're interested in looking at the reservation stats for the coming 
week, here are the different columns in the attached spreadsheet are (from 
left to right)

ColumnA: username (I just called people UserA, UserB, UserC, etc. to keep 
it anonymous)
ColumnB: Tot.Hours: just the total hours reserved for the coming week by 
that user
ColumnC: #.of.reservations by each user
ColumnD: average length of each reservation by that user
ColumnE: minimum # of hours that would have to be opened by that user right 
now with a 10 hour cap.  (Assuming that users simply get rid of just enough 
time to get under new cap)
ColumnF: actual # of hours that might reasonably be expected to be opened 
by that user right now with a 10 hour cap (Assuming that users give up all 
reservations that would exceed 10hr cap, and don't expand their other 
ones.  This is a rough estimate which uses ColumnD)
ColumnG & H: same as E & F but with an 8 hour cap.

I've included simple analyses (I know they're not perfect) of what the two 
simplest proposals for solving the time-crunch problem would probably buy 
us.  Those two proposals are to make a 10hr cap or an 8hr cap.  (See the 
descriptions of the columns above for the algorithm I used to get these 
numbers)   It makes no difference to the numbers in the spreadsheet whether 
we allow people to reserve two weeks in advance, although I have to say 
that I firmly believe extending the reservation horizon out to 2 weeks 
while simultaneously lowering the current-reservations-cap to 10 or 8 hours 
would completely solve the "every-30-minutes" problem.  I can explain more 
my reasoning on that at "town-meeting" tomorrow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reservation_stats.xls
Type: application/octet-stream
Size: 17920 bytes
Desc: not available
URL: <http://snf.stanford.edu/pipermail/raith/attachments/20040201/723afe46/attachment.obj>


More information about the raith mailing list