Browse Prior Art Database

A method for the adaptive display of variable rate data in a user interface Disclosure Number: IPCOM000132279D
Original Publication Date: 2005-Dec-06
Included in the Prior Art Database: 2005-Dec-06
Document File: 3 page(s) / 84K

Publishing Venue



This article describes a method for the adaptive display of variable rate data in a user interface

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 40% of the total text.

Page 1 of 3

A method for the adaptive display of variable rate data in a user interface

When using a graphical tool to analyse and display network traffic a problem arises of how to display the data to the user whilst also keeping pace with the level of network traffic, where the level of traffic is continually changing. The type of system we're considering here, is one which displays flashing graphical "lights" in response to different data packets appearing on a network, so the user can visually comprehend the nature of the network traffic.

An example is the WebSphere MQ* Telemetry Transport protocol analyser:

     If the user interface (UI) processes the data too slowly then a backlog of data will form and the user interface will be displaying data that is not current. If the user interface processes data too quickly then the data will not be as readable to the user. The effect we are aiming to achieve, is that data is displayed for as long as possible to the user whilst still enabling the UI to keep up with the rate of network traffic.

    This disclosure addresses this problem by proposing an adaptive solution that varies the time data is displayed to the user in relation to how busy the network is, whilst not being over sensitive to small bursts of network traffic.

Alternative solutions are:

Set a fixed time that events are displayed on a user interface. The drawback of

this is that this does not take into account how busy the network is. If a burst of network traffic occurs the user interface will lag behind and may never catch up with realtime if the level of traffic is sustained at a high enough rate.

Make the time for which events are displayed on the user interface inversely


proportional to the backlog of events to process. This leads to a situation where the backlog of events to process never clears because whenever the backlog


[This page contains 2 pictures or other non-text objects]

Page 2 of 3

reduces the events are displayed for longer on the user interface. As a result the rate at which events are being processed reduces and the backlog increases.

    There are two main points to this idea. Firstly the backlog of data from the network is only monitored periodically. This allows bursts of network traffic to occur without causing sudden changes in the time the UI displays data for. Secondly a number of thresholds are defined in the backlog of data to be processed, for example at depths 2, 10, 15 and 25.

When data is arriving at a higher rate than the UI is currently processing it then, every time the backlog depth is monitored and found to be in excess of a threshold the time the UI displays an event for is reduced. The greater the number of thresholds that are exceeded the greater the reduction in the time a UI displays data for.

Eventually the UI will have increased its processing rate to a point where it exceeds the rate at which data is arriving from the network. When the backlog drops below the first threshold the time the UI dis...