Здравствуйте, Nasdaq, Вы писали:

N>подскажите гуру,
N>имеем

N>- поток данных (с АЦП)
N>- 8 каналов (float 4 bytes)
N>- 3kHz

N>- Java сервер читает эти данные и ретранслирует клиентам (один или несколько)
N>- Клиент читает данные и что-то делает с ними
N>- Клиент и сервер используют nio ByteBuffers, оба работают в одно поточном режиме


N>т.е. получается поток данных где-то 100кб/сек
N>но система приближена к реальному времени ибо буфер на АЦП всего несколько секунд, так что задержок в несколько секунд со считыванием быть не должно

N>правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

N>OS — Windows

Не прокатит, при запуске GC пойдет глобальный ступор и ничего читаться не будет. Надо глядеть в сторону real-time java и прощаться с windows.

подскажите гуру,
имеем

— поток данных (с АЦП)
— 8 каналов (float 4 bytes)
— 3kHz

— Java сервер читает эти данные и ретранслирует клиентам (один или несколько)
— Клиент читает данные и что-то делает с ними
— Клиент и сервер используют nio ByteBuffers, оба работают в одно поточном режиме


т.е. получается поток данных где-то 100кб/сек
но система приближена к реальному времени ибо буфер на АЦП всего несколько секунд, так что задержок в несколько секунд со считыванием быть не должно

правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

OS — Windows

Nasdaq wrote:

> — Клиент и сервер используют nio ByteBuffers, оба работают в одно поточном режиме
> правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

Насколько я понимаю, при использовании blocking-io ваш сервер может
запросто подвиснуть при выдаче данных в сокет для клиентов. Если такая
ситуации может случиться, ваш единственный поток подвиснет и не сможет
читать данные с ваших АЦП и они (данные) могут быть безвозвратно утеряны.

Отсюда вывод: либо использовать non-blocking-io, либо завести на вывод
данных еще один поток, а доступ к общему буферу засинхронизировать.

Aib wrote:

> Не прокатит, при запуске GC пойдет глобальный ступор и ничего читаться не будет. Надо глядеть в сторону real-time java и прощаться с windows.

Не пугайте — у человека буфер на несколько секунд, так что не все так
плохо. Кроме того можно посмотреть на BEA JVM.

Здравствуйте, Nasdaq, Вы писали:

N>т.е. получается поток данных где-то 100кб/сек
N>но система приближена к реальному времени ибо буфер на АЦП всего несколько секунд, так что задержок в несколько секунд со считыванием быть не должно

N>правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

Про проблему с GC уже упоминали. Её надо в любом случае тщательно оттестировать.
Насколько я понимаю, ваш сервер только читает данные из АЦП и пишет их в сокет.
То есть задача сводится к тому, чтоб не создавались в рабочем режиме (после инициализации) новые долгоживущие объекты.
Для надёжности можете включить incremental GC.

Второе, буфер TCP всего 64кб по умолчанию. Если клиент задумается (скажем, из-за того-же GC), то данные пропадут, либо остановят сервер (его единственный тред), либо будут накапливаться в памяти (как организуете передачу данных в nio). Так что увеличьте размер буфера (у клиента и сервера), либо сделайте более умный сервер, чтоб буферизировал данные, если сокет на отправку их не может отправить (но если данных накопится много — то GC может и начать долго отрабатывать, хотя инкрементальный GC может помочь).

Здравствуйте, Nasdaq, Вы писали:

N>правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)
N>OS — Windows
Готовься шаманить с настройками GC, иначе проблемы точно будут

Здравствуйте, Nasdaq, Вы писали:

N>подскажите гуру,
N>имеем

N>- поток данных (с АЦП)
N>- 8 каналов (float 4 bytes)
N>- 3kHz

N>- Java сервер читает эти данные и ретранслирует клиентам (один или несколько)
N>- Клиент читает данные и что-то делает с ними
N>- Клиент и сервер используют nio ByteBuffers, оба работают в одно поточном режиме


N>т.е. получается поток данных где-то 100кб/сек
N>но система приближена к реальному времени ибо буфер на АЦП всего несколько секунд, так что задержок в несколько секунд со считыванием быть не должно

N>правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

N>OS — Windows

Чтобы не было проблем с GC, копайте в сторону Concurrent Mark Sweep Garbage Collector. Он позволяет практически полностью исключить остановки виртуальной машины на Full GC.

Увеличение буфера TCP тоже важно, про это уже написали.

Здравствуйте, Лобанов Игорь, Вы писали:


ЛИ>Чтобы не было проблем с GC, копайте в сторону Concurrent Mark Sweep Garbage Collector. Он позволяет практически полностью исключить остановки виртуальной машины на Full GC.

ЛИ>Увеличение буфера TCP тоже важно, про это уже написали.

чем дальше тем страшнее

пока ситуация такая что работает стабильно на 1kHz, при том что клиент ничего не делает с данными, только считает сколько пришло пакетов.
на 3kHz начинает терять данные по несколько раз в минуту.
А должен работать без сбоев вообще сутками ! )))

Здравствуйте, mazurkin, Вы писали:

M>Nasdaq wrote:

>> — Клиент и сервер используют nio ByteBuffers, оба работают в одно поточном режиме
>> правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

M>Насколько я понимаю, при использовании blocking-io ваш сервер может
M>запросто подвиснуть при выдаче данных в сокет для клиентов. Если такая
M>ситуации может случиться, ваш единственный поток подвиснет и не сможет
M>читать данные с ваших АЦП и они (данные) могут быть безвозвратно утеряны.

M>Отсюда вывод: либо использовать non-blocking-io, либо завести на вывод
M>данных еще один поток, а доступ к общему буферу засинхронизировать.

да nio используется

Здравствуйте, Aib, Вы писали:


Aib>Не прокатит, при запуске GC пойдет глобальный ступор и ничего читаться не будет. Надо глядеть в сторону real-time java и прощаться с windows.

пока это out of scope )))

Здравствуйте, Nasdaq, Вы писали:

N>Здравствуйте, Лобанов Игорь, Вы писали:


ЛИ>>Чтобы не было проблем с GC, копайте в сторону Concurrent Mark Sweep Garbage Collector. Он позволяет практически полностью исключить остановки виртуальной машины на Full GC.

ЛИ>>Увеличение буфера TCP тоже важно, про это уже написали.

N>чем дальше тем страшнее

N>пока ситуация такая что работает стабильно на 1kHz, при том что клиент ничего не делает с данными, только считает сколько пришло пакетов.
N>на 3kHz начинает терять данные по несколько раз в минуту.

В этом предложении, по-видимому, имелся в виду сервер, а не клиент?

N>А должен работать без сбоев вообще сутками ! )))

Так на каком уровне данные теряются?

Я вижу три варианта:
1) Данные вообще с клиента не уходят -- можно проверить, например, поглядев на сеть снифером;
2) Данные теряются по дороге в сети -- можно тоже проверить снифером, но на стороне сервера;
3) Данные приходят в сокет, но не считываются оттуда -- можно делать дамп того, что вычитано из сокета.

N>имеем

N>- поток данных (с АЦП)
N>- 8 каналов (float 4 bytes)
N>- 3kHz

N>- Java сервер читает эти данные и ретранслирует клиентам (один или несколько)
N>- Клиент читает данные и что-то делает с ними
N>- Клиент и сервер используют nio ByteBuffers, оба работают в одно поточном режиме


N>т.е. получается поток данных где-то 100кб/сек
N>но система приближена к реальному времени ибо буфер на АЦП всего несколько секунд, так что задержок в несколько секунд со считыванием быть не должно

N>правильно ли я понимаю, что при правильной реализации — это должно работать (в смысле нет проблем связанных с Java)

N>OS — Windows



UPD

немного ещё вопросов
что-то я не понял как узнать какие опции работают на Window JVM какие нет, в документации как-то не очень понятно, опции описаны, а к чему относятся непонятно. Вот например на опцию "-server" ругается а по поводу "-Xincgc" молчит.

— Значит ли что Xincgc действует на Windows JVM ?