Self restarting property of RTOS-How it works?

In article <opsl7syzh8qm36vk@grunion>, Joe Seigh <jseigh_01@xemaps.com> wrote:
>On 14 Feb 2005 21:58:49 GMT, Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>
>> In article <ud8Qd.57$OU1.45@newssvr21.news.prodigy.com>,
>> Kelly Hall  <khall@acm.org> wrote:
>>> If the system sends too mare cars to a request, the cost is momentary
>>> inconvenience for the passengers of the extra car.  If the system sends
>>> too few cars to a request, some people get annoyed.
>>
>> No, you have got that wrong.  If it sends too many, the effect is that
>> the average waiting time goes up for 'random' use patterns.
>>
>Actually, sending two elevators down to the ground floor makes sense.  If
>you only send one down, it's coming right back up and you'll have both
>elevators at the upper floors again.  Send two down, and one stays down
>waiting at the ground floor.

There are circumstances when it makes sense, but you should think that
one through a bit more.  Think of a precise, reasonable model (i.e.
one that does not involve the accumulation of people inside the
building) and work it out.  Quite subtle differences in the model can
lead to big differences in whether particular naive rules help.

It is a hell of a long time since I looked at this one (and I never
looked at it closely), but I can remember that none of the naive
algorithms are much use in practice.  There ARE some good ones, but
even they have problems.


Regards,
Nick Maclaren.

Nick Maclaren wrote:
>> Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>
... snip ...
>>
>> Actually, sending two elevators down to the ground floor makes
>> sense.  If you only send one down, it's coming right back up and
>> you'll have both elevators at the upper floors again.  Send two
>> down, and one stays down waiting at the ground floor.
> 
> There are circumstances when it makes sense, but you should think
> that one through a bit more.  Think of a precise, reasonable model
> (i.e. one that does not involve the accumulation of people inside
> the building) and work it out.  Quite subtle differences in the
> model can lead to big differences in whether particular naive
> rules help.
> 
> It is a hell of a long time since I looked at this one (and I
> never looked at it closely), but I can remember that none of the
> naive algorithms are much use in practice.  There ARE some good
> ones, but even they have problems.

I would expect better algorithms would await better input methods. 
For example, instead of selecting from 'up' or 'down', the
prospective rider could select the destination floor.  Now an
arriving car has to display which floors it will handle, and
separate the sheep from the goats.  The sheep and goats have to be
sufficiently alert to be separated.  Maybe something along the
lines of "take a ticket" based on rfids would work.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

In article <4211F82F.3035D23D@yahoo.com>,
CBFalconer <cbfalconer@yahoo.com> writes:
|> 
|> I would expect better algorithms would await better input methods. 
|> For example, instead of selecting from 'up' or 'down', the
|> prospective rider could select the destination floor.  Now an
|> arriving car has to display which floors it will handle, and
|> separate the sheep from the goats.  The sheep and goats have to be
|> sufficiently alert to be separated.  Maybe something along the
|> lines of "take a ticket" based on rfids would work.

Yes.  As with all such issues, a very small amount of extra
information can make a great deal of difference.  Similarly,
you could have a special program for rush hours (and the morning
one might be very different from the evening one).  What becomes
very clear on a fairly casual inspection is that understanding
the properties of the input data is a prerequisite to designing
good algorithms.

This is very, very relevant to telecommunications and many
aspects of computing, as all experts in the relevant aspects know
very well.  I know just enough to have a glimmering of the depths
of my ignorance :-)


Regards,
Nick Maclaren.

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message 
news:cut7cl$c0o$1@gemini.csx.cam.ac.uk...
>
> In article <4211F82F.3035D23D@yahoo.com>,
> CBFalconer <cbfalconer@yahoo.com> writes:
> |>
> |> I would expect better algorithms would await better input methods.
> |> For example, instead of selecting from 'up' or 'down', the
> |> prospective rider could select the destination floor.  Now an
> |> arriving car has to display which floors it will handle, and
> |> separate the sheep from the goats.  The sheep and goats have to be
> |> sufficiently alert to be separated.  Maybe something along the
> |> lines of "take a ticket" based on rfids would work.
>
> Yes.  As with all such issues, a very small amount of extra
> information can make a great deal of difference.

The key word here is "can".  In thinking about this particular possibility, 
it seems the big advantage would be if one could have multiple elevators 
where one would service the "higher" floors and one the "lower".  Then the 
people going to the higher ones wouldn't have to wait for all the stops in 
the lower ones.  This is probably only usefull for fairly tall buildings. 
In fact, for such buildings, something like this is frequently done.  I have 
been in buildings with multiple banks of elevators each clearly labeled with 
the range of floors they service.  While this doesn't have the flexibility 
of being able to change the floors serviced dynamically, it avoids the need 
for dynamic "sheep/goat separation", (with presumably a higher mistake rate 
than a static system) as described above.

> Similarly,
> you could have a special program for rush hours (and the morning
> one might be very different from the evening one).

I think this is pretty standard for tall buildings.

> What becomes
> very clear on a fairly casual inspection is that understanding
> the properties of the input data is a prerequisite to designing
> good algorithms.

Absolutely.  And, since the elevator companies have been at this for 
something like a century now, the have worked out an awful lot of the "best 
practices".

> This is very, very relevant to telecommunications and many
> aspects of computing, as all experts in the relevant aspects know
> very well.

Absolutely.

> I know just enough to have a glimmering of the depths
> of my ignorance :-)

Me too.  :-)

-- 
 - Stephen Fuld
   e-mail address disguised to prevent spam 

Stephen Fuld wrote:
> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
>> CBFalconer <cbfalconer@yahoo.com> writes:
>>>
>>> I would expect better algorithms would await better input methods.
>>> For example, instead of selecting from 'up' or 'down', the
>>> prospective rider could select the destination floor.  Now an
>>> arriving car has to display which floors it will handle, and
>>> separate the sheep from the goats.  The sheep and goats have to be
>>> sufficiently alert to be separated.  Maybe something along the
>>> lines of "take a ticket" based on rfids would work.
>>
>> Yes.  As with all such issues, a very small amount of extra
>> information can make a great deal of difference.
> 
> The key word here is "can".  In thinking about this particular
> possibility, it seems the big advantage would be if one could have
> multiple elevators where one would service the "higher" floors and
> one the "lower".  Then the people going to the higher ones wouldn't
> have to wait for all the stops in the lower ones.  This is probably
> only usefull for fairly tall buildings.  In fact, for such
> buildings, something like this is frequently done.  I have been in
> buildings with multiple banks of elevators each clearly labeled
> with the range of floors they service.  While this doesn't have the
> flexibility of being able to change the floors serviced
> dynamically, it avoids the need for dynamic "sheep/goat
> separation", (with presumably a higher mistake rate than a static
> system) as described above.

Already done, in the tall buildings.  There the problem is to
conserve elevator shaft space.  Works something like airline hubs
and feeder lines.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:

> 
> Already done, in the tall buildings.  There the problem is to
> conserve elevator shaft space.  Works something like airline hubs
> and feeder lines.
> 
And I've seen proposals (still in the gee-whiz) stage to have an "up" 
shaft, a "down" shaft and a few cross-shafts, with motors in the 
elevator cars so they have more autonomy for getting up and down.

It was a popular science kind of thing -- I have no idea if it's being 
seriously developed (but it'd be fun to do the software!).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

In article <1114jf5fbfah663@corp.supernews.com>,
Tim Wescott  <tim@wescottnospamdesign.com> wrote:
>CBFalconer wrote:
>And I've seen proposals (still in the gee-whiz) stage to have an "up" 
>shaft, a "down" shaft and a few cross-shafts, with motors in the 
>elevator cars so they have more autonomy for getting up and down.

Sounds like the "Tower of Terror" ride at the MGM Studios park at
Disney World.  The elevator "car" seats 12 people or so, and starts
out running vertically.  It then switches into a horizontal haunted
house mode of operation before finishing vertically again.  Think
of the fun the BOFH would have.  He he. :-)
-- 

Craig Ruff      	NCAR			cruff@ucar.edu
(303) 497-1211  	P.O. Box 3000
			Boulder, CO  80307

Tim Wescott wrote:
> CBFalconer wrote:
> 
>>
>> Already done, in the tall buildings.  There the problem is to
>> conserve elevator shaft space.  Works something like airline hubs
>> and feeder lines.
>>
> And I've seen proposals (still in the gee-whiz) stage to have an "up" 
> shaft, a "down" shaft and a few cross-shafts, with motors in the 
> elevator cars so they have more autonomy for getting up and down.
> 
> It was a popular science kind of thing -- I have no idea if it's being 
> seriously developed (but it'd be fun to do the software!).

Google "wonkavator"  (:

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:421237FB.FB33D465@yahoo.com...
> Stephen Fuld wrote:
>> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
>>> CBFalconer <cbfalconer@yahoo.com> writes:
>>>>
>>>> I would expect better algorithms would await better input methods.
>>>> For example, instead of selecting from 'up' or 'down', the
>>>> prospective rider could select the destination floor.  Now an
>>>> arriving car has to display which floors it will handle, and
>>>> separate the sheep from the goats.  The sheep and goats have to be
>>>> sufficiently alert to be separated.  Maybe something along the
>>>> lines of "take a ticket" based on rfids would work.
>>>
>>> Yes.  As with all such issues, a very small amount of extra
>>> information can make a great deal of difference.
>>
>> The key word here is "can".  In thinking about this particular
>> possibility, it seems the big advantage would be if one could have
>> multiple elevators where one would service the "higher" floors and
>> one the "lower".  Then the people going to the higher ones wouldn't
>> have to wait for all the stops in the lower ones.  This is probably
>> only usefull for fairly tall buildings.  In fact, for such
>> buildings, something like this is frequently done.  I have been in
>> buildings with multiple banks of elevators each clearly labeled
>> with the range of floors they service.  While this doesn't have the
>> flexibility of being able to change the floors serviced
>> dynamically, it avoids the need for dynamic "sheep/goat
>> separation", (with presumably a higher mistake rate than a static
>> system) as described above.
>
> Already done, in the tall buildings.  There the problem is to
> conserve elevator shaft space.  Works something like airline hubs
> and feeder lines.

That is a different solution.  What you are talking about is "stacked" 
elevators, where you have to get off at some intermediate floor and switch 
to another elevator.  That is the only way to conserve shafts.   What I was 
talking about was where all the elevators went to the lobby, but only to a 
subset of the upper floors.  Doesn't conservve shafts, but reduces total 
time for those wanting to go to the upper floors, as they don't have to wait 
through all the stops on the lower ones.

-- 
 - Stephen Fuld
   e-mail address disguised to prevent spam 

> I would expect better algorithms would await better input methods. 
> For example, instead of selecting from 'up' or 'down', the
> prospective rider could select the destination floor.  

I've been in two buildings in recent years where the elevator user interface
works just in that way. One is ~30 stories, but the other is only 14, IIRC.
Both have access control via RFID cards, and those cards can be programmed
to either just allow a single floor - no need to enter the data then - or
a range of floors. Once the desired floor has been entered (explicitly or
implicitly), the display will show the letter of the elevator that will
service you. For larger parties, it is recommended to enter the data more
than once.

	Jan