Re: [Gabel-guys] experiment waiting room

[Allen L. <al...@cs...>]

Hey Rob, another quick question - how often do we need to sample the data
collection, and what data needs to be collected (currently client number,
location, total amount of food consumed).  Does this need to be configurable
as well?  

Allen

On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote:
> Hi Allen,
> An experiment can't really be a set of rounds, because people will be coming
> in and out.  If we could imprison subjects for an hour or so, then we could
> be sure of having the same subjects, but we can't do this.  So, the short
> answer to your question is that a "per round" makes sense.  Each 5-10 minute
> experiment is logically independent of the others, even though there may be
> an orderly arrangement to which configurations of an experiment are
> presented when.  In terms of statistical analyses, this means that we'll be
> using "between-subjects" rather than "within-subject" designs.
> 
> The rest of what you describe makes good sense.  For Forager and social
> choice I'm not envisioning any upper limit to the number of people involved.
> So, I don't expect we'll be spawning new experiments if one is filled up.
> This is fine functionality to include though, because I could imagine it
> coming up down the road.
> Ciao,
> Rob
> 
> > Andy and I have come up with an issue that I thought would be good to have
> > some feedback on.  We've been discussing how we want to implement the 'waiting
> > room' functionality.  Right now we're leaning towards the following
> > interaction model:
> > 
> > 1. User hits the web page listing available games.  Web page checks KNS to see
> > which services are available and dynamically generates hyperlinks encoded with
> > the specific host and port information for that particular server.
> > 
> > 2. User clicks on a specific hyperlink, that takes them to the applet,
> > automatically connecting them to that experiment server.
> > 
> > 3. Here's where we need some clarification or at least a "yes keep doing
> > that".  We decided to 'throttle' connections at the experiment server end, not
> > the KNS end.  This means that people will be making connections to the
> > experiment server regardless of whether or not an experiment is already in
> > progress, etc.  What we plan to do here is the following:
> >   a. If there is no experiment session is in progress, or all current
> >   experiment sessions are already full, a new experiment session is started.
> >   We're going to have to worry about dealing with a maximum allowable limit
> >   to this, of course, but we're leaving that for later since it's not
> >   immediately needed.
> > 
> >   b. If there is an experiment session in progress and it is not full, the
> >   user gets queued up for that particular experiment session and begins
> >   playing in that experiment session in the next round.  I was wary of this
> >   idea when Andy first mentioned it because I had some artificial notion
> >   that an experiment was a logical set of rounds, and the participants for a
> >   given experiment should remain static throughout this set to keep it
> >   cohesive.  Since experiments will be randomized anyhow, we're leaning
> >   towards the per-round implementation, so a user connects to the forager
> >   server and gets slapped into the next round of forager.
> > 
> > DING: Here's where we need confirmation/clarification.  Do participants join
> > on a per-round basis or on a per experiment session basis?  Will this change
> > for other experiments? Also, how long do we keep running these rounds?  Do we
> > let someone play forager for 37 hours?  Do you need to interpret their data
> > differently?
> > 
> > This is a pretty trivial question, but it's kind of a stumbling block right
> > now.
> > 
> > Thoughts?
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > gabel-guys mailing list
> > gab...@li...
> > https://lists.sourceforge.net/lists/listinfo/gabel-guys
> > 
> > 
> >