I/O Request Processing via Delay-Based Priority Scheduling

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional I/O-request processing systems fail to prioritize tasks effectively, leading to increased delay times and buffer overflow/underflow issues due to lack of consideration for task urgency, resulting in higher buffer requirements.

Innovation Solution

An I/O-request processing system that prioritizes I/O requests based on delay time, continued registry failure time, and failure count, registering requests with longer delays or more frequent failures first to minimize delay times and prevent buffer overflow/underflow.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If I/O requests are processed in conventional priority order without considering delay time, then system simplicity is maintained, but delay time for urgent requests increases and buffer overflow/underflow occurs

Engineering Contradiction:
Improvedelay time of I/O requestVSAvoidbuffer capacity requirement
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The patent changes the priority parameter from conventional CPU-time or I/O-processing-time based metrics to delay-time based metric. The priority judgment section calculates delay time as the difference between current time and I/O request reception time, and uses this delay time parameter to determine processing priority, thereby reducing delay time for urgent requests without increasing buffer capacity

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent implements feedback by continuously monitoring the delay time of each I/O request and using this information to dynamically adjust processing priority. The priority judgment section refers to the delay time information to make real-time priority decisions, ensuring that requests with longer delays are processed first, thus preventing buffer overflow and underflow conditions

Inventive Principle:
Principle #23Feedback

2Reliability

If buffer capacity is increased to prevent overflow/underflow, then system reliability improves, but device complexity and resource consumption increase

Engineering Contradiction:
Improvebuffer overflow/underflow preventionVSAvoidbuffer capacity
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent changes the control parameter from static buffer capacity allocation to dynamic priority-based request scheduling. By using delay time as the priority determination parameter, the system processes requests in an order that naturally prevents buffer overflow and underflow without requiring increased buffer capacity, thus maintaining reliability while reducing resource consumption

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The system uses the delay time information inherent in each I/O request to automatically determine processing priority without external intervention. The priority judgment section autonomously selects which request to process next based on delay time, eliminating the need for complex buffer management and large buffer capacities while ensuring reliable operation

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS7707332B2I/O-request processing system and method
Publication Date: 2010.04.27 NEC CORP
  • US7707332B2 patent drawing
  • US7707332B2 patent drawing
  • US7707332B2 patent drawing

AI summary

An I/O-request processing system which is capable of reducing the maximum value of the time required until the I/O request of each external device is registered. An I/O-request receiving section (501) receives an I/O request issued from an external device (600). A process-information storage section (510) stores an I/O-request delay time (512) for each external device (600). A priority-process judgment section (520) registers the I/O request having a maximum I/O-request delay time (512) among the I/O requests which have been registered into an I/O-request cue (540).