Всъщност не може с UDP да се подобри tcp. В крайна сметка ще се получи вариант на
tcp под udp така или иначе, инак udp си остава това, което е - "best effort" доставка.

В текущите ми машини (5200B базирани) постигам към 8.5 мегабайта/S ftp трансфер
към wintel телевизор, през 100 MbpS switch. Ограничението да не надхвърли с малко
10 (което би трябвало да се получи) не знам отде идва, не съм го разследвал в детайли,
подозирам, че сумата от ATA+Ethernet+system overhead (последният е минимален
в споменатия тест) идва там някъде (32 бита жица на 133 MHz). ATA е на 66МBpS,
което си е 33 MHz, почти 100% там е главната спирачка. Не съм мерил скоростите без
ATA.

Ако споменатият процесор го може това (мноого съмнително), какво може да се направи
в крайна сметка ще зависи от това за колко паралелно на трансферите може да смята по един
MAC. (5200B докарва под 5.5 nS някъде за .d което по спецификация е два цикъла - два цикъла
бидейки 5nS - и е специфициран за 1 цикъл за .s [.d= dual FP, .s=single fp].)
Оттам нататък са подробности по реализацията, ако остане към 1/3 от ресурса на процесора за
комуникации и общо системно натоварване, всичко ще е наред.

не мисля, че им трябва потвърждение за получени пакети. просто, защото ретрансмита е безсмислен.
даже май не им трябва и обратен канал (високоскоростен) за данни. е, удобно е да е по една и съща медия, но подлежи на жертване.

затова ми се струва, че една семпла синхронна машинка която просто да плюе семпъли в медията в синхронен режим е достатъчно лесна и надеждна за реализация. още повече, че не гонят стандарти и съвместимости, освен със себе си.

съберете и решете.

Виж дали не е това http://www.google.com/search?hl=en&q=qos+windows
по конкретно това: http://techknowbytes.blogspot.com/2008/ ... os-in.html
Пробвай и без switch само с кабел(кръстосан кабел).

Ако изгубен пакет тук и там не е проблем UDP може да ускори малко нещата, разбира се.
И може би да ги опрости (или усложни, според детайлите).

ike, едва ли е това. Не помня вече - има година откак гоних скоростите - но доста си
поиграх и с настройките откъм windows страната. Трябваше да пусна да върви разширен
прозорец (при 100 MbpS 64k прозорец е спирачка дори и при много малко - LAN-чаво - RTT),
и не че не може да съм пропуснал нещо но е малко вероятно, играх си дни наред. После
двата wintel телевизора ftp-чат понякога един към друг с над 10 MBpS, докато внучето
(машината с 5200B с която правих тестовете) не щя. Помня, че доста големи/голям брой буфери
трябваше да сложа за входящи докато победя всички латентности ама си тръгна
мазно на 8.5, без дупки, та всъщност така и не знам защо е. А и не е проблем засега
и едва ли ще бъде де.

И аз мисля като Дедо. Използването на Ethernet в случая е по скоро пречка. Идеологически е сбъркано. Данните са му строго синхронен стрим. Интерфейса не. Това винаги води до тапа в даден момент. Ако може да си подсигури сигурен синхронен интерфейс е най-добре. Така няма да му трябва препредаване, корекция за грешки и прочие.

То въобще вкарването им в "стандартно" PC ако ще работи под "стандартна" ОС също е проблем. Щото и те са асинхронни.

Най-добре да си имат железо дето да си обработва данните отделно. Дали ще е DSP или някакъв мощен процесор, но да си е отделно с проста ОС и основно занимание - да дъвче данните. И ПЦ-то само да визуализира резултата. Евентуално ако им трябва за научна работа - т.е. да доизпипват алгоритми, анализи и прочие - бива. Но за крайно изделие - аз на ПЦ+Едернет не бих се доверил.

Е то това за данните и обработката им в телевизор ясно де, то аз не защото го намирам
приемливо не се цапам с wintel програмиране и комуникирам с тях на ниво пиксели .

Ама за трансфер за известно време без мрежа (само телевизор и устройство на ethernet-а) и приемайки,
че понякога телевизорът ще дава заето със секунди и човек няма да има какво да направи
освен да го гледа тъпо някаква илюзия за работене може да се постигне, предполагам .

Малко да защитя дизайна.

за ПЦ-то:
Да вярно е , че ПЦ-то е много асинхронно, но неговата задача не е да синхронизира а да е достатъчно бързо да се справя (с практически произволно мегабайтово буфериране) с идващите данни. Синхронизирането между различни датчици по идея се извършва от системата пращаща по етхернета АЦП данните, след като да кажем всеки пакет съдържа и още десетина байта от всички датчици свързани времево с него (основно положение на мотор и някои други нискочестотни напрежение) то дали ще бъдат обработени и визуализирани след 0.01 или след 1-2 секунди от ПЦ-то няма голямо значение, стига да се визуализират и да има сносно обоновяване на картината (не твърде рядко че да 'сече'). Закъснения на потребителските команди от порядъка на секунда са приемливи (има се предвид команди засягащи смяна на режима на системата, не цъкане по меню, и определено не 'замръзнал' интерфейс през това време). Да разбира се трябва да съм много смотан да пусна по етхернет само АЦП данни, а примерно в ПЦ-то да чета фази на мотор и да определям положение и да очаквам синхрнонност между тях дори в рамките на милисекунди да не говорим за по надолу (е сигурно не е невъзможно ако може да пипаш в етхернет драйверите но обикновенно особено за ХР, понякога за ЦЕ нямаш сорса, а и вероятно ще намали производителността, язък че мрежовата карта има килобайти буфери ако се мъчи човек да чете колкото се може по-рано че да синхронизира пакета с нещо друго). А иначе ако и без това купим някоя не много скъпа система с двуядрен процесор за визуализацията то той вероятно ще може да прави над 45 000 1024 точкови флоат32 ФФТ-та в секунда (примерно толкоз стига с мой код тоз пентиумМ лаптоп, на двуядрен целерон 2.5 ГХз май минавах 100 000 на едното ядр0, а с по-добър код от нет-а към 8-90 000 стига тук ама искат 6000$ за него, е сигурно няма да може да ползваме ПЦ с АТОМ, ама карай), та ако ни стига тази изчислителна мощ що да търсим специален процесор за сметките , пък ако трябва повечко - ами да вземем четириядрен (все пак интел постоянно ми пълнят пощата с подобен тип тип реклами и може да съм с леко промит мозък) ...

За етхернета:
Да уточня, че броя данни в предната система е 5 МХз 16 бита, но семплирани около 50% от времето та към 5 мегабайта в секунда се очаква да е трафика, това въобще не смятам за ужасно много, в друга система работим с около 0.5МБ в секунда по принцип ( с тази АРМ платка като ПЦ-визуализатор и правещ проста обработка на картината и ФПГА семплираща платка ), съшата програма на 5 годишен пентиумМ лаптоп на 1.5ГХз вчера пуснах на 20 пъти по-висока скорост когато и се пращат записани пакети и се стигна до трансфер 9.5МБ в секунда без проблеми и през хъб 100 мегабита. Освен това имаме толеранс към грешки и пропуснати пакети да кажем 1 на 1000-10000 нещо такова (при пропуск повтаряме последния пакет понеже са сравнително корелирани, теоретично би могло да се компресира на тази основа, но не съм мислил), та поради тези причини твърдо търсим етхернет (все пак и няколко метра метра разстояние се иска), не съм пускал никога USB HiSpeed (въпреки че поразбирам от УСБ покрай пик18ф4550) и тотално нищо не разбирам от Firewire, SATA, хмм даже не мога да изброя други интерфейси за връзка с ПЦ (РС232/485 не е в категорията по скорост).

хммм...

не ви знам бизнес модела, нито роудмапа. ама ми се струва, че не правите радар за домашно ползване в хола.
поне на лодка очаквате да се качва? и надали си мислите за 10 бройки само.

в този случай трябва за забравите всичко безоловно.
да вземете стандартни модули (дъно, памет и т.н.) и да реболвате всичко с оловни топчета е безумие, разбира се.
в този смисъл, четири-ядрените процесори са много привлекателни, но неприложими.
не случайно в совалките не могат да сменят 386-ците.

забравете и за стандартни ОС-ове - ХР, СЕ, linux дори.

преди (боже!) почти 20 години подкарах 1024 фурие на 486/33 за ~25uS. тъй че не е кой знае колко трудно в днешно време да се стигнат 100К. проблема, препънал проекта, беше не толкова времето за обработка, колкото в обмена на данните. тогава много исках да намеря майката на инженера от IBM, който беше навързал DMA-тата и да й кажа, че е трябвало да го удуши при раждането още според мен фуриетата са най-малкия проблем в система като вашата. има една инженерна пословица: "слон се яде на порции". в малки и прости чинийки.

е, от страни винаги е по-лесно да се дава акъл. вероятно си имате добри инженерни причини за всяко решение?
аз изказах само някои съображения. ама като гледам и цецо и tgi по същество казват същото.

между другото - как го правят големите момчета в бранша?

http://en.getac.com/
http://www.buytough.com/tb_30.asp

За такъв тип ПЦ-та става дума, не сме купували още естествено, но правят хората, хубавото е ,че за самата разработка не ни и трябва, но за евентуална продукция все ще се намерят. Все пак не тава дума за животоподдържаща система...

нямам време да чета всички постове и не мога да се ориентирам какъв всъщност е проблемът?

Но ако има съмнения в мрежата - пуснете един wireshark и вижте къде се запушва тръбата.... Иначе тук можем да хвърляме боб, да гадаем и да залагаме. Аз залагам на малък TCP джам ама не помня дали джама можеше да се променя от ЦЕ приложенията или беше набит в BSP-то...

> Да вярно е , че ПЦ-то е много асинхронно, но неговата задача не е да синхронизира а да е достатъчно
> бързо да се справя (с практически произволно мегабайтово буфериране) с идващите данни.
> ....

А бе да, ако е от днес за утре работата може и в wintel PC да се върши . Данните с time-stamp
и то все някога ще се събуди PC-то да стигне и до тях. Голяма част от времето дори ще е будно и никой няма да
забележи, че понякога се успива . Нещо като гледане на филм или мач по мрежата, прекъсванията ако
са малко никой не ги помни.

Въпрос на зададени спецификации, ако успиването понякога е поносимо
що да не е и PC. Е, повечко зор е да се програмира докато победи човек десетилетните
размазаности трупани една върху друга вътре ама нали за всички трябва да има някаква
заетост .

Аз по-скоро имах предвид индустриално ПЦ от сорта на продуктите на Kontron например, някакво лаптопско core 2 duo може би.
Въпросът е обаче дали имате нужда от отдалечен хардуер за събиране на данните, или това АЦП може да е data acqusition платка на PCI / PCIE слот? Щото ако може, вземате един служебен комп, и почвате разработката. Ако няма пари за acqusition платка, симулирате данни. Докато правите софтуера за обработката си разработвате (или купувате готова - ni.com, advantech, ... ), АЦП платка.
Като се замисля, предлагането на такава (16-бит, 5Мс/с) платка не е голямо, и цените може да са страшни. Така че ако си инвестирате времето в нейната разработка (за PCI например), ще имате втори продукт дето да го предлагате. Е, то драйвери-мрайвери ще трябва, но ако се базирате на някакъв стандартен bridge от сорта на PLX чиповете, и тоя проблем е решен.
Тъй де, имам предвид че са малко външните интерфейси, които могат да поемат такива трансфери - през ума ми минава FireWire-a ? Защо не го погледнете дали няма нещо хитро за него (готови data acquisition). Май идва доста по-синхронен, имаше навремето напъни да го правят индустриален (fieldbus). Работи и през оптика ако се налага ... Последно го бяха докарали до 800Мбита/с.

Ето нещо подобно :
http://depts.washington.edu/nucmed/IRL/Recent_Publications/Lewellen_Firewire_IEEE_2005.pdf

Едит: скромните 3600 евра за 4 канална 12-битова с 10М/с на канал ...