4 ms·
Yeah, but isn't that just hard real-time with bigger deadlines?
by bernardt32z 11y ago
Yeah, but isn't that just hard real-time with bigger deadlines?
- xiaq 11y agoNo. 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 agoBut 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.