4 ms·

Maybe off-topic, but why exactly do we have hard and soft real-time? I think this is terrible, either you have deadlines or you don't. E.g. in games which lag y

Maybe off-topic, but why exactly do we have hard and soft real-time? I think this is terrible, either you have deadlines or you don't. E.g. in games which lag you are missing deadlines and the result is terrible. Currently it seems that we distinguish between hard-real-time, soft-real-time and no-real-time, but probably we should just have hard realtime everywhere and if we do not care, we just give big numbers. I mean even if you are not hard realtime you're are probably expecting results before the heat death of the universe, so maybe it would be a nice idea to NOT abstract time in programming languages but give the possibility to the programmer to annotate timing constraints in e.g. function's definitions? E.g. such information could be crucial to the GC. Maybe we could build such a mechanism into a fancy type theory?

xiaq 11y ago
Network service is a good example for soft real-time systems. Under high load, it is preferable to delay the responses a bit instead of starting to drop requests.
- bernardt32z 11y ago
  Yeah, but isn't that just hard real-time with bigger deadlines?
  - xiaq 11y ago
    No. Say we choose 100ms as the (soft) deadline, since some study showed users consider a response time anywhere within 100ms to be "instant". Under light load, all requests are served within 100ms. Under heavy load, response time of some requests can exceed 100ms, but the scheduling algorithm will (likely) try to minimize the quality loss. If we increase the deadline to be 200ms, then even under light load, the response time of some requests can exceed 100ms. That's not what you want.
    - bernardt32z 11y ago
      But in a hypothetical real-time programming environment you could switch strategy at runtime (which of course limits your heuristics as it also has to be hard real-time; that is probably the hardest part). E.g. you could have different code path depending on "load" (which is probably a vague term) and switch to different GC's implementations on the fly. What I mean is, that you always have hard real-time in the end. E.g. you could make your network service with a hard real-time limit of 100ms. On light load you serve all requests as you mentioned with ease, if load gets heavier you hit an uncommon situation (by definition, otherwise you would not be satisfied with soft-realtime) and everything changes, as you hit a rare situation. You could do different things, e.g. in case of a news page just serve plain text and get rid of images and while you are doing that you also change to a different GC that only guarantees 500ms.
digitalzombie 11y ago
Erlang was made for soft real-time. So it's a real thing and accord to wiki: https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f... Hard – missing a deadline is a total system failure. Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline. Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

xiaq 11y ago

Network service is a good example for soft real-time systems. Under high load, it is preferable to delay the responses a bit instead of starting to drop requests.

bernardt32z 11y ago
Yeah, but isn't that just hard real-time with bigger deadlines?
- xiaq 11y ago
  No. Say we choose 100ms as the (soft) deadline, since some study showed users consider a response time anywhere within 100ms to be "instant". Under light load, all requests are served within 100ms. Under heavy load, response time of some requests can exceed 100ms, but the scheduling algorithm will (likely) try to minimize the quality loss. If we increase the deadline to be 200ms, then even under light load, the response time of some requests can exceed 100ms. That's not what you want.
  - bernardt32z 11y ago
    But in a hypothetical real-time programming environment you could switch strategy at runtime (which of course limits your heuristics as it also has to be hard real-time; that is probably the hardest part). E.g. you could have different code path depending on "load" (which is probably a vague term) and switch to different GC's implementations on the fly. What I mean is, that you always have hard real-time in the end. E.g. you could make your network service with a hard real-time limit of 100ms. On light load you serve all requests as you mentioned with ease, if load gets heavier you hit an uncommon situation (by definition, otherwise you would not be satisfied with soft-realtime) and everything changes, as you hit a rare situation. You could do different things, e.g. in case of a news page just serve plain text and get rid of images and while you are doing that you also change to a different GC that only guarantees 500ms.

digitalzombie 11y ago

Erlang was made for soft real-time. So it's a real thing and accord to wiki: https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f... Hard – missing a deadline is a total system failure. Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline. Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.