15 ms·

"Real time" to me means an interaction delay in the range of milliseconds. If the delay is more in the range of seconds like the web application i am working on

"Real time" to me means an interaction delay in the range of milliseconds. If the delay is more in the range of seconds like the web application i am working on then "live" would probably be a better term.

davidw 17y ago
The traditional meaning of 'real time' (at least in embedded stuff) doesn't really specify just how fast, just that things have to be done in a given amount of time. Generally, you're right that those things happen quickly too. http://en.wikipedia.org/wiki/Real-time_computing http://en.wikipedia.org/wiki/Real-time_computing I also agree that 'live' or some other term might be a nice way of not confusing things.
anonymousDan 17y ago
I think event-driven (as opposed to request driven) is probably a better term to describe the conceptual difference being discussed here. Obviously you could then have different latency requirements for event delivery depending on the application.
- wglb 17y ago
  I think this is the best way to think about it. Event-driven unstructured or lightly structured data.
wglb 17y ago
There is a range of timespans that Real Time applies to. In data acquisition, say a medical signal such as an electrocardiographic signal or an EEG signal, we are talking milliseconds. I wouldn't think of web transactions as real-time, even though there is user expectation of response within a certain small number of seconds. In the context of the investments mentioned, these seem like the data comes in asynchronously, not matched with a specific request, and that the interesting work to be done is to make sense out of this non-fielded data. As someone else said here in this thread, Google made search interesting again using essentially unstructured data--no real metadata to get your ERD around. Similarly, the other sources we are thinking of also don't really have that much structure--no tag saying HERE-IS-WHAT-YOU-ARE-LOOKING-FOR. To me, this is why these are interesting problems.

davidw 17y ago

The traditional meaning of 'real time' (at least in embedded stuff) doesn't really specify just how fast, just that things have to be done in a given amount of time. Generally, you're right that those things happen quickly too. http://en.wikipedia.org/wiki/Real-time_computing http://en.wikipedia.org/wiki/Real-time_computing I also agree that 'live' or some other term might be a nice way of not confusing things.

anonymousDan 17y ago

I think event-driven (as opposed to request driven) is probably a better term to describe the conceptual difference being discussed here. Obviously you could then have different latency requirements for event delivery depending on the application.

wglb 17y ago
I think this is the best way to think about it. Event-driven unstructured or lightly structured data.

wglb 17y ago

There is a range of timespans that Real Time applies to. In data acquisition, say a medical signal such as an electrocardiographic signal or an EEG signal, we are talking milliseconds. I wouldn't think of web transactions as real-time, even though there is user expectation of response within a certain small number of seconds. In the context of the investments mentioned, these seem like the data comes in asynchronously, not matched with a specific request, and that the interesting work to be done is to make sense out of this non-fielded data. As someone else said here in this thread, Google made search interesting again using essentially unstructured data--no real metadata to get your ERD around. Similarly, the other sources we are thinking of also don't really have that much structure--no tag saying HERE-IS-WHAT-YOU-ARE-LOOKING-FOR. To me, this is why these are interesting problems.