clockelliptic / clockelliptic/open-av-latency-optimization-framework

Future enhancements & topics

Open
#11 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

### 1. **Future Enhancements to Leave Out for Now**

These additions will make the paper stronger in later versions but are too complex to tackle right now. We’ll save them for future iterations once we’ve established the baseline.

#### 1. **Hold Off on Stochastic Latency Models (G/G/1)**
- **Why**: G/G/1 models allow for handling complex, unpredictable arrival rates, but we don’t need that level of detail yet.
- **Goal**: Mention this as a future enhancement for cases where system load is less predictable.

#### 2. **Skip Dynamic Reconfiguration for Now**
- **Why**: Adjusting settings based on the environment (like traffic conditions) adds a lot of complexity. Static configurations work fine for our current latency focus.
- **Goal**: Note this for future research when we expand into more adaptive, real-time adjustments.

#### 3. **Defer Reinforcement Learning (RL) for Failure Prevention**
- **Why**: RL is a great next step but requires complex training and real-time learning. LSTM is more manageable for now.
- **Goal**: Leave RL as a suggestion for future iterations when we’re ready for a self-learning system.

#### 4. **Don’t Include Network Latency or Offloading Yet**
- **Why**: Right now, we’re focusing on **on-vehicle** latency. Cloud or edge offloading complicates things with network delays, which aren’t central to our current goal.
- **Goal**: Indicate that network latency will become important as we expand to cloud processing.

#### 5. **Hold Off on Graceful Degradation Policies**
- **Why**: Graceful degradation keeps the system running under heavy load, but for now, we’re focused on **preventing** failures rather than managing them after they happen.
- **Goal**: Suggest this as a future area to explore once failure prediction is stabilized.

#### 6. **Defer Power/Resource Efficiency Trade-Offs**
- **Why**: While balancing power use and latency is important, it complicates the latency focus. Adding power concerns would divert from our main point.
- **Goal**: Leave this for future research, especially as we expand to power-constrained systems like electric vehicles.

---

### Future Direction Summary

**Deferred Enhancements** more advanced models (stochastic latency, dynamic reconfiguration, RL), network latency, and resource optimization. These can wait until after we’ve fully established the basics.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.