User:Graham.Fountain

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Work: Senior Engineer 3 - Technical Specialist in the Networks Group of the Research and Technology Dept., of a large multinational aerospace co.

Other: Chairman BSI committee ACE 6/-/9: Aerospace - Digital data buses, 1992 to Aug 2013.

Interests:

Avionic data networks and data buses:
Integrated Modular Avionics
ASAAC
Provably reliable and secure (i.e. tolerant of faults, and malicious actions), real-time data transfers over packet switched networks, for safety-critical and mission critical applications. Moreover, allowing these provably real-time transfers between the standard Ethernet network interface units that are integrated into almost all the likely equipments, i.e. done properly, not like AFDX or TTEthernet do it:
Network congestion prevention - the ultimate level of congestion control: an ounce of prevention is worth a pound of management and a ton of avoidance.
In regard to hard real-time and soft real-time: “Hard real-time is hard, soft real-time is even harder.” (E. Douglas Jensen)
The difference between hard and firm real-time, at least in terms of data transport over imperfectly reliable media, merely represents the difference between theory and practise - “In theory, theory and practice are the same. In practice, they are not.” (Albert Einstein) So, while distributed real-time systems like IMA may, in theory, be hard real-time, in practise they must allow for some level of loss, and are, necessarily, firm real-time.
However, what does not appear to be well understood, or is at least not well discussed, in regard to real-time data transport (unlike in real-time computing), is that delivering hard or firm real-time data after its deadline is the same as failing to deliver it at all. It may even be argued that late delivery is worse, because the data is valueless, but still consumes resources - see Time-utility function. Hence, sufficiently delaying a real-time data transfer has at least as great an impact as preventing or corrupting it. So, in the context of secure, real-time, safety/mission critical data transport, a real-time transport protocol has to provide a means of proving timely delivery, as well as providing proof of reliable delivery.
And the only way to actually prove that (either or) both reliability and timeliness requirements for delivery will be met (even firm real-time ones) is to guarantee that the real-time traffic is fully protected from congestion, which may not be easy, but has to be done. It may also go against the grain of IP, in requiring complex functionality in the network. But where provably reliable and secure, real-time performance is required, there is no choice.
The leaky bucket and the token bucket algorithms - they're the same thing really.
The generic cell rate algorithm (GCRA).
OpenFlow (versions 1.3.0 and later).
Legacy buses and networks:
MIL-STD-1553B
EN 3910 and EFABus - formerly STANAG 3910
The Asynchronous Transfer Mode
Liner Token Passing Bus - AS 4074.
Related issues
TEMPEST testing
The Triumph TR7 Sprint
The Triumph Dolomite Sprint
The Triumph Slant-4 engine#Sprint version

This user's motto is:

Why put off till tomorrow what you can put off till next week?

This user lives too close to Blackpool for comfort.

This user lives too far from York to be happy.

"It's a great place to live, but I wouldn't want to visit there."
Of the one-way system - "Well, if I was driving there (York central library), I wouldn't have started from here (Parliament St)."
From a bemused American tourist "Why do they call the streets gates, the gates bars, and the bars pubs?"