Talk:Real-time computing

Hard vs. Soft

The distinction between hard and soft is incorrectly stated. An RTOS is hard when the consequences of not meeting time constraints are severely unacceptable -- typically, medical and other life-threatening situations. Most commercial RTOSs form soft systems, not hard. (I have the time neither to correct the mistakes nor to provide the requisite references.) P00r 04:03, 1 May 2007 (UTC)

Oh jeez, just cite Liu, J. W. 2000 Real-Time Systems. 1st. Prentice Hall PTR. For all of this. —Preceding unsigned comment added by 152.14.245.184 (talk) 18:19, 23 March 2010 (UTC)

Too soon can be as bad as too late

I'm not going to edit the entry, but I want to make an observation. There are real-time systems in which failure can occur if an operation starts too soon. I deal with such systems frequently. One example is a half-duplex serial connection where one side must delay sending data until the other side has had time to tri-state the shared communication line. Another is a system where one process reads data that must arrive from another from within recurring assigned time windows. An example might be a simple star network, where a central processor takes data from a number of external processors, each of which has well-defined time windows assigned to it. Jive Dadson 21:10, 20 June 2006 (UTC)

Your point may be worth mentioning, but you can typically wait for your window, which is not as much of a concern or as difficult a requirement as making it within your window. 108.6.2.66 (talk) 18:43, 13 May 2010 (UTC)

Proposed merger or other reorganizations

What's up with real-time? Its talk page links here, and most of the useful information in it is better explained here or in the RTOS entry. Some of the information on it (Gartner forcasts a fast increase...) is out-of-place, or at the very least needs to be properly cited. And the whole entry needs better organization. I think either we should try to merge "Real-time computing" into a section of "Real-time", or delete the latter. piman 03:09, 2005 Feb 27 (UTC)

My vote is to merge Real-Time computing" to Real-time" Symphonic

I'm much more active on the Dutch Wikipedia than I am here, but I can't help myself today: The real-time-article is also used to explain some other real-time activities, like [[real-time]] chat on WP:IRC. So you guys might want to take this into account in discussing wheter these two articles should be merged. MigGroningen 20:15, 19 February 2006 (UTC)

I agree, merge. This article primarily relates to computing. It should be merged, and "Real-time" should either be what's Real-time (media) now, or some overall explanation of the concept (which I don't think has been written here yet), or just a disambiguation page. --Howdybob 13:53, 16 May 2006 (UTC)

I should elaborate. I think there should be a conceptual definition of "real-time" which applies to everything. I should be able to say "this works in real time" or "it speeds up to thirty times real time." I don't think that's anywhere now. The same article should also cover what it means as an adjective in general, and links to the various things like computing and media. Nobody has really defined the concept of "real-time," just given examples and applications. Howdybob 14:49, 16 May 2006 (UTC)

Realtime currently is going to a disambiguatiuon page, which I feel is incorrect. Being bold, I'll have realtime land here. Electrawn 01:37, 13 September 2006 (UTC)

I feel the disambiguation is necessary, as there exist many different concepts of real-time. Why should it be incorrect?? Fuffzsch 13:52, 7 November 2006 (UTC)

I agree with using a disambiguation. To find out what the term means, you should use a dictionary, not an encyclopedia. 108.6.2.66 (talk) 18:46, 13 May 2010 (UTC)

Other subjects

I would like to ask how does the real time operating system achieve the task in real time.How does it make sure that the given task is finished in the given amount of time.

Different RTOSs may do different things when a task does not complete in its alloted time (e.g., kill it and log an error, abort it this time and raise its priority for the next time, kill less critical tasks). In some cases they may do different things for different tasks (e.g., a flight critical task may be allowed to complete even if it runs over its alloted time, but non-flight critical tasks get killed to give the flight critical ones more time in the future). These are usually designer/programmer decisions and the RTOS must be properly configured to meet the system requirements.

But sometimes the RTOS doesn't even get a say in the matter, if the task doesn't complete in the alloted time it will never complete due to external "real world" events. The best example I ever heard of this was someone's description of a real time data collection computer they were working on that came up in a conference on design methodologies: "I don't think you understand what I mean when I say real time system. The system I am working on is attached at one end of a one meter long steel rod, at the other end of which is a nuclear bomb. It begins collecting data and transmitting it over a high speed link to another computer just before detonation. This system MUST complete all tasks before the radiation from the explosion destroys the processor. That is what I mean by real time system." That is an example of a true hard real time system. -- RTC 00:20 Apr 24, 2003 (UTC)

I recognise this anecdote from Tom Demarco's Foreword to Hatley D and Pirbhia I, Strategies for Real-Time System Specification, Dorset House Publishing, New York 1988 ISBN 0-932633-11-0. With Tom's usual talent for the snappy, he uses the example to differentiate real-time from just 'quick as a bunny' Atconsul (talk) 08:39, 10 May 2013 (UTC)

Real-time can be changed to make operating systems much stronger, if only we had time.

---

How does it make sure that the given task is finished in the given amount of time.

An excellent question. Say I ask the computer to do some complicated task, and I see with my stopwatch that it takes 2 seconds to finish. Clearly, if I give it a deadline of 0.1 second, the task is going to overrun the deadline.

With most desktop PCs, one demands that the computer do this, that, and the other thing, and we expect it to (eventually) do all of them.

What happens in a realtime system is that one asks the real-time system to do this, that, and the other thing, with a particular deadline (and perhaps on a repeating schedule). Every time you give it a task with a deadline, it checks -- Is there plenty of time to meet the deadline, even in the worst case, taking into account all the other tasks and their deadlines ? If there is any potential for problems, then it politely refuses that task up front. Only if it is certain that it can finish that task (and all the other tasks it has already committed to) will it accept and commit to that task.

Do I need an example ?

--DavidCary 05:16, 20 Jul 2004 (UTC)

Firm Real-time System

Can anyone explain what is a firm real-time system and how is it different from hard and soft real-time systems? One definition I found was that systems which are soft real-time but in which there is no benefit from late delivery of service. Confused me further...

There is a lot of confusion about what constitutes a soft real-time system even among researchers. There are, however, a few classical versions. One of these is the notion of firm real-time (and the only one of these variants that I know even has a name). With firm deadlines, deadlines may occasionally be missed, but there is no use of continuing the work after the deadline. Typically there are borders on how many misses are acceptable (i.e. max 3% deadline miss ratio). This is in perfect correspondence with the definition you found. Basically, after the deadline, the computation is useless, so you might as well skip to the "next" computation as soon as the system realises that the deadline will be missed (in many system this is at the deadline, but potentially it could be earlier).

For comparison, another notion of soft real time systems is the one where some jobs may occasionally be slightly late, but still have to be performed. Further, there are several other interpretations floating around, and as said, quite much confusion. If you have access to a university library, this paper might be an interesting read to clarify some of the confusion. TERdON (talk) 16:00, 15 October 2008 (UTC)

---

Why the gratuitous plug for Gartner? - unsigned (please sign your comments)

The concept of "real time" is one which is too general to localise to computing. I agree that two articles about the same thing (RTC) should be merged, but that is best done here and not not at RT, which should either be a philosophical treatment of the abstracted concept (with tangents in psychology {perception}, physics {relativitity}, not to mention any colloquial usage, etc). No specific concept can dominate a more general one, unless its a very old one (hence a seminal term and part of the language tradition); we dont let gamers cant move the Halo (video game) article to Halo. In this case, the RT article has yet to materialize in the abstract form due to its bind to the specific. -Ste|vertigo 20:06, 10 February 2006 (UTC)

The last paragraph is indeed very questionable. Wikipedia is the wrong place for wild guesses about the future and it sounds like pure marketing bullshit blather. I bet whoever added that is affiliated with Gartner or just loves bullshit bingo. --82.141.57.73 01:00, 8 July 2006 (UTC)

Real-time not a subset of computing!

I cannot follow the idea to merge real-time with real-time computing, as real-time is a broader subject than real-time computing. Although, the matter of real-time is not only a matter of computation. So, neither of these themes are a subset of the other.

There are real-time networks, real-time secure networks. Of course, they do have some software, but that is only part of it.

SAE1962 13:24, 29 June 2006 (UTC)

The 68000 Was a CPU, not a Computer

Part of the History section reads, "Once when the C64 and later Motorola 68000 were popular...." This seems less than wonderful because the C64 (the Commodore 64) is a model of computer, and the Motorola 68000 is model of CPU (used in the Macintosh and Amiga). I'm going edit this, changing "C64" to "MOS Technology 6502," which was the CPU of the C64 (and the Apple II).

I agree with you that gradually fixing the problems of this section will someday lead to an excellent encyclopedia article.

Most of the history section, including the part you mention, was deleted by someone who apparently disagrees with that philosophy.

So I restored it. I hope this doesn't lead to a huge edit war. --DavidCary (talk) 01:46, 21 December 2012 (UTC)

Compared to these the Programmable Interrupt Controller of the Intel CPUs (8086..80586) generates a very large latency This is a broad qualitative statment. The main point about real time is that *fast enough is fast enough*, so even if it were 'very large' and that was fast enough for your application, you would have a real time solution. But how fast is it? What are the numbers?

Windows operating system is neither a real-time operating system nor does it allow a program to take over the CPU completely and use its own scheduler. That's a separate point and will best be made as one. If a program took over the CPU and used its own scheduler it would subvert the OS. But real-time systems have been built on Wintel hardware and firmware as the referenced article on *scheduler* catalogues.

I don't see any philosophy here. Do we mean to imply that the 6502 did something intrinsically right? Are we saying that a 30 year old 6502 has a better realtime performance in every case than Intel's best system today, and that the computing industry has taken a wrong turn? If so that's a very non-neutral view of the history of (real time) computing and I doubt serves Wikipedia well. Any case to continue to make the point would need to be better argued both for and against. One could discuss or reference the emergence of transputers, RISC Reduced instruction set computing, ARM Architecture ... SCADA, PLCs, systolic array ...

I didn't do the deletion btw. I would have felt honour-bound to offer a complete rewrite, which I'm not. A history of real time computing is needed. Atconsul (talk) 09:11, 10 May 2013 (UTC)

Modern Air Travel

"It would not be possible to offer modern commercial air travel if these computations could not reliably be performed in real time." This is simply untrue, since "modern commercial air travel" existed long before the development of the microchip; indeed, before even ENIAC. Depends what's meant by "modern commercial air travel"...as a reader, I think "modern commercial air travel" certainly existed when people were boarding DC-3s in the 1930s. Perhaps the original author can clarify.

There has been tremendous misuse of the expression "real time" Most people confuse online rapid response with real time. "Real time" means synchronized with the clock. Notice a NASA missile launch. "T-10 and counting". The missile does not ignite when ready but is poised to ignite at just the right second and every operation is the synchronized with the clock. "Shut off" occurs at just the right time. Collecting telemetry live from an aircraft is not real time. It is rapid and with minimum delay but it is not synchronized with the clock. 68.50.127.210 19:02, 6 July 2007 (UTC)Tom Amenta tom.amenta@aya.yale.edu

Firm Real-time System

Firm real-time system is a system in which a completion of an operation after its deadline is considered useless, but the system can withstand a few missed operations.

Ehudhal 03:33, 12 September 2007 (UTC)

Milli second is real time?

What is real time? Is it the interval of one milli second between input and output? One micro second? One nano second? One pico second? One femto second? One atto second?

What is real time to one system may not be so for another. Time is relative. Anwar (talk) 10:07, 11 June 2008 (UTC)

It's a common misconception that real time means fast -- it doesn't. It means on time, within a specified error, where the acceptable error was set by the system designer. The error could be microseconds or minutes, it all depends upon the application. GyroMagician (talk) 09:22, 26 August 2008 (UTC)

sorry but it does not mean "on-time", check the difference between real, user and system time, run a 'time .' comand in Linux to have an idea of the differences

(unsigned embedded comment) 2013-09-10T16:24:19‎ Hugozam

Nevertheless, GyroMagician was right. Real-time does not meean fast, it means to deterministically (re)act within a definable maximum allowed time to process, including worst case scenarios. Usually, this amount of time is small, and much effort in the design and implementation of real-time operating systems goes into making it as small as technically possibly, however, if the application does not demand a particularly fast response, but a task to be completed within a certain amount of time, ensuring that even under the worst conditions still makes it a real-time operating system. --Matthiaspaul (talk) 16:21, 10 September 2013 (UTC)

IS the FTSE 100 a RT system?

Is the FTSE 100 a good example of a RT system? I'm not sure it is catastrophic if the system runs slow. I'm not simply deleting because I can't decide. The system has to be responsive, but I'm not sure the limits are precisely defined. A word-processor should also be responsive, but isn't RT. Any opinions? GyroMagician (talk) 20:13, 5 November 2008 (UTC)

It's probably a good example. It's defined to be calculated every 15 seconds (source: FTSE 100 Factsheet), and any delay over this limit has the potential to translate into financial losses to investors, index funds, or similar. —Piet Delport (talk) 2010-12-15 10:45

real time used wrongly

real time has been used/defined wrongly in this article. real time means the ability of a system to be modified whille running by changing its input....i will try and get some references to journals. Prince Waters (talk page) 20:45, 7 December 2009 (UTC)

°Re: Oh, no. What you mean is "online" computing. Real-time has to do with time constraints, such as deadlines. Source: Giorgio Buttazzo, "HARD REAL-TIME COMPUTING SYSTEMS: Predictable Scheduling Algorithms and Applications", Second Edition, Springer, 2005. This is the the best book from a theoretical stand point and clarify all the doubts. 87.6.67.248 (talk) 15:13, 15 December 2009 (UTC)

scheduling / interrupting tasks

How does the definition of "real time" relate to getting interrupted by the OS?

It seems like when I hear people talking about RT programming they talk about assurances that nothing else is going to interfere with a certain task.

Is this what RT programming is all about or a side aspect of RT programming? —Preceding unsigned comment added by 214.4.3.75 (talk) 01:54, 3 April 2010 (UTC)

Dead links

Some of the External Links are presently dead or pointing to confusing redirects:

International Symposium on Object-oriented Real-time distributed Computing (dead link)

Real-time, Embedded, and Specialized Systems Platform Task Force (confusing redirect to http://www.omg.org/homepages/index.htm which doesn't mention realtime) --Donkeydonkeydonkeydonkey (talk) 21:22, 23 July 2010 (UTC)

Thank you for finding these; if you want, you can be bold and update Wikipedia articles yourself. I replaced the first link with <http://www.informatik.uni-trier.de/~ley/db/conf/isorc/index.html>, which appears to be a listing of past conferences; I am not positive that it is from the organizers and will be updated for 2010, so there may be a better link out there. For the second, that Platform Task Force appears no longer to exist (see <http://www.omg.org/homepages/index.htm> and scroll to Platform Technology Committee), so I removed it. There does appear to be a relevant conference at <http://www.omg.org/news/meetings/SMCS/rt/Program.htm>, if anyone prefers to replace than remove. - 2/0 (cont.) 00:06, 24 July 2010 (UTC)

Key People

This is uncited and, in some cases, dubious. It's also unclear what real value such a list adds to the article. I'm leaving it here in talk for now.

• Sanjoy Baruah
• Alan Burns
• Giorgio Buttazzo
• Costas Courcoubetis
• David Dill
• Nicolas Halbwachs
• Hermann Kopetz
• Arthur Pollen
• Bruce Douglass
• John Stankovic
• Lui Sha

Fell Gleaming^talk 02:58, 14 September 2010 (UTC)

Disputed

Is this article's factual accuracy still disputed? If so, regarding what topic? 145.120.14.162 (talk) 20:17, 14 January 2011 (UTC)

Looks like there is no dispute, so I'm removing it. 145.120.14.162 (talk) 03:06, 22 January 2011 (UTC)

Defining a real time system as one that has real time constraints is disputable, although popular. A batch system to process a weekly payroll has a time constraint. It must complete by payday. However few would consider it to be a real time system. Is there in fact any computing system that does not have an explicit or implicit time constraint? WhaleyTim (talk) 14:11, 19 June 2011 (UTC)

There is another oft-used definition (from out of the USENET comp.realtime FAQ) for real-time computing regarding real-time digital signal processing:

In a real-time DSP process, the analyzed (input) and/or generated (output) samples (whether they are grouped together in large segments or processed individually) can be processed (or generated) continuously in the time it takes to input and/or output the same set of samples independent of the processing delay.

Consider an audio DSP example: if a process requires 2.01 seconds to analyze or process 2.00 seconds of sound, it is not real-time. If it takes 1.99 seconds, it is (or can be made into) a real-time DSP process.

A common life example is standing in a line (or queue) waiting for the checkout in a grocery store. If the line asymptotically grows longer and longer without bound, the checkout process is not real-time. If the length of the line is bounded, customers are being "processed" and outputted as rapidly, on average, as they are being inputted and that process is real-time. The grocer might go out of business or must at least lose business if he/she cannot make his/her checkout process real-time (so it's fundamentally important that this process be real-time).

This definition is the one used for real-time audio and video. It means that the processing time is less than the time to get a sample. Note that in the case of Internet it is easy to get starvation because the sample arrivals depend on the bandwidth. Would this come under "firm" real-time? 70.109.177.197 (talk) 05:02, 20 July 2011 (UTC)

The third paragraph: "The needs of real-time software requires the use of one or more synchronous programming languages, real-time operating systems, and real-time networks which provide the essential frameworks on which to build a real-time software application.” is untrue in that many real real-time systems have been built without the use of synchronous programming languages, however good a solution they may be to the problem. Simonjwright (talk) 01:11, 14 February 2012 (UTC)

Agree; I've submitted clarified wording. JMatthews (talk) 11:28, 14 February 2012 (UTC)

MOVING FROM BABEL TO SCIENCE -- REAL-TIME COMPUTING

After examining the Wikipedia article Real-Time Computing and Talk - the situation remains confused and uninformed. Rather than getting wrapped around the flag pole on definitions, it would be preferable if Wikipedia were to adhere to the modern accepted canon (developed after close to forty years of academic and industrial research, defense and commercial real-time software/firmware development projects - some embedded, some standalone) that now reflect best practices. All interested parties should read Real-Time Scheduling: A Historical Perspective, Dr. Lui Sha, Editor. In contemporary use Real-Time Computing is routinely considered a canonically distinct element of Real-Time Systems, just as Real-Time Scheduling is treated pedagogically as a supporting element of Real-Time Computing. Also, refer to Real-Time Talk.

[1] Sha04-RTSJ.pdf (available free on Google Scholar)

[2] Donald B. Gillies Professor of Computer Science, University of Illinois

[3] Real-Time Systems, J.W.S. Liu, April 2000, Prentice-Hall Publ., Chapters 1,2

[4] Ibid.

Ken Fowler, PhD. Kenfowler1945 (talk) 22:08, 4 March 2012 (UTC)

References

Still puzzled

I still can't work out what usefully distinguishes a RTOS from a non-RT OS. "..."deterministic" timing means that operating system services consume only known and expected amounts of time." Almost all the system calls in my 6502-based BBC Micro were listed with the times the calls took. Does that make it a RTOS? Deterministic timing seems to mean that a RTOS must never interact with a user ever as it is unknown how long the user is going to take. A RTOS must never interact with any IO devices ever. It is impossible to know how long, eg, a disk drive or printer or actionator solenoid is going to take to respond. A RTOS must never run on a system with interupts running, as an interupt could occur during a call and add extra time to the call. All of this seems to essentially say that a RTOS is an unattaintable idealistic system with no useful purpose.

Jgharston (talk) 23:06, 25 July 2012 (UTC)

At the most extreme a RTOS must provide complete deterministic timing for all OS functions. More practically, the RTOS must bound the maximum amount of interference it can cause to any given running program.

For interrupts, the RTOS might split the interrupt handler into fast and slow components. The fast component handles the actual hardware interrupt processing (i.e. when the interrupt physically occurs) and immediately returns control to the application. The slow component is invoked later when there is spare processing time to actually *do* something about the interrupt. For example, take a network card. The card has a limited amount of on-board storage, so when a packet comes in the card will interrupt the CPU. The fast-half of the interrupt handler can do the bare minimum amount of work to service the network card and offload its data, but not actually process the packet. Later, when there is spare processing time, the slow-half of the interrupt handler can be invoked to process the packet. If you can guarantee that the fast half only takes a few microseconds, you can guarantee that each network packet will only delay the currently running process by at most a few microseconds.

User interaction is similar. A user can interact with an RTOS, but depending on the specific interaction, the user might not be the highest priority thing in the system. It is common for many Real-Time systems to have some kind of user display that indicates the status of the system, but this display is a low-priority task. It will only be updated when the RTOS can ensure that doing so will not affect the real-time operation of the system. Note that not all interaction is the same- an emergency-stop button would be a very high-priority interaction, so the RTOS must always be capable of responding to that input, while keyboard input to change the type of data displayed can be much lower priority.

An RTOS cannot guarantee the time it takes for physical actions to happen in the real world, such as a solenoid activating, but it can bound the response to control signals. Think of anti-lock breaking as an example. The computer is periodically getting sensor data about whether or not the car's wheels are slipping. If the sensors detect slippage, then the ABS engages. The RTOS is able to make a guarantee like: "if slippage is detected, then the ABS will engage within 10ms". The RTOS cannot ensure correct operation of the physical components in a system, but it can ensure a proper response to those physical components within a fixed time frame.

Finally, you question whether an RTOS is an unrealistic ideal, and it really depends on what demands you're going to make of it. Commercial RTOSes are heavily tested and certified to operate correctly for the purposes for which they are designed. They're used and they work flawlessly every day (for example, in your car). Other platforms such as the RT_PREEMPT patch for Linux purports to make a 99% RTOS that has all the functionality and features of normal Linux. Are you going to risk your life on that last one percent? Probably not, but lots of people use that variant of Linux for things like high quality audio capture, where the consequence of failure is a little blip in the audio recording.

128.252.20.193 (talk) 21:00, 23 January 2014 (UTC)

"...as fast as a real clock."

I'm considering what I believe to be merely a semantic correction, but as I'm not an expert in real-time programming I want to be sure that I don't alter the intended meaning of the sentence. The sentence in question is from the opening section, and currently reads, "In the domain of simulations, the term means that the simulation's clock runs as fast as a real clock." I'm pretty sure that what was intended was, "In the domain of simulations, the term means that the simulation's clock runs at the same speed as a real clock." The phrase runs as fast as can reasonably be construed to still be true if the simulation clock runs faster than a real clock. In other words, at least as fast can reasonably be inferred from how the sentence is currently written.

Would my proposed change more accurately convey the intent of the sentence?Tedd (talk) 22:14, 23 October 2013 (UTC)

Merge from Time-utility function

According to a learned colleague of mine, it is impossible to discuss Time-utility function without Real-time computing. Since Time-utility function has been tagged for notability and lack of references for four years, a merger would also be appropriate. Bearian (talk) 21:21, 4 February 2014 (UTC)

Yes, please merge whatever is appropriate from Time-utility function to here and change the other article to redirect to here. Thank you. 71.169.179.188 (talk) 05:49, 5 February 2014 (UTC)

Oppose: Time-utility function isn't a term specific to real-time computing only; please have a look at Adaptive Time-utility Function Scheme for Downlink Packet Scheduling in IEEE 802.16e/WiMAX Networks, for example. — Dsimic (talk | contribs) 05:57, 5 February 2014 (UTC)

My goodness, that paper you refer to does the opposite of supporting your case that time-utility function is unrelated to (or whatever is meant by not "specific to") real-time computing. It appears that it is intimately related. I am a DSP engineer, both real-time and non-real-time processing, and I have some experience in other real-time embedded systems and I am not familiar with specifically what "time-utility function" is as a semantic. But I imagine as I read more about it, I am going to find out that even if there is some application of the concept of "time-utility function" to non-real-time targets, that the concept really is primarily about real-time processing and the efficacious scheduling of tasks. 71.169.179.188 (talk) 15:59, 5 February 2014 (UTC)

Sorry, I wasn't clear enough, please allow me to explain. When people talk about real-time computing, they usually think of real-time operating systems (RTOSs), and what I tried to say was that the time-utility function isn't bounded to be used in RTOSs only. That's the reason why I'm suggesting that it should be kept as a separate article, so it's clear that it—as a scheduling function, basically—can be used for many purposes. Hope it now makes more sense. — Dsimic (talk | contribs) 16:21, 5 February 2014 (UTC)

What are the some of the other "many purposes"? It is true that real-time computing is not the same as high-performance computing, but it is related (if the CPU speed is not sufficient, the real-time performance suffers). Similarly it is true that real-time computing, as a topic is not the same as real-time operating system, but they are, of course, related. It appears that this time-utility function is directly related to efficacy of certain processes that affect deadlines. If that is the case, and if time-utility function is small enough and narrow enough to not deserve it's own page (because it looks like a stub), then it should be folded in with the broader topic that contains it. 71.169.179.188 (talk) 17:49, 5 February 2014 (UTC)

The above linked paper illustates use of the time-utility function for network packets scheduling in a real-time manner, and not as part of an RTOS. As another example, this paper describes its use in heterogeneous systems (computer clusters, which are hardly of a real-time nature). Having that in mind, the Time-utility function article could be easily expanded to at least five times its current size. Hence, my opinion is that it shouldn't be merged as it can be expanded – of course, that's just my opinion, and we don't have to agree there. :) — Dsimic (talk | contribs) 18:11, 5 February 2014 (UTC)

I support the merge. Please appreciate that the proposed target is Real-time computing not Real-time operating system. The former should encompass wider aspects of computing including networking. ~KvnG 15:01, 17 February 2014 (UTC)

Merge from Near real-time

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There seemed to be no objections to the proposal. Peter Flass (talk) 16:36, 26 April 2014 (UTC)

---

There are merge banners proposing that Near real-time be merged into this article. Anyone want to discuss this proposal? ~KvnG 14:53, 17 February 2014 (UTC)

Could you please explain what the 'Near real-time' is at all about? I'd vote for completely deleting it unless there's any information there worth merging into anywhere. That said, I know more about real-time computing systems than telecommunications, which seems to be the perspective from which 'Near real-time' article was created.Alexeicolin (talk) 16:55, 11 April 2014 (UTC)

Yeah, just have a look at this quote from the Near real-time article:

The delay in near real-time can be as high as 15 to 20 minutes in some applications.

C'mon, if that's near to real-time... :) To me, Near real-time article looks more like something to be deleted. — Dsimic (talk | contribs) 01:04, 14 April 2014 (UTC)

In my experience, near real-time is about low-latency computing that doesn't have the hard deterministic deadlines characteristic of real-time computing. But it's not about me. The only citation we have is [1] which pretty much quoted in the lead and is pretty much nebulous. Please also have a look at Talk:Near real-time for past discussion. ~KvnG 14:17, 17 April 2014 (UTC)

Yes, real-time is deterministic, near real-time is "more or less" real-time. Peter Flass (talk) 14:20, 17 April 2014 (UTC)

Totally agreed about what near real-time as a term should mean, but there seem to be next to no references providing exact definitions. It's all about "ASAP, but no promises", so to speak, but that's very stretchy if you agree. Maybe this could also be some kind of a reference? — Dsimic (talk | contribs) 14:29, 17 April 2014 (UTC)

Looking at the refs we've collected and the content of Near real-time, I get the impression that there are multiple cases where this term is used. It looks like our options are to turn Near real-time into a disambiguation page pointing to what are probably a few non-notable topics. We can just delete Near real-time or we can do our best at mentioning, based on our knowledge, the term in Real-time computing and redirect there. ~KvnG 02:41, 20 April 2014 (UTC)

I'd say that the "near real-time" term should be mentioned in Real-time computing article, and Near real-time turned into a redirect. — Dsimic (talk | contribs) 06:22, 22 April 2014 (UTC)

Support - NRT Is pretty short and unlikely to get significantly larger.Peter Flass (talk) 22:18, 20 April 2014 (UTC)

Done. There wasn't that much there, I just copied almost all of it in. Peter Flass (talk) 13:10, 25 April 2014 (UTC)

Please have a look at WP:MERGE for the remaining steps (closing the discussion, and placing tags on talk pages). — Dsimic (talk | contribs) 07:21, 26 April 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Martin citation

Although I could not get Google Books to confirm the citation from Martin, I have found this definition of "real-time" of Martin's cited by other authors.

It's a good definition and I think it should stay. I have also confirmed my edit removing the "d" 71.169.179.28 (talk) 16:23, 27 April 2014 (UTC)

Sorry, I think you're right about "and". I have the hardcopy book, but wanted to include some sort of link to a source on Google or Amazon. Peter Flass (talk) 16:38, 27 April 2014 (UTC)

Merge vs No merge

A single article used to distinguish between three distinctly different and accepted meanings of real-time. Some months ago, they were then separated into two articles in a incomplete way and the mixed meanings remain in each new article, and the third meaning was dropped altogether. The differences between the two remaining meanings remain mixed, and aren't distinguished, making for a confusing read. Now there is a proposal to merge these articles (re-merge), without realizing that they were once a single, well segmented article. Many of the comments on this page refer to the ambiguity and confusion that has arrisen from people accustomed to one particular distinct definition. — Preceding unsigned comment added by 130.216.49.8 (talk) 19:46, 25 June 2014 (UTC)

What is the second article you're referring to? ~KvnG 13:25, 3 July 2014 (UTC)

External links

The External links section needs some serious trimming to comply with WP:EL. As a start, I have marked the dead links there. I've checked to see if any of the items referenced in the section has a corresponding Wikipedia article. I've found List of computer science conferences, Kang_G._Shin#Real-Time_Computing_Laboratory_.28RTCL.29, Sant'Anna_School_of_Advanced_Studies#Laboratories_and_research_centers, Simula Research Laboratory. Nothing really worthy of a See also link. We might consider moving this to DMOZ at [2]. We might just want to delete it all. ~Kvng (talk) 16:35, 6 July 2015 (UTC)

Hello! Got the section trimmed down – in theory, having all those external links might have been great, but in practice, 99.9% of the readers had absolutely no use for them. Hope you agree. — Dsimic (talk | contribs) 19:41, 6 July 2015 (UTC)

Real world example (plan9)

Plan9 has a real time scheduling option, this seems like a good real-world example, but I'm not sure how to fit this in. Binarycat64 (talk) 23:58, 4 November 2021 (UTC)

Insert link to "Real time operating system" at the end?

There's currently a link to DSOS, which seems oddly specific as an example of an RTOS. Maybe replace this with a broader link to the general RTOS article? Liftyee (talk) 14:11, 12 March 2022 (UTC)