При работе через "сервер" в отделном потоке если я в цикле буду постояно вызывать
LTR34_ProcessData
LTR34_Send
где размер масива будет порядка 80-120 значений как быстро попадут даные на выход модуля если я их поменяю в другом потоке который и будет отвечать за изменения значений??

Олег, попробуем это оценить, только условия эксперимента опишите полностью:
- Какую частоту вывода ЦАП устанавливаете в модуле LTR34 и на какое количество каналов?
- Какая конфигурация крейта LTR (тип крейта, какие модули запущены одновременно)?
- Какой поток (кB/s) будет литься в данный LTR34?
- На фоне какой общей скорости ввода и вывода данных (MB/s) в LTR будем проводить эксперимент?
- Если LTR-EU, то USB или Ethernet?
- Конфигурация компьютера (процессор, чипсет, размер ОЗУ)?

- Нужен синхронный режим вывода (с отсутствием опустошения буфера LTR34) или асинхронный (с опустошением буфера)?

Ноутбук с windows xp поставленый с нуля + офис, core 2 duo 2ггц, озу 1гб, передача по usb,
крейт это Ltr eu 2.5  c модулями  34(8) и 42
частоты цапа модуля 34 достаточно минимальную на 8 каналов. кроме лтр на usb нечего больше не подключено .
если я правильно понимаю то асинхронный режим будет быстрее ??
хотелось бы еще конечно учитывать плавность наростания сигнала скажем
если мы меняем с 0 до 1 вольта то плавность(1%) будет 0.01 т.е. значения выводимые составляли 0,0.01,0.02 ... и тд но это в идеале .
Опять же если я правилно понимаю ваше обьяснения будет достаточно передать 8 значений на модуль34
чтобы установить его выходы в какое то положение.
То есть нужно узнать период време с момента LTR34_Send и до реального появвления сигнала
плюс к этому постояно ли это время.

Опишу как я начал делать но пока я несмог понять результат
есть 2 потока наследованые от стандартного thread
в первом потоке подключен интерфейс модуля 34 и в цикле
/////
while
waitfor..(event)
LTR34_Recv()
LTR34_ProcessData
LTR34_Send
//////
во втором потоке  тогда когда нужно мне, пока это событие кнопки с формы передается значение на  которое нужно выйти лтру ,он формирует массив и вызывает событие event .
Вот с размерами массива я пока и эксперементирую
стоит ли продолжать  это делать и что из этого получится пока незнаю.

также вы писали
////
Собственно, с любым модулем LTR крейт-контроллер LTR-EU имеет ресурс работать на порядки более оперативно, чем через Host-комптьютер, если заточить ПО Blackfin под эту задачу.
////
я правильно вас понял что это написание своей прошивки для лтра?

- Сам LTR34 в асинхронном режиме будет быстрее выводить, если в буфере у него вообще не копить данные, но LTR34 - это последнее звено цепи передачи данных. Есть ещё звенья Сервер, USB и пр. 
- "Плавность нарастания сигнала" в асинхронном режиме ЦАП - это как? В асинхронном режиме плавности гарантировать нельзя. Монотонность при выводе  0,0.01,0.02 ... будет. А вот, гарантированную плавность можно обеспечить только в синхронном режиме...
- Для 8 каналов достаточно передать 8 значений на модуль LTR34. Но в асинхронном режиме они не обязаны появиться строго одновременно на выходах ЦАП.
- "нужно узнать период време с момента LTR34_Send и до реального появления сигнала
плюс к этому постояно ли это время" - Ответ итак известен - время будет непостоянным (грубо в среднем десятки миллисекунд), но с большим разбросом. Это принципиальная асинхронность  Windows. Сколько будет реально? - это можно выяснить только, поставив эскперимент. Поэтому, если написать ПО для Blackfin так, чтобы он самостоятельно слал данные в LTR34 и управлял им, и использовать Blackfin а качестве интеллекта в Вашей системе,  то процесс управления LTR34 и другими LTR-модулями можно убыстрить на 2-3 порядка по времени, если сравнивать с временем реакции Windows.

Для этого, собственно, и было выпущено семейство  крейтов LTR-EU, имеющих периферийный процессор Blackfin (600 МГц, ОЗУ 32 MB), чтобы обеспечить возможность замкнуть быстрый контур управления LTR-модулями на этот процессор...