jihoson/The-Ouroboros
1
0
Fork 0
Code Issues Pull Requests Actions 14 Packages Projects Releases Wiki Activity

Implement Latency Control - Criticality-based prioritization #21

New Issue
Closed
opened 2026-02-04 16:12:07 +09:00 by agentson · 0 comments
agentson commented 2026-02-04 16:12:07 +09:00
Collaborator
Copy Link

Goal

Pillar 1: 속도와 시의성의 최적화

Implement urgency-based response system to react faster in critical market situations.

Background

모든 상황을 똑같이 처리하지 말고, 긴급도(Criticality)에 따라 대응 속도를 달리해야 함.

Tasks

1. Criticality Levels

Define 4 levels:

  • CRITICAL: Market crash/spike, circuit breaker risk (< 5s response)
  • HIGH: High volatility on tracked stocks (< 30s response)
  • NORMAL: Regular trading conditions (< 60s response)
  • LOW: Market closed, low volatility (batch processing)

2. Priority Queue

  • Implement priority-based task queue
  • Critical decisions bypass normal queue
  • Timeout enforcement per level
  • Queue metrics and monitoring

3. Volatility-based Triggers

  • Auto-elevate to CRITICAL when:
    • P&L < -2.5% (near circuit breaker)
    • Stock moves >5% in 1 minute
    • Volume surge >10x average
  • Integration with Volatility Hunter

4. Fast-path Execution

  • Simplified decision flow for CRITICAL
  • Pre-warmed connections
  • Cached market data
  • Parallel API calls

5. Latency Monitoring

  • Track decision latency per criticality
  • Alert on SLA violations
  • Performance dashboard

Implementation Files

  • src/core/criticality.py - Criticality definitions
  • src/core/priority_queue.py - Priority queue implementation
  • src/main.py - Integration with trading loop
  • tests/test_latency_control.py - Tests

Acceptance Criteria

  • 4 criticality levels implemented
  • Priority queue with timeout enforcement
  • Auto-elevation based on market conditions
  • CRITICAL decisions < 5s latency (p95)
  • Latency monitoring dashboard
  • Tests achieve ≥80% coverage

Priority

MEDIUM - Depends on Volatility Hunter for triggers

Related

Pillar 1: Latency Control
Depends on: Volatility Hunter (for triggers)

## Goal Pillar 1: 속도와 시의성의 최적화 Implement urgency-based response system to react faster in critical market situations. ## Background 모든 상황을 똑같이 처리하지 말고, 긴급도(Criticality)에 따라 대응 속도를 달리해야 함. ## Tasks ### 1. Criticality Levels Define 4 levels: - **CRITICAL**: Market crash/spike, circuit breaker risk (< 5s response) - **HIGH**: High volatility on tracked stocks (< 30s response) - **NORMAL**: Regular trading conditions (< 60s response) - **LOW**: Market closed, low volatility (batch processing) ### 2. Priority Queue - Implement priority-based task queue - Critical decisions bypass normal queue - Timeout enforcement per level - Queue metrics and monitoring ### 3. Volatility-based Triggers - Auto-elevate to CRITICAL when: - P&L < -2.5% (near circuit breaker) - Stock moves >5% in 1 minute - Volume surge >10x average - Integration with Volatility Hunter ### 4. Fast-path Execution - Simplified decision flow for CRITICAL - Pre-warmed connections - Cached market data - Parallel API calls ### 5. Latency Monitoring - Track decision latency per criticality - Alert on SLA violations - Performance dashboard ## Implementation Files - `src/core/criticality.py` - Criticality definitions - `src/core/priority_queue.py` - Priority queue implementation - `src/main.py` - Integration with trading loop - `tests/test_latency_control.py` - Tests ## Acceptance Criteria - [ ] 4 criticality levels implemented - [ ] Priority queue with timeout enforcement - [ ] Auto-elevation based on market conditions - [ ] CRITICAL decisions < 5s latency (p95) - [ ] Latency monitoring dashboard - [ ] Tests achieve ≥80% coverage ## Priority **MEDIUM** - Depends on Volatility Hunter for triggers ## Related Pillar 1: Latency Control Depends on: Volatility Hunter (for triggers)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agentson jihoson
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jihoson/The-Ouroboros#21
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?