> Destination Dispatch [...] are in general worse
I wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be:
- Everyone who is not on the ground floor generally want to go to the ground floor.
- People who are on the ground floor generally travel in large groups to the same destination.
This happens because people who worked on the same floor often leave for lunch at the same time, and return at the same time to the same floor. Destination Dispatch helps in this case because it's batching large groups of people with the same destination.
It is almost certainly because of the way the simulation was performed:
It turns out these fancy kiosks are in general worse for wait times compared to the traditional good ol' up and down buttons. There are certainly edge cases when the kiosks can win out (extremely tall buildings with 8+ cars per elevator bank) but for the majority of cases, simple up down buttons reign supreme.
This counterintuitive result is all thanks to the rebalancing step where every 5 seconds, the system re-optimizes each elevator's path. The kiosk enforces rigidity, you must get in the assigned elevator.
There should be no way that only having more information results in a worse outcome. At minimum, you could ignore the extra information, and achieve the same results as using up and down buttons.
Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
> Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
I don't think it's possible to have destination dispatch AND update assignment together, in the real world.
- If the user clicks floor 26 and you tell them to wait at elevator G, you can't really tell them to move to F if it's taking too long.
- But if you don't tell them an elevator to wait at, then you'd need them to run around what is possibly like 5-8 elevators to find which one is going to their floor? That's obviously not realistic.
So then you're going to just have them get in the first one that opens? But then that's just the same as an up/down button.
That explanation is entirely inconsistent with sambellll's statement that when the user clicks a floor, the display tells them what elevator to take, and that elevator is then locked into going to that floor.
Also, I don't think that destination dispatch would work if the elevator didn't commit to going to the users's floor at the point the user got onboard. It may also stop at additional floors that weren't committed to when the user entered, and it may drop floors it was thinking of going to before it picked up the user (if the user onboard isn't going to those floors), but once the user gets onboard, that floor is a hard commitment.
omoikane · · focus · HN ↗
I wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be:
- Everyone who is not on the ground floor generally want to go to the ground floor.
- People who are on the ground floor generally travel in large groups to the same destination.
This happens because people who worked on the same floor often leave for lunch at the same time, and return at the same time to the same floor. Destination Dispatch helps in this case because it's batching large groups of people with the same destination.
richk449 · · focus · HN ↗
It turns out these fancy kiosks are in general worse for wait times compared to the traditional good ol' up and down buttons. There are certainly edge cases when the kiosks can win out (extremely tall buildings with 8+ cars per elevator bank) but for the majority of cases, simple up down buttons reign supreme.
This counterintuitive result is all thanks to the rebalancing step where every 5 seconds, the system re-optimizes each elevator's path. The kiosk enforces rigidity, you must get in the assigned elevator.
There should be no way that only having more information results in a worse outcome. At minimum, you could ignore the extra information, and achieve the same results as using up and down buttons.
Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
sambellll · · focus · HN ↗
I don't think it's possible to have destination dispatch AND update assignment together, in the real world.
- If the user clicks floor 26 and you tell them to wait at elevator G, you can't really tell them to move to F if it's taking too long.
- But if you don't tell them an elevator to wait at, then you'd need them to run around what is possibly like 5-8 elevators to find which one is going to their floor? That's obviously not realistic.
So then you're going to just have them get in the first one that opens? But then that's just the same as an up/down button.
richk449 · · focus · HN ↗
Why not have active display above each elevator that says what floors it is going to when it opens?
NetMageSCW · · focus · HN ↗
richk449 · · focus · HN ↗
Also, I don't think that destination dispatch would work if the elevator didn't commit to going to the users's floor at the point the user got onboard. It may also stop at additional floors that weren't committed to when the user entered, and it may drop floors it was thinking of going to before it picked up the user (if the user onboard isn't going to those floors), but once the user gets onboard, that floor is a hard commitment.