什么是“实时”？
我无法决定是否将我的应用程序分类为“实时”或“接近实时”，甚至可能是其他类别。
该软件立即接收从源生成的数据，然后根据某些规则，在满足某些条件时发出警报。 它采用每30秒检查最后30秒数据的方法来查看是否满足规则的标准。
那是实时的吗？ 实时与准实时的定义阈值是多少？
I am having trouble deciding on whether to classify my application as 'real time' or 'near real time', or perhaps even something else.
The software receives data immediately as it is generated from the source, then based on certain rules, raises an alert when certain conditions are met. It takes the approach of checking the last 30 seconds of data every 30 seconds to see whether the criteria for a rule has been met.
Is that real time? What are the thresholds for the definitions of real time vs. near real-time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
我同意约翰的观点，在你的场景中，你看到的至少是 30 秒的延迟，我想说这几乎是实时的。
I am in agreement with John, in your scenario you are looking at least 30 seconds of delay, I would say that it is nearly real time.
实时处理微秒......主要围绕机器人技术。 想想“移动手臂 30 微秒； 焊接 1000 微秒；'，就像汽车装配一样。
您的 30 秒是基于线程睡眠还是非实时操作系统中的计时器？ 如果是这样，那么你就有了潜在的差异。 如果超出该方差（30.01 秒），您会认为这是失败吗？ 如果不是，那么它就不是实时的。
Real Time deals with microseconds...mainly around robotics. Think 'move arm 30 microseconds; weld 1000 microseconds;', like in automobile assembly.
Is your 30 seconds based on a Thread sleep or a timer in a non-real time OS? If so, then you have a potential varience. Will you consider it a failure if you're outside that variance (30.01 seconds)? If not, then it's not real time.
我认为您需要查看需要实时响应的特定解决方案或解决方案的一部分。 实时响应是接收者（应用程序或基本上最终用户）感知为实时的响应。
I think you need to look at the specific solution or part of the solution in where you need the response to be real-time. A real time response is one which is perceived by the receiver (the application or basically the end-user) as being real-time.
我想说实时的定义取决于上下文。 与音乐示例一样，实时时间需要为毫秒，但对于您的示例，实时时间可能在 30 秒左右。 这都是相对的。
I would say the definition of real time would depend on the context. As with the music example real time would need to be milliseconds, but possibly with your example real time could be within 30 seconds or so. It's all relative.
我相信答案是实时系统是主观的，因为“实时”只是需求所施加的及时性约束。 虽然显然需要 2 小时才能响应请求的事情不是实时的，但 30 秒的延迟可能足以满足实时的要求。
我研究的是我认为的实时系统，当系统中发生事件时，它会立即传播到系统上的设备，因此了解设备更新的延迟是网络延迟和所花费时间的乘积更新其内存中的数据。
我个人不会将每 30 秒轮询更新的内容归类为实时。 我们有一个网络应用程序作为上述系统的一部分，它每 30 秒刷新一次，因此向用户呈现的数据最多为 30 秒前的数据。 将此与事件发生后立即更新的获胜形式进行对比。
同样，“实时”受到您对及时响应的定义的限制。
I believe the answer is that realtime systems are subjective, in that "real time" is just timeliness contraints imposed by the requirements. Though clearly something that takes 2 hours to respond to a request is not real time, a 30 second delay might be fast enough to qualify as real time.
I work on what I consider real time systems, where when an event happens in the sytem it is immediately propogated to devices on the system, such that the delay in knowing about an update on a device is product of the network latency and the time take to update its in-memory data.
I personally wouldn't classify something with that polls for updates every 30 seconds as realtime. We have a web app as part of the afore mentioned system that does just that, it refreshes every 30 seconds, so the user is presented with data that is at most 30 seconds old. Contrast this with the win forms equalivent that is updated as soon as the event occurs.
Again, "real time" is bounded by your definition of a timely response.
我在我的网站 realtime.org 上对此进行了长篇论述。 主页有一个简报的临时链接。 该简报讨论了人们如何以及为什么不理解“实时”（以及“硬”、“软”和“可预测”等）的含义。 它提供了一些精确和一般的定义。 我听到有人不同意我对这个话题的解释，但他们中没有人提出像我这样精确和笼统的解释。 正如拉里·金所说，“拉把椅子来，我们谈谈”。
I provide a lengthy discourse on this on my web site real-time.org. The home page has a temporary link to a briefing. The briefing discusses how and why people don't understand what "real-time" (and "hard" and "soft" and "predictable" etc.) means. It provides some precise and general definitions. I have heard from people who don't agree with my explanation of this topic, but none of them have come forward with anything remotely as precise and general as mine. "Pull up a chair, let's talk" as Larry King says.
我的控制朋友对“硬”实时的定义 - 迟到的信息是错误的信息。 如果需要每 1s 到达一次，并且在 1.1s 内到达，那么对于计算来说是没有用的。
Definition of 'hard' real-time from my controls friends - Late information is wrong information. If it needs to be there every 1s and it gets there in 1.1s, it's useless for calculations.
定义“实时”的另一种方法是评估许多 RTOS 的功能s（实时操作系统）。 例如，QNX 的定义位于此处。 请注意，它们符合 POSIX PSE52 实时控制器 1003.13-2003 系统产品标准。 大多数嵌入式操作系统将提供类似的功能。
Another way to define "real-time" is by evaluating the capabilities of the many RTOSs (real-time operating systems). e.g QNX's definition is here. Notice that they conform to the POSIX PSE52 Realtime Controller 1003.13-2003 System product standard. Most embedded operating systems will provide similar functionality.
我认为定义实时的一个方面是该过程是确定性的 - 也就是说，应用程序的响应时间完全可以根据输入进行预测。
因此，使用非常广泛的笔触进行绘画，任何位于 Windows 之上的应用程序充其量只能是“近实时”。 如果您的应用程序运行在某种沙箱平台（Java、.NET）上，而您对平台功能（例如，垃圾收集）没有绝对控制权，则情况更是如此。
我个人的规则是，“实时”不属于台式电脑；而是属于“实时”。 这就是 PLC 的领域（是的，它们可能运行 QNX、VxWorx 甚至 RTLinux 等操作系统）。
I think one aspect that defines real-time is that the process is deterministic - that is, the application's response time is totally predictable based on the inputs.
Thus, painting with very broad brush-strokes, any app sitting on top of Windows can only be "near-real-time", at best. Doubly so if your app is running on some sort of sandbox platform (Java, .NET) where you don't have absolute control over platform functions (eg, garbage collection).
My personal rule is that "real-time" doesn't belong on a desktop PC; that's the realm of PLCs (and yes, they may be running OSes like QNX, VxWorx or even RTLinux).
嗯，这可能更多是一个营销问题，而不是一个技术问题。
就嵌入式硬件而言，实时涉及处理传入信息（中断等）的已知固定最大时间。
您当然可以声称 30 秒的延迟是实时的，特别是如果所述信息的传递时间比这更长。
例如，如果您的“警报”是一封可能在邮件服务器上花费 10 分钟的电子邮件，或者是用户每半小时检查一次的显示器上的红叉，那么 30 秒对于实时来说就足够了。
Well, that could be more of a marketing question than a technical one.
Real-time, in terms of embedded hardware, involves a known fixed maximum time for handling incoming information (interrupts and the like).
You can certainly claim 30 seconds delay as real-time especially if the delivery of said information is longer than that.
For example, if your "alert" is an email that could spend 10 minutes in a mail server or a red cross on a monitor that the users only check every half hour, 30 seconds is more than adequate for real-time.
“实时”一词涵盖了相当大的范围。
模糊的定义是“在有限响应时间内运行的软件”。
在边界较硬的情况下，例如在汽车的喷射控制系统中，该软件被称为“硬实时”。
如果边界是软的，例如在音乐播放系统中，可以容忍高达 50ms 的变化，则该系统被称为“软实时”。
所以，是的，对于实时的某些定义，您的系统是实时的。
但是，如果您在其他实际使用实时系统的人周围将其称为实时，您可能会被嘲笑，因为 30 秒相当长。
The phrase "real-time" covers a fairly large patch of ground.
The vague definition is "software that acts within a bounded response time".
Where the boundary is hard e.g. in a car's injection control system, the software is said to be "hard real-time".
Where the boundary is soft e.g. in a music-playback system, where variations of up to 50ms are tolerable, the system is said to be "soft real-time".
So yes, for some definition of real-time, your system is real-time.
But you're probably going to get laughed at if you call it real-time around anybody else who actually works on real-time systems, because 30 seconds is pretty huge.
实时是指在指定时间段内完成的事件获得所需的响应，否则您的系统将发生故障。
人们习惯于认为这一定意味着“少量的毫秒/微秒”，但这不一定是真的 - 这取决于您的系统。
如果您的系统在 30 秒内没有完成所需的响应，就会失败，那么它就是“实时”的。
对于某些系统，故障可能是灾难性的，例如导致多人死亡 - 这被描述为安全关键，例如关闭核电站。
Real-time is getting a required response to an event completed within the time period specified or your system fails.
People are used to thinking this must mean 'small number of milliseconds/microseconds' but that isn't necessarily true - it depends on your system.
If your system will fail if it doesn't complete it's required response within 30 seconds then it's 'real-time'.
For some systems, a fail could be catastrophic, e.g. causing multiple fatalities - this is described as safety critical, e.g. shutting down a nuclear power plant.
实时 = 保证解决问题的最长时间。 根据应用程序的要求，可能是皮秒或几分钟
这是 StackOverflow 最大的问题：不合格的人用“听起来正确”的答案回答了很多问题并获得了投票，关心答案是否正确的人不会很快胡言乱语足以赢得代表来纠正错误的答案。 由于预期的下意识反应而匿名发布。
Real-time = Guaranteed maximum time for resolution. It could be picoseconds or minutes depending on the application's requirements
This is StackOverflow's biggest problem: unqualified people answer LOTS of questions with answers that "sound right" and get voted up, people who care whether the answer is actually correct don't spew nonsense fast enough to earn rep to fix the wrong answers. Posting anonymously due to expected knee-jerk reactions.