[news] RealTime & Garbage Collector
То есть то, что Lisp мог делать уже 20 лет назад?
Кто-нибудь знает пример финансового софта, которому нужен soft-realtime? Например, "Realtime Gross Settlement System" не подразумевает soft-realtime вопреки своему названию.
А так вообще новость хорошая и полезная.
А так вообще новость хорошая и полезная.
в банках точно есть потребность в обработке финансовых операций в реальном времени.
те же транзакции платежей и т.д.
те же транзакции платежей и т.д.
> Кто-нибудь знает пример финансового софта, которому нужен soft-realtime?
почти любой биллинг, чтобы отключать пользователей до того как будет 0 на счету, а не после этого.
почти любой биллинг, чтобы отключать пользователей до того как будет 0 на счету, а не после этого.
> в банках точно есть потребность в обработке финансовых операций в реальном времени.
> те же транзакции платежей и т.д.
Да, вот только это "в реальном времени" с realtime в IT-шном понимании (про которое речь в данной новости) никак не соотносится.
> те же транзакции платежей и т.д.
Да, вот только это "в реальном времени" с realtime в IT-шном понимании (про которое речь в данной новости) никак не соотносится.
Да, вот только это "в реальном времени" с realtime в IT-шном понимании (про которое речь в данной новости) никак не соотноситсяпопизди попизди
"реальное время" - предсказуемость промежутка времени выполнения "команд, операций, и т.д." - в моем понимании (что соответствует общему пониманию)
как "реальное время" понимаешь ты - то это твои трудности.
Вроде, телекомовский и финансовый софт и раньше на яве писали тоже. Как я понял, громкие слова про rt - это про то, что Garbage Collector отрабатывает за определенное время. Означает ли это гарантию на фиксированное время ответа? В любом случае, время отклика будет зависит также от обращения к базе и от того, что предсказать нельзя. Имхо, такая работа с GC вообще должна плохо повлиять на производительность overall. А вот, hot swappable (читай установка на сервер без перезагрузки) для Weblogic очень кстати. И поддержка Spring framework -хорошо.
Какие могут быть разговоры о реальном времени, если всё оборудование работает вероятностно (ECC-память, коррекция ошибок на данных, идущих от харда, и т.д.)? Я уж молчу, что большинство ОС сейчас многозадачные.
> В любом случае, время отклика будет зависит также от обращения к базе и от того, что предсказать нельзя.
При необходимости, мы можем общаться с кэшем, а не базой, и иметь гарантированное время отклика.
> на производительность overall
Так кроме общего overall для тех же биллингов, очень часто важно время выполнения одного запроса.
При необходимости, мы можем общаться с кэшем, а не базой, и иметь гарантированное время отклика.
> на производительность overall
Так кроме общего overall для тех же биллингов, очень часто важно время выполнения одного запроса.
> Какие могут быть разговоры о реальном времени, если всё оборудование работает вероятностно
А математику зачем в институтах преподают?
ее преподают как раз для того, чтобы даже в этих случаях можно было посчитать время гарантированного отклика.
А математику зачем в институтах преподают?
ее преподают как раз для того, чтобы даже в этих случаях можно было посчитать время гарантированного отклика.
По-моему вы просто про разные реалтаймы говорите.
Есть реалтаймовые оси, и там гораздо более жесткие требования к реалтайму. И задачи гораздо более ответственные (ядерный реактор контроллить, или самолет).
Для реалтайма для простых смертных таких требований не накладывается.
Есть реалтаймовые оси, и там гораздо более жесткие требования к реалтайму. И задачи гораздо более ответственные (ядерный реактор контроллить, или самолет).
Для реалтайма для простых смертных таких требований не накладывается.
чего эт ты к укропу на вы? тут все кроме него об одних и тех же реалтаймах 
чего эт ты к укропу на вы?хули ты докопался. тебе все равно, а мне приятно
тут все кроме него об одних и тех же реалтаймахвсе кроме вонда. Он про Real time gross settlement system(RTGS) впаривает.
Хули увидел вместе "realtime" и "финансовые системы" - и давай хуйню писать.
посчитать можно только вероятность. и то, если исходить из тех принципов, на которых всё это оборудование было построено.
так вероятность обычно и нужна, понятно, что если на комп упадет метеорит, то никакого гарантированного обслуживания не будет.
Какие могут быть разговоры о реальном времени, если всё оборудование работает вероятностно (ECC-память, коррекция ошибок на данных, идущих от харда, и т.д.)? Я уж молчу, что большинство ОС сейчас многозадачные.Я так понимаю разработчики написали алгоритм GC, который отрабатывает за фиксированное время. И маркетологи сразу ухватились за термин RT. По своему они правы, ведь их разработчики сделали свою часть работы, для того, что бы вся система была RT. А то, что все нижележащее (ОС, железо, сеть) не является RT, так это не их проблемы.
почти любой биллинг, чтобы отключать пользователей до того как будет 0 на счету, а не после этого.real-time там не нужен.
Задача там такая: у абонента есть X на счету; он запрашивает услугу стоимостью Y разово или Z в единицу времени. Разрешить ему пользоваться разовой услугой (Y<=X?) или в течении какого времени он может пользоваться услугой (чему равно X/Z?)? На самом деле, ситуации несколько усложняется наличием всяких там тарифных планов, аккумуляторов, переводом часов и прочей лабудой, но суть в этом. Real-time там просто не нужен. Достаточно того, что ответ на поставленный вопрос даётся за приемлемое время. Если он на данной железке даётся за приемлемое время в real-time системе, он тем более будет даваться на той же железке в системе общего назначения (real-time порой менее производительны из-за необходимости использования детерминированных алгоритмов. Как и любое другое ограничение, это не увеличивает производительность. Яркий пример -- в real-time системе придётся отказаться от qsort'а).
> Какие могут быть разговоры о реальном времени, если всё оборудование работает вероятностноВремя гарантированно отклика можно посчитать в любой системе имея все входные параметры и предполагая отсутствие сбоев не по вине системы. Возможность это рассчитать для любой системы не делает каждую систему real-time.
А математику зачем в институтах преподают?
ее преподают как раз для того, чтобы даже в этих случаях можно было посчитать время гарантированного отклика.
А то, что оборудование работает вероятностно, это существенное замечание.
В real-time системах нельзя пользоваться дисковыми (и прочими имеющими механическую составляющую)
накопителями, нельзя пользоваться виртуальной памятью (обращение к памяти становится недетерминированным, а переключение между адресными пространствами при переключении задач долгими из-за сброса TLB, если он безтеговый) и не рекомендуется пользоваться многопоточностью (если она вызывает необходимость использовать примитивами синхронизации) и прочими трудно детерминируемыми вещами.
В Яве, если она запускается в ява-машине под системой общего назначения иметь real-time бессмысленно. Вся система, сверху до низу должна быть real-time, иначе это просто buzzword, маркетинговый трюк, фикция. Аналогично, если нет юридических гарантий, про real-time можно забыть.
Я так понимаю разработчики написали алгоритм GC, который отрабатывает за фиксированное время. И маркетологи сразу ухватились за термин RT. По своему они правы, ведь их разработчики сделали свою часть работы, для того, что бы вся система была RT. А то, что все нижележащее (ОС, железо, сеть) не является RT, так это не их проблемы.Подписываюсь Под Каждым Словом
> В Яве, если она запускается в ява-машине под системой общего назначения иметь real-time бессмысленно
Что мешает запустить яву, например, на QNX-е?
или на одном из real-time клонов *nix-а?
Что мешает запустить яву, например, на QNX-е?
или на одном из real-time клонов *nix-а?
Что мешает запустить яву, например, на QNX-е?QNX использует виртуальную память, так что недетерминированность доступа к ней останется, равно как и долгое переключение между задачами.
Смысл?
Если прога работает приемлемо быстро и вы не попадаете на бабки и никто не умирает каждый (редкий) раз, когда она вдруг немного потормозит, то зачем вам гарантии real-time?
Если её притормаживают другие задачи (cron вдруг проснётся или ещё что и надо, чтобы этого не было -- снесите другие задачи с этой железки и система общего назначения будет для ваших целей вполне приемлема.
А если прога тормозит часто, то никакой real-time её не ускорит.
PS. Кстати, информация из первых рук: биллинг (в том числе prepaid) во вполне успешных системах крутится на совершенно безгарантийном PL/SQL'е под каким-нибудь бронтозавриком вроде оракла, запущенным на системе общего назначения linux или Solaris (в зависимости от железки).
хотя бы то, что сановской JDK нет ни под QNX, ни под real-time клоны *nix-ов.
Оставить комментарий
Dasar
BEA выпустило версию явского сервера приложений WebLogic, дающую soft-realtime гарантии. Теперь на Яве можно писать телекомовский и финансовый софт.Обещают паузу на GC порядка милисекунды и code updates без остановки сервиса.
http://www.eweek.com/article2/0,1759,1864334,00.asp