อัลกอริทึมการจัดคิวลิฟต์

 (john.fun)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเดินลิฟต์ไม่ใช่แค่การตอบสนองต่อการเรียกแบบง่าย ๆ แต่เป็น ปัญหาการเพิ่มประสิทธิภาพการจัดคิว ที่ต้องพิจารณาจำนวนลิฟต์ กระแสผู้โดยสาร น้ำหนักบรรทุก และทิศทางการเคลื่อนที่ร่วมกัน
  • SCAN สำหรับลิฟต์คันเดียวจะเปลี่ยนทิศที่ชั้นบนสุด ส่วน LOOK จะกลับทิศที่ชั้นสูงสุดที่มีคำขอจริง จึงใกล้เคียงกับความคาดหวังทั่วไปต่อการเดินลิฟต์มากกว่า
  • RSR(Relative System Response) สำหรับลิฟต์หลายคันจะให้คะแนนจากเวลาถึงโดยประมาณ น้ำหนักบรรทุก ฯลฯ และปรับการจัดคิวให้เหมาะสมใหม่ทุก 5 วินาที ทำให้สามารถย้ายผู้โดยสารของลิฟต์ที่ล่าช้าไปยังลิฟต์คันอื่นได้
  • หากลิฟต์เต็มตลอดเวลา หรือมีปริมาณผู้โดยสารมากจนต้องจอดแทบทุกชั้นและจำนวนลิฟต์มีน้อย LOOK แบบเรียบง่ายอาจดีกว่า RSR ที่ซับซ้อน
  • Destination Dispatch ที่ให้ป้อนชั้นปลายทางล่วงหน้าช่วยให้ได้ข้อมูลมากขึ้น แต่เปลี่ยนลิฟต์ที่ถูกกำหนดไว้ได้ยาก ดังนั้นยกเว้นบางกรณี เช่น อาคารสูงพิเศษหรือมีลิฟต์ 8 คันขึ้นไปต่อกลุ่ม เวลารอมักยาวกว่าปุ่มขึ้น/ลงแบบดั้งเดิม

ลิฟต์คันเดียวเปลี่ยนทิศที่ไหน

  • SCAN ซึ่งได้รับสิทธิบัตรในปี 1961 จะออกจากล็อบบี้ ขึ้นไปจนถึงชั้นบนสุดแล้วเปลี่ยนทิศลงมา พร้อมรับและส่งผู้โดยสารตามเส้นทาง
  • LOOK จะไม่ขึ้นไปถึงชั้นบนสุดโดยไม่มีเงื่อนไข แต่จะวิ่งไปถึงแค่ชั้นสูงสุดที่มีคำขอ แล้วจึงกลับทิศ
  • โดยทั่วไป รูปแบบการเดินลิฟต์ที่ผู้คนรู้จักและคาดหวังจะใกล้เคียงกับ LOOK

การจัดคิวพื้นฐานสำหรับลิฟต์หลายคัน

  • หากมีลิฟต์หลายตัว ต้องประสานว่าลิฟต์คันไหนจะรับคำเรียกใด
  • ในระบบพื้นฐาน ตัวจัดตารางส่วนกลาง จะกำหนดชั้นที่แต่ละลิฟต์ต้องจอด และจัดสรรคำเรียกใหม่ให้กับลิฟต์ที่อยู่ใกล้ที่สุด
  • แต่การจัดคิวที่อิงระยะทางอย่างเดียวสะท้อนสถานการณ์อย่างลิฟต์ใกล้สุดแต่เต็มแล้วได้ไม่เพียงพอ

วิธีประเมินเวลารอ

  • ตัวชี้วัดที่เข้าใจง่ายที่สุดของอัลกอริทึมลิฟต์คือ เวลารอ ตั้งแต่เรียกลิฟต์จนลิฟต์มาถึง
  • แบบง่าย ๆ สามารถวัดสัดส่วนที่ลิฟต์มาถึงภายใน 30 วินาที หรือ 90 วินาที
  • หากต้องการประเมินอย่างเข้มงวดยิ่งขึ้น ให้รวบรวมเวลารอจากการเดินลิฟต์หลายพันครั้ง แล้วตรวจสอบ การกระจายและฮิสโตแกรม
    • ถ้า p90 เท่ากับ 2 นาที หมายความว่า 90% ของผู้โดยสารรอไม่เกิน 2 นาที
    • ถ้า p50 เท่ากับ 1 นาที หมายความว่าในครึ่งหนึ่งของการเรียก ลิฟต์มาถึงภายใน 1 นาที
  • ผู้โดยสารมีแนวโน้มจดจำ กรณี p90 ที่ต้องรอนานผิดปกติได้ชัดเจนกว่าค่าเฉลี่ยเวลารอ

กระแสผู้โดยสารที่เปลี่ยนไปตามช่วงเวลา

  • ตอนเช้าในอาคารสำนักงานขนาดใหญ่ การเดินทางส่วนใหญ่จะเป็นจากล็อบบี้ขึ้นไปยังชั้นบน
  • ตอนเย็น กระแสจากชั้นบนลงมาด้านล่างจะเด่นกว่าเนื่องจากคนเลิกงาน
  • ช่วงพักกลางวันจะมีทั้งขาขึ้นและขาลงปนกัน ส่วนช่วงเวลาอื่นจะมีการเดินทางระหว่างชั้นต่าง ๆ มาก
  • การกระจายของเวลารอเปลี่ยนแปลงอย่างมากตามช่วงเวลาและรูปแบบการสัญจร โดยเฉพาะสถิติใน ช่วงเวลาเข้างานตอนเช้า จะย่ำแย่

RSR เลือกลิฟต์คันใด

  • RSR(Relative System Response) ของ Otis ให้คะแนนว่าลิฟต์แต่ละคันเหมาะกับการรับผู้โดยสารมากน้อยเพียงใด โดยคะแนนยิ่งต่ำยิ่งเหมาะสม
  • คะแนนการรับผู้โดยสารคำนวณจากการผสมผสานหลายปัจจัย
    • เวลาถึงโดยประมาณ ไปยังชั้นที่เรียก
    • ค่าปรับจากน้ำหนักบรรทุกตามจำนวนผู้โดยสารที่อยู่ในลิฟต์
    • ค่าปรับเพื่อป้องกันการกระจุกตัว เมื่อมีลิฟต์อีกคันกำลังมุ่งหน้าไปยังชั้นเดียวกันในทิศทางเดียวกันอยู่แล้ว
    • โบนัสเมื่อทิศทางการเคลื่อนที่ตรงกัน
    • โบนัสสำหรับลิฟต์ว่างที่อยู่ภายในสองชั้นจากชั้นที่เรียก
    • โบนัสเมื่อน้ำหนักบรรทุกต่ำ
  • การป้องกันการกระจุกตัว(anti-bunching) จะยับยั้งการจัดสรรเพิ่มเติม หากมีลิฟต์อีกคันมุ่งหน้าไปยังชั้นเดียวกันในทิศทางเดียวกันอยู่แล้ว
  • RSR จะปรับการจัดคิวทั้งหมดให้เหมาะสมใหม่ทุก 5 วินาที
    • หากลิฟต์ A ล่าช้า สามารถมอบหมายผู้โดยสารที่เดิมควรขึ้น A ใหม่ให้ไปขึ้นลิฟต์ B ได้
    • การปรับให้เหมาะสมซ้ำอย่างต่อเนื่องเช่นนี้คือหัวใจที่ทำให้กระแสผู้โดยสารไหลลื่น

ความแตกต่างด้านประสิทธิภาพระหว่าง LOOK และ RSR

  • การใช้เครื่องมือวิเคราะห์เวลารอทำให้เปรียบเทียบสัดส่วนการมาถึงภายใน 30 วินาทีและ 90 วินาทีของ LOOK กับ RSR ได้
  • เมื่อปริมาณผู้โดยสารสูงขึ้น LOOK จะเริ่มนำหน้า RSR
    • หากลิฟต์เต็มตลอดเวลาและจอดทุกชั้น ผลของกฎเพิ่มเติมใน RSR จะลดลง
  • ในอาคารขนาดเล็กที่มีจำนวนลิฟต์ต่อกลุ่มน้อย LOOK ก็มีแนวโน้มดีกว่า RSR เช่นกัน ดังนั้นวิธีที่เรียบง่ายกว่าอาจเหมาะสมกว่า
  • นอกจากเวลารอแล้ว ยังวัด เวลาเดินทาง หลังขึ้นลิฟต์จนถึงชั้นปลายทางได้ด้วย
    • LOOK และ RSR มีลักษณะต่างกันในตัวชี้วัดนี้เช่นกัน แต่ไม่ได้กล่าวถึงการเปรียบเทียบอย่างละเอียด

เหตุใด Destination Dispatch จึงเสียเปรียบแม้มีข้อมูลมากกว่า

  • Destination Dispatch คือวิธีที่ผู้โดยสารป้อนชั้นปลายทางที่คีออสก์ในแต่ละชั้นก่อน แล้วระบบจะกำหนดลิฟต์ที่จะขึ้นให้
  • ระบบเพิ่มประสิทธิภาพสามารถรู้ปลายทางของผู้โดยสารแต่ละคนทั้งหมดก่อนลิฟต์มาถึง แต่โดยทั่วไปเวลารอจะยาวกว่าวิธีปุ่มขึ้น/ลงแบบดั้งเดิม
  • มีข้อยกเว้นที่ระบบคีออสก์ได้เปรียบ เช่น อาคารที่สูงมากและมีลิฟต์ 8 คันขึ้นไป ต่อกลุ่ม
  • สาเหตุหลักของประสิทธิภาพที่ลดลงคือ ความแข็งตัว ของการจัดคิว
    • วิธีดั้งเดิมสามารถปรับเส้นทางลิฟต์และการจัดสรรผู้โดยสารให้เหมาะสมใหม่ได้ทุก 5 วินาที
    • ใน Destination Dispatch ผู้โดยสารต้องขึ้นลิฟต์คันที่ถูกกำหนดไว้ตั้งแต่แรก
    • แม้สภาพการเดินลิฟต์จะเปลี่ยนไปหลังเรียก 30 วินาที ก็ไม่สามารถเปลี่ยนลิฟต์ที่กำหนดไว้ได้อย่างยืดหยุ่น
  • ความเสียหายจาก การสูญเสียความยืดหยุ่นในการจัดสรรใหม่ มากกว่าประโยชน์ของข้อมูลเพิ่มเติมเรื่องปลายทาง

รายการปรับแต่งและขอบเขตของการจำลอง

  • ในการจำลองทั้งหมด สามารถปรับจำนวนชั้น จำนวนลิฟต์ และปริมาณผู้โดยสารต่อนาที พร้อมตรวจสอบสัดส่วนการมาถึงภายใน 30 วินาทีและ 90 วินาทีได้
  • อัลกอริทึมลิฟต์จริงมีปัจจัยที่ต้องพิจารณามากกว่านี้ และขอบเขตที่กล่าวถึงที่นี่เป็นเพียงส่วนหนึ่งของทั้งหมด
  • การกดปุ่มเรียกจะถูกส่งต่อไป แต่เพราะลิฟต์คำนวณเงื่อนไขการเดินหลายอย่างร่วมกัน จึงอาจไม่ได้มาถึงทันที

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • ตลอดราวครึ่งหนึ่งของครึ่งศตวรรษที่ผ่านมา ลิฟต์ถูก ควบคุมด้วยรีเลย์ล้วน ๆ โดยไม่มีคอมพิวเตอร์ และอัลกอริทึมแบบนี้ก็ถูกนำไปใช้เป็นวงจรลอจิกที่เดินสายไว้
    รายละเอียดที่น่าสนใจ เช่น ผังวงจร ดูได้จากสิทธิบัตรเก่า ๆ ของ Otis

  • ตอนเรียนวิทยาการคอมพิวเตอร์ในมัธยมปลาย เคยทำ ซิมูเลชันอัลกอริทึมลิฟต์ หลายแบบเป็นโปรเจกต์ส่วนตัว
    ฮาร์ดดิสก์แบบจานหมุนคล้ายกับลิฟต์ที่ยาวมาก ๆ พันรอบสปินเดิลแทนที่จะเป็นแนวดิ่ง และ SCAN ก็เป็นอัลกอริทึมจัดตารางดิสก์จริง ๆ: https://en.wikipedia.org/wiki/Elevator_algorithm

    • ตอนมหาวิทยาลัยก็ทำโปรเจกต์คล้าย ๆ กันโดยใช้ ไมโครคอนโทรลเลอร์กับ LED และอย่างอื่น สนุกมาก

  • สงสัยว่าผลที่บอกว่า destination dispatch โดยรวมแย่ เป็นเพราะตั้งชั้นปลายทางแบบสุ่มหรือเปล่า
    ในอาคารจริง คนส่วนใหญ่ที่ไม่ได้อยู่ชั้นล่างมักจะลงไปชั้นล่าง และที่ชั้นล่าง คนที่ทำงานชั้นเดียวกันมักออกไปกินข้าวเที่ยงพร้อมกันแล้วกลับมาชั้นเดียวกันพร้อมกัน ระบบ destination dispatch สามารถจัดกลุ่มคนจำนวนมากที่มีปลายทางเดียวกันให้ขึ้นด้วยกันได้ จึงเหมาะกับแพตเทิร์นแบบนี้

    • สำหรับโรงแรมยิ่งเป็นสมมติฐานที่ไม่ค่อยเข้ากัน ตอนเช้าไม่ได้มีแค่การขึ้นจากล็อบบี้ไปห้องพัก แต่ยังมีการลงไปกินอาหารเช้า แล้วกลับขึ้นไป แล้วลงมาอีก จึงเกิด การสัญจรสองทิศทาง
      ระบบคีออสก์ของโรงแรมบางแห่งยังเปลี่ยนอินเทอร์เฟซผู้ใช้ตามช่วงแออัดของมื้อเช้าด้วย
    • เรือสำราญที่ใช้ destination dispatch ก็สบายกว่ามาก เรือที่ใช้อัลกอริทึมแบบเก่ารอช่วงแออัดทรมาน แต่ก็ทำให้ใช้บันไดมากขึ้น
    • คนที่อยู่ชั้นบนมีโอกาสกลับไปชั้นล่างมากกว่าจะขึ้นหรือลงไปแค่หนึ่งสองชั้น แต่ผู้โดยสารที่รอในซิมูเลชันดูเหมือนจะไม่ได้สะท้อนเรื่องนี้ดีนัก
      ผลของการรวมกลุ่ม ของคนที่ออกไปกินข้าวเที่ยงหรือกลับมาก็มีอยู่จริง และเห็นชัดกว่าช่วงเช้าหรือเย็นในตอนกลางวัน
    • ผมมองว่าแพตเทิร์นที่กลุ่มใหญ่จากชั้นล่างเดินทางไปปลายทางเดียวกัน เป็นหนึ่งในเหตุผลหลักที่ destination dispatch ดีกว่า
      มีบทความที่บอกว่า หลังจากสำนักงานหรือโรงแรมเปลี่ยนมาใช้วิธีนี้ เวลารอคอยลดลงมาก ด้วย
    • สงสัยว่าเป็นเพราะเกณฑ์ประเมินคือเวลารอ ไม่ใช่เวลาเดินทางหรือเปล่า destination dispatch ช่วยลดการหยุดที่ไม่จำเป็นระหว่างทาง
      อาคารใหม่ที่เพิ่งไปมาก็ใช้วิธีนี้ สมัยมหาวิทยาลัย รูมเมตที่เรียนวิศวกรรมไฟฟ้าทำวงจรลิฟต์บนเบรดบอร์ด โดยต่อปุ่มเรียก มอเตอร์ และแผ่นใสทรงกลมที่มีสี่เหลี่ยมสีดำสำหรับตรวจจับตำแหน่ง น่าจะเป็นอัลกอริทึมง่าย ๆ

  • ถ้าเพิ่งรู้จักการจัดตารางลิฟต์ ขอแนะนำเกมนี้: https://play.elevatorsaga.com/

    • สมมติฐานเรียบง่าย แต่ยิ่งเลเวลสูงก็ยิ่งยากแบบน่าพอใจ แถมยังมี ความขัดข้องแบบสุ่ม เล็กน้อย ทำให้ท้าทายขึ้น อยากให้มีเกมแบบนี้มากกว่านี้
    • ดูทำออกมาได้ดีมาก แต่ถึงอย่างนั้นก็ยังชอบ https://en.wikipedia.org/wiki/Elevator_Action มากกว่า
    • ยอดเยี่ยม แต่สำหรับผม เกมจัดตารางลิฟต์ ที่ดีที่สุดคือ SimTower
    • ทุกครั้งที่รอลิฟต์ในโรงแรมที่จัดงานประชุม ก็ทำให้นึกกลับไปเล่นเกมนี้อีก
    • เคยสงสัยมาตลอดว่าเกมที่ให้เขียนโปรแกรมตัวจัดตารางลิฟต์เองจะสนุกไหม และคิดว่าคงไม่มีใครทำ ดีใจที่คิดผิด

  • ตอนพัฒนา Sky Lobby เกมควบคุมและอัตโนมัติลิฟต์สำหรับ iOS/Android ได้คิดเรื่องนี้เยอะมาก
    เลือกใช้อัลกอริทึมคล้าย LOOK ที่ใกล้เคียงกับการเคลื่อนที่ที่ผู้เล่นคาดหวังที่สุด แต่เมื่อการเลือกกำกวม จะให้ความสำคัญกับชั้นที่รอนาน เพื่อปรับปรุง p90 ซึ่งสำคัญในเกม อย่างไรก็ตาม เมื่อเพิ่มลิฟต์สองชั้นที่ให้บริการสองชั้นพร้อมกัน ชั้นเปลี่ยนลิฟต์ระหว่างปล่องลิฟต์ และปล่องลิฟต์ด่วนเข้าไป อัลกอริทึมที่เหมาะที่สุดหรือเข้าใจง่ายที่สุดก็ยิ่งไม่ชัดเจนมากขึ้น เนื่องจากเป็นเกมไม่ใช่ระบบจริง จึงหา heuristic ที่ดีพอ และให้ผู้เล่น override แผนการเดินรถเองได้เมื่อไม่ชอบ ผลคือส่วนใหญ่พอใจ

  • ทุกครั้งที่รอลิฟต์ มักคิดว่างานสร้างอัลกอริทึมที่ลดเวลารอจนผู้โดยสารขึ้นลิฟต์และถึงปลายทางให้น้อยที่สุดคงปวดหัวแค่ไหน
    บางครั้งก็อดคิดไม่ได้ว่าคนที่ทำระบบพวกนี้อาจเป็นพวกซาดิสม์ชั่วร้ายที่จงใจให้รอนานขึ้น

    • อยากให้ลิฟต์คำนึงถึง น้ำหนักบรรทุก ด้วย
      เช้าวันถัดจากงานประชุมใหญ่ ทุกคนกำลังจะลงไปข้างล่าง แต่ลิฟต์ที่เต็มแล้วก็ยังจอดทุกชั้นแบบเป๊ะ ๆ ถ้าลิฟต์จุ 10 คนได้รับผู้โดยสารจากการเรียกมาแล้ว 10 ชั้น ก็ควรตรงไปชั้นล่างและประหยัดเวลา 5 นาที แทนที่จะหยุดทุกชั้นให้เกิดเหตุการณ์ “ไม่มีที่แล้วครับ/ค่ะ รอคันถัดไป” ซ้ำ ๆ โดยเฉพาะถ้าคนที่เคลื่อนไหวลำบากบนชั้น 2 ต้องไปขึ้นเครื่องบิน นั่นเป็นปัญหาร้ายแรง
    • เคยพัฒนา ซอฟต์แวร์อินทิเกรชันภายนอก ที่เชื่อมลิฟต์กับอุปกรณ์อื่นหลายครั้ง
      เมื่อเห็นตำแหน่งและการเคลื่อนไหวของลิฟต์ทั้งหมด จะพบว่าตารางแน่นจนน่าทึ่ง ที่ล็อบบี้การรอดูเหมือนไม่สิ้นสุด แต่ในมุมมองการจัดคิว กิจกรรมดำเนินต่อเนื่องแทบไม่หยุด และในเวลาที่มีคนใช้อาคาร ลิฟต์แทบไม่ได้ว่างเลย แค่นั่งดูแผงสถานะก็น่าสนใจแล้ว อีกอย่าง ถ้าช่างซ่อมลิฟต์บอกว่า “เจอกันเช้าตรู่” โดยมากหมายถึงประมาณตี 4 และเขาพยายามทำงานให้เสร็จก่อนคนเริ่มมาทำงาน
    • ไม่ใช่เพราะซอฟต์แวร์จัดตารางลิฟต์ทึ่ม แต่เพราะมีการคิดเรื่องนี้ไว้อย่างมหาศาลแล้ว
      ลิฟต์มีราคาแพง และเจ้าของอาคารก็ไม่ลงทุนเกินจำเป็นตามอารมณ์ ดังนั้นโดยทั่วไปจึงติดตั้ง จำนวนลิฟต์ขั้นต่ำ ที่พอรองรับความต้องการที่คาดไว้ หรือบางครั้งน้อยกว่านั้นด้วยซ้ำ
    • นอกจากเวลารอแล้ว อาจกำลังปรับฟังก์ชันวัตถุประสงค์อย่าง การสึกหรอและการใช้พลังงาน ให้เหมาะสมอยู่ก็ได้

  • มีลิฟต์ 4 ตัว โดยแต่ละตัวแสดงชั้นที่จะหยุดถัดไปไว้ด้านบน และระหว่างที่รอก็ยังเปลี่ยน การจับคู่ระหว่างลิฟต์กับชั้น พร้อมแจ้งด้วยเสียง ดูเหมือนเป็นฟีเจอร์ที่ทำมาเพื่อให้จัดคิวได้เหมาะที่สุด

  • ปัญหาใหญ่ที่สุดของลิฟต์ไม่ใช่อัลกอริทึม แต่คือคนที่ไม่เข้าใจแนวคิดการกดปุ่มเรียกขึ้น/ลงให้ตรงกับทิศทางปลายทาง
    ถ้ากดทั้งสองปุ่มเพราะคิดว่า “จะมาเร็วขึ้น” ครึ่งหนึ่งก็จะได้ไปทิศตรงข้ามก่อน และยังเพิ่มการหยุดที่ไม่จำเป็นให้คนที่อยู่ในลิฟต์แล้วด้วย

    • จริง ๆ แล้วเหมือนไม่เคยเห็นคนทำแบบนั้นเลย
    • ในสถานการณ์แบบนี้ แทนที่จะสรุปว่าคนไม่เข้าใจ ลองคิดย้อนกลับว่าถ้าเขาเข้าใจอยู่แล้ว ทำไมมันถึงสมเหตุสมผล บางครั้งคำตอบก็จะออกมา
      อาจคล้ายกับ จิตวิทยาของแถบโหลดปลอม ถ้ารอโดยไม่รู้เวลามาถึงก็จะเบื่อและหงุดหงิด แต่ถ้าได้ขึ้นลิฟต์ที่กำลังเคลื่อนที่ แม้จะไปทิศตรงข้าม ก็รู้สึกว่ากำลังคืบหน้า สุดท้ายแม้จะใช้เวลานานกว่า แต่การมีอะไรเกิดขึ้นก็อึดอัดน้อยกว่า
    • พอประตูเปิด ก็มีคนถามคนข้างในว่าขึ้นหรือลง ทั้งที่มี ลูกศรบอกทิศทาง อยู่ตรงหน้า
    • ถ้าจะลงจากชั้นล่าง ๆ ในช่วงเช็กเอาต์แออัด ลิฟต์ขาลงอาจเต็มตลอด
      ในทางกลับกัน ถ้าความต้องการขาขึ้นมีน้อย การ ขึ้นไปก่อนแล้ววนกลับลงมาจนสุด อาจเป็นกลยุทธ์ที่สมเหตุสมผลกว่าการยืนหวังว่าจะมีที่ว่าง
    • ในอาคารแออัดช่วงพีก ความจุลิฟต์ไม่เพียงพอ เวลาจะไปชั้นล่าง การขึ้นไปก่อนแล้วค่อยลงมาอาจช่วยลดผลลัพธ์ที่แย่ที่สุด หรือโดยเฉลี่ยเร็วกว่า
      ในกรณีนี้ การกดทั้งปุ่มขึ้นและลง ไม่ได้โง่ แต่มีเหตุผล

  • นอกเหนือจากประสิทธิภาพของอัลกอริทึมแล้ว จิตวิทยาการรับรู้เวลารอ ของผู้คนก็สำคัญ
    ถ้ารอเฉย ๆ โดยไม่ทำอะไรจะหงุดหงิดมาก แต่ถ้าใช้เวลาเท่ากันไปทำบางอย่าง จะรู้สึกว่ามีความคืบหน้าและบ่นน้อยลง ที่สนามบินก็มีกรณีว่า แทนที่จะให้ผู้โดยสารเดินตรงจากเกตไปสายพานรับกระเป๋าแล้วรอจนกระเป๋าใบแรกออกมา เขาจงใจทำทางเดินให้ยาวและอ้อมขึ้น แม้เวลารวมเท่าเดิม แต่ผู้โดยสารพอใจมากกว่า

  • ในอัลกอริทึมลิฟต์หลายแบบ มักไม่ค่อยพูดถึง การสึกหรอและต้นทุนบำรุงรักษา โดยรวม
    การเคลื่อนไหวมากขึ้นอาจทำให้ต้องเปลี่ยนน้ำมันไฮดรอลิกเร็วขึ้นและชิ้นส่วนเสียเร็วขึ้น อัลกอริทึมที่มีประสิทธิภาพอาจจัดตำแหน่งล่วงหน้าตามช่วงเวลาหรือตำแหน่งของลิฟต์ตัวอื่น เช่น ถ้าตัวหนึ่งลงมา ก็อาจส่งอีกตัวหนึ่งขึ้นไป อัลกอริทึมที่อิงสัญญาณความต้องการจะลดการเคลื่อนไหวแบบนี้ให้เหลือน้อยที่สุด ความสมดุลระหว่างการเพิ่มเวลารอเพื่อให้ลดการบำรุงรักษาเป็นเรื่องสำคัญ และเจ้าของอาคารที่เป็นคนจ่ายค่าใช้จ่ายอาจไม่ได้ให้ความสำคัญกับเวลารอของผู้โดยสารมากเท่านั้น

    • ระหว่างการบำรุงรักษาต้องนำลิฟต์ตัวหนึ่งออกจากการให้บริการ ดังนั้น เวลารอเฉลี่ย ในช่วงนั้นก็เพิ่มขึ้นด้วย