ข้ามไปที่เนื้อหา

S4 · run งานผ่าน dashboard และ queue

▶ clip: https://youtu.be/yFDGtFjdeOA

จบบทนี้แล้วทำได้:

  • เปิด dashboard ของ kit และรู้ว่า tab ไหนใช้ทำอะไร
  • อธิบายได้ว่าทำไมแก้ YAML หลังเข้า queue แล้วงานที่รออยู่ไม่เปลี่ยน
  • บอกได้ว่างานไหนจะถูกข้าม งานไหนจะถูก run ใหม่
  • ไม่เชื่อข้อความ "ล้มเหลว · ไม่มีรายงาน" จนกว่าจะ check tester log
  • ตัดสินจาก equity curve ระหว่าง run ว่าเส้นแบบไหนหยุดได้ แบบไหนห้ามหยุด

ต้องมีก่อน: จบ S3 และมี config จาก lab S3 ที่ dry-run ผ่านแล้ว

1 · dashboard สี่ tab

S4-1

งาน backtest ทั้งหมดในคอร์สนี้สั่งผ่าน dashboard

เปิด: double-click 2-เปิดหน้าคุม.bat ใน folder kit แล้วเปิด browser ไปที่ http://127.0.0.1:8770 (หน้าต่างดำที่ขึ้นมาต้องเปิดค้างไว้ระหว่างใช้)

dashboard ของ kit มีสี่ tab (ใน clip พูดว่าสาม — tab สถานะกลยุทธ์ เพิ่มเข้ามาทีหลัง)

tab ใช้ทำอะไร ใช้ใน Standard
ระบบ backtest card MT5 ต่อ broker · สั่ง run · queue งาน · การตั้งค่า ✓
สถานะกลยุทธ์ ดูว่า EA แต่ละตัวไปถึงขั้นไหนของงานวิจัยแล้ว ผ่านหรือตก · อ่านอย่างเดียว (อ่านจาก research\status.yaml) ✓
เครื่องมือวิเคราะห์ เครื่องมืออ่านผล ✓
skill คำอธิบาย skill ของ Claude Code —

tab ขึ้นบัญชีใหม่บน VPS มีเฉพาะใน repo ของผู้สอน ไม่มีใน kit

ภาพบนจอเป็นภาพจาก kit จริง บัญชี Exness-Demo และ ICMarkets-Demo ในภาพเป็นตัวอย่างที่ใส่ไว้เพื่อถ่ายภาพ ของคุณจะเห็นบัญชีที่ตัวเองเพิ่ม

สองเรื่องที่ต้องรู้ก่อนกดอะไร

  1. dashboard แก้ file config ตัวที่เลือกอยู่ตรง ๆ ไม่ได้สร้างสำเนา แก้ค่าในหน้าเว็บ = แก้ file .yaml นั้นทันที ถ้าอยากเก็บค่าเดิมไว้ ให้ copy file ก่อน
  2. เครื่องมือทุกตัวมีคำอธิบาย ว่าใช้ทำไม ใช้ยังไง และอ่านผลยังไง ให้อ่านก่อนกดทุกครั้ง (คู่มือทุกหน้าทุก field อยู่ที่ docs\dashboard-guide.md ใน kit และในหน้า dashboard ทีละ tab ทีละปุ่ม)

2 · queue แช่ config ทั้งก้อน

S4-2

config.yaml  ──กดเพิ่มงาน = คัดลอกทั้งก้อน──▶  queue.json "cfg"  ──▶  run → MT5
(file ที่แก้ได้ตลอด)                            (ค่าที่จะ run จริง)       (อ่านจาก queue)

ตอนกดเพิ่มงานเข้า queue ระบบไม่ได้จำแค่ชื่อ file config แต่คัดลอก config ทั้งก้อนเก็บไว้ใน bt\queue.json ที่ key "cfg" ของงานนั้น ตอน run ระบบอ่านค่าจาก cfg ไม่ใช่จาก file YAML

ผลคือ ถ้าแก้ YAML ทีหลัง (เช่น date_from) งานที่รออยู่ใน queue จะไม่เปลี่ยนตาม การแก้ไปถึงแค่ config.yaml ไม่ถึงงานที่รออยู่ ถ้าต้องการค่าใหม่ ต้องลบงานเดิมแล้วเพิ่มเข้า queue ใหม่

สถานะของงาน:

รอ  →  กำลัง run  →  เสร็จ / ล้มเหลว

case จริง: รายงาน prop firm หกใบ run บนช่วงมกราคม 2025 ถึงกรกฎาคม 2026 ที่ leverage 1:500 ทั้งที่หัว file เขียนว่าครึ่งแรกปี 2026 ที่ 1:100 — ค่าที่ run จริงคือค่าที่ถูกแช่ไว้ตอนเข้า queue ไม่ใช่ค่าที่เห็นใน file ตอนหลัง

ล้าง queue แล้วเลข id เริ่มนับใหม่ เลข id ของงานใหม่ = id มากสุดที่มีอยู่ + 1 ถ้า queue ว่าง งานถัดไปจึงกลับไปเป็น 1 ใช้ id อ้างถึงงานข้ามวันไม่ได้

ดังนั้นให้เก็บ config เป็น file เสมอ อย่าพึ่ง queue เป็นที่เก็บ

3 · เมื่อไรงานถูกข้าม เมื่อไร run ใหม่

S4-3

ระบบไม่ได้ run ทุกงานซ้ำทุกครั้ง

มีรายงานแล้ว? .ini เดิมเทียบกับ config ผล
ยังไม่มี — run
มี ตรงกันครบ 11 key ข้าม (skip_existing)
มี เปลี่ยนวัน · ทุน · leverage run ใหม่เอง
แถว fail --retry-failed (_lastrun.json) run เฉพาะแถวนั้น

11 key ที่ระบบเทียบ (จาก code bt/core/tester.py):

Symbol · Period · Model · ExecutionMode · FromDate · ToDate ·
Deposit · Currency · Leverage · ExpertParameters · Visual

ทำไมต้องเทียบ .ini ด้วย ไม่ใช่ดูแค่ว่ามี file รายงานไหม: ถ้าดูแค่ว่ามีรายงาน พอเปลี่ยนช่วงวันที่แล้วสั่ง run ใหม่ งานเดิมทุกตัวจะถูกข้าม ได้ตารางผลที่ปนกันหลายเงื่อนไขโดยไม่มีอะไรบอก

run เฉพาะงานที่ล้มเหลวในรอบก่อน ใช้ตัวเลือก --retry-failed ซึ่งอ่านแถวที่ fail จาก _lastrun.json (ใน dashboard คือปุ่ม "run ซ้ำที่ล้มเหลว")

งานพร้อมกันถูกจำกัดด้วย RAM ของเครื่อง งานหนึ่งใช้ประมาณ 3.8 GB · kit README ระบุเครื่องขั้นต่ำ RAM 16 GB และกันไว้ให้ระบบ 8 GB จึง run ได้ทีละงาน ใน repo ของผู้สอนมีเครื่องมือดูเพดานงานพร้อมกันของเครื่อง แต่ใน kit ไม่มีเครื่องมือนี้

4 · "ไม่มีรายงาน" ไม่ได้แปลว่า test ล้ม

S4-4

ข้อความว่างานล้มเหลวเพราะไม่มีรายงาน ไม่ได้แปลว่า test ล้มเสมอไป สาเหตุที่เจอจริง

อาการ สาเหตุ ทางแก้
queue ช้าผิดปกติ ได้ผลน้อยกว่าที่ควร terminal ที่ใช้ backtest เปิดค้างอยู่ งานต้องรอให้ว่าง ปิด terminal ก่อนเข้า queue
งานแรกไม่เริ่ม test ไม่มี error MT5 LiveUpdate ยึดงานแรกไป update ตัวเอง ระบบยิงซ้ำบน build ใหม่ · ดู log ยืนยัน
ขึ้น "ล้มเหลว · ไม่มีรายงาน" ตัว run เคยเลิกรอก่อน MT5 boot เสร็จ check tester log ก่อนเชื่อ

(บนจอเขียนว่า terminal WF-* ซึ่งเป็นชื่อ terminal ในเครื่องผู้สอน ใน kit คือ terminal ใน mt5\MT5_<ชื่อ>\)

ตัวเลขจาก case จริง

  • งานที่ run สำเร็จ 54 นาที ถูกนับเป็นล้มเหลวไปสี่ครั้ง เพราะตัว run เลิกรอก่อน MT5 boot เสร็จ
  • เปิด terminal ค้างไว้ ทำให้งานละ 10 ชั่วโมง ได้ผลแค่สองใบใน 20 ชั่วโมง

tester log อยู่ที่ไหน: journal ของรอบที่ run เสร็จถูกเก็บเป็น file .log ข้างรายงาน (S3) ส่วน log ของ tester ใน terminal อยู่ที่ mt5\MT5_<ชื่อ>\Tester\logs\ ชื่อ file เป็นวันที่ (YYYYMMDD.log)

5 · equity curve ดิ่ง = หยุดทันที

S4-5

ระหว่าง run ให้ดู equity curve ใน tester (ภาพบนจอเป็นภาพสมมติประกอบการสอน)

เส้นที่เห็น ตัดสิน ทำไม
ลงต่อเนื่องหลายเดือน ปิดได้ ไม่มีชุดตัวเลขไหนกู้กลับมาเป็นบวก
ขึ้นเรียบสวย ห้ามอ่านว่าผ่าน EA แบบ grid/martingale หน้าตาเป็นแบบนี้ก่อนตกหน้าผา ต้องดูจนจบ
แกว่งรอบเส้นเริ่ม ห้ามปิด ข้อมูลยังไม่พอ
ลงแล้วเด้ง ซ้ำ ๆ ห้ามปิด อาจเป็นตะกร้าที่ยังไม่ปิด ต้องวัดที่ระดับตะกร้า

case TripleEngineEA: ทุนจาก 10,191 ลงเหลือ 8,700 ในเจ็ดเดือนแรก รอบนี้ยาวประมาณ 15 ชั่วโมง แต่รู้คำตอบตั้งแต่ชั่วโมงที่สอง

เวลาหยุด ทำสองอย่าง

  1. กด Stop แล้วต้องปิด terminal ด้วย — ถ้ากดแค่ Stop terminal ยังเปิดอยู่ ระบบยังรอ file รายงานต่อไป queue จะค้างจนครบ run_timeout_sec (ใน kit config คือ 7200 วินาที) ปิด terminal แล้วระบบจึงนับว่างานนั้นจบและขึ้นงานถัดไปทันที
  2. จดว่า "ตกด้วยตา" ไม่ใช่ตัวเลขที่วัดแล้ว — ไม่มีรายงาน = ไม่มี E[R] ไม่มี CI ไม่มี n ให้จดสิ่งที่เห็นบนจอแทน คือช่วงวันที่ และทุนต้น → ทุนตอนปิด

Lab · พิสูจน์ว่า queue แช่ config

S4-L

เป้าหมาย: เห็นกับตาว่าค่าที่จะ run จริงอยู่ใน cfg ของ queue.json ไม่ใช่ใน file YAML

lab นี้ทำผ่าน dashboard เท่านั้น เพราะไม่มีคำสั่ง command line สำหรับเพิ่มงานเข้า queue

ขั้นที่ 0 double-click 2-เปิดหน้าคุม.bat → http://127.0.0.1:8770 · check ก่อนว่าไม่มีงาน "กำลัง run" และ queue ไม่ได้เดินอยู่ ไม่อย่างนั้นงานที่เพิ่มจะถูกหยิบไป run ทันที

ขั้นที่ 1 tab ระบบ backtest → card queue งาน → ช่อง file config เลือก config ที่ทำไว้ใน lab S3

ขั้นที่ 2 กด + เพิ่มงานนี้เข้า queue → จะเห็นแถวใหม่สถานะ รอ และมี H1 อยู่ใน label ของแถว

ขั้นที่ 3 ไปที่ card การตั้งค่า → กด แก้ YAML ดิบ → เปลี่ยน period: H1 เป็น period: M30 → กด บันทึก YAML

ขั้นที่ 4 ดูแถวเดิมใน queue ยังเขียน H1 · เปิด file bt\queue.json หางานที่ id นั้น ใน "cfg" ยังเป็น

"period": "H1"

ขั้นที่ 5 ลบงานด้วยปุ่ม ✕ แล้วแก้ period กลับเป็น H1 · ห้ามกด "เริ่ม queue"

ด่านของ lab: ชี้ได้ว่าค่าที่จะ run จริงอยู่ใน cfg ของ queue.json ไม่ใช่ใน file YAML

ข้อสังเกต:

  • จำนวน broker ใน label ขึ้นกับจำนวนบัญชีที่คุณเปิดใช้
  • ถ้ากดเพิ่มงานแล้วขึ้นว่ายังไม่มีบัญชี broker แปลว่า config ยังไม่มีบัญชีที่เปิดใช้ ต้องเพิ่มบัญชี demo ก่อน (M0-LAB)
เฉลย — ทำเองก่อนแล้วค่อยเปิด

หลังขั้นที่ 3 มีค่า period สองที่ที่ไม่ตรงกัน

ที่ ค่า ใช้ตอนไหน
file YAML ของ config M30 ตอนกดเพิ่มงานครั้งถัดไป
bt\queue.json → งานนั้น → "cfg" H1 ตอนงานนี้ถูก run

ถ้ากดเริ่ม queue ตอนนั้น งานจะ run ด้วย H1 แม้ file จะเป็น M30 แล้ว นี่คือกลไกเดียวกับ case prop firm หกใบในหัวข้อ 2 · ทางแก้เมื่อเห็นค่าผิดหลังเข้า queue คือลบงานแล้วเพิ่มใหม่ ไม่ใช่แก้ YAML

จุดที่มักพลาด

พลาด ผลที่ตามมา ทางกัน
แก้ค่าใน dashboard โดยคิดว่าเป็นสำเนา file config เดิมถูกแก้ทับ copy file ก่อนแก้ ถ้าอยากเก็บค่าเดิม
แก้ YAML หลังเข้า queue งานที่รออยู่ run ด้วยค่าเก่า ลบงานแล้วเข้า queue ใหม่
ใช้ queue เป็นที่เก็บ config ล้าง queue แล้ว id เริ่มใหม่ ค่าเดิมหาย เก็บ config เป็น file เสมอ
เปิด terminal ค้างไว้ระหว่าง queue เดิน งานช้า ได้ผลน้อย (2 ใบใน 20 ชม.) ปิด terminal ก่อนเข้า queue
เชื่อ "ล้มเหลว · ไม่มีรายงาน" ทันที ทิ้งงานที่จริง ๆ run สำเร็จ check tester log ก่อน
เห็นเส้นขึ้นเรียบแล้วกด Stop จดว่าผ่าน พลาด grid/martingale ก่อนหน้าผา ดูจนจบ
ปิดงานที่เส้นแกว่งหรือลงแล้วเด้ง ตัดสินจากข้อมูลไม่พอ ปล่อยจนจบ
กดแค่ Stop ไม่ปิด terminal queue ค้างจนครบ run_timeout_sec ปิด terminal ด้วย
จดผลของงานที่หยุดเป็นตัวเลข ตัวเลขที่ไม่ได้วัดปนกับที่วัดแล้ว จดว่า "ตกด้วยตา" + ช่วงวันที่ + ทุนต้น → ทุนตอนปิด

ทวนท้ายบท

S4-Q

  1. เข้า queue ไปแล้วเพิ่งเห็นว่า date_from ผิด จึงแก้ใน YAML แล้วบันทึก งานที่รออยู่จะ run ด้วยวันใหม่ไหม
  2. equity curve ขึ้นเรียบสวยตั้งแต่ต้น กด Stop แล้วจดว่าผ่านได้ไหม และเส้นแบบไหนที่ปิดงานได้
  3. ระบบแจ้งว่างานล้มเหลว ไม่มีรายงาน สรุปได้เลยไหมว่า test ล้ม
เฉลย
  1. ไม่ queue เก็บ config ทั้งก้อนไว้ใน cfg แล้ว ต้องลบงานแล้วเข้า queue ใหม่
  2. ไม่ได้ เส้นขึ้นเรียบสวยห้ามอ่านว่าผ่าน ปิดได้เฉพาะเส้นที่ลงต่อเนื่องหลายเดือน และปิดแล้วต้องปิด terminal ด้วย พร้อมจดว่า "ตกด้วยตา"
  3. ไม่ได้ ต้อง check tester log ก่อน เพราะตัว run เคยเลิกรอก่อน MT5 boot เสร็จ จนงานที่สำเร็จถูกนับเป็นล้มเหลวมาแล้ว