Svenska ElektronikForumet

Om timingen mellan paketen är det som är viktigt så kan du helt glömma att göra på det sätt du har tänkt dig. Den förstörs helt av OS:ets scheduler. Edit: och av buffring både här och var.

Om det som är viktigt är att helt enkelt få iväg datat så fort som möjligt när det finns tillgängligt så är det bästa du kan göra att helt enkelt skriva det till drivaren så fort datat finns (anropa USBOutput() eller hur du nu gör). Sen är det bara att hoppas att inte drivrutinen väntar på att någon buffert ska fyllas innan datat går iväg. Möjligen kan det finnas något sätt att tala om för drivaren att den inte ska vänta på ytterligare data (typ med en ioctl under Linux eller motsvarande, om det finns, i Windows).

I mina ögon innebär ju realtid att det är en FÖRUTSEBAR och ICKE VARIERADE fördröjning, d.v.s. att överföringslänken har en konstant datahastighet hela vägen.

Inte ens titta på TV över ip är "realtid", det buffras och kan bli stopp eller "hack". Normalt är bufferten visserligen så stor att man UPPLEVER det som realtid, men "under huven" ser det annorlunda ut.

> I mina ögon innebär ju realtid att det är en FÖRUTSEBAR och ICKE VARIERADE fördröjning,

Det stämmer inte riktigt. Förutsebar kanske, men inte nödvändigtsvis
icke varierande.

Om t.ex 10 sekunder är "realtid" i ett visst sammanhang, så är allt
mellan 0 och 10 sekunder "realtid", i just det sammanhanget. Spelar
i princip ingen roll hur det varierar mellan 0 och 10 sekunder. Att det
varierar spelar ingen roll så länge som det ligger inom (eller under) gränserna.

I TV så är allt som kallas "live" i princip realtid, även om det fördröjs
5 sekunder (som Melodifestivalen från Jerusalem) så att någon
i kontrollrummet kan avbryta om något händer.

Som sagt, min poäng var att "realtid" är ett missbrukat begrepp, och
vanligtsvis används det då man inte har full koll på vad man
håller på med...

Skall man köra med så pass snabba förlopp att ms är avgörande så kan man nog glömma USB helt -även TV-capturekort via USB bygger på att man buffra ganska rejält med data hos perferienheten och efter en ganska tidsödande transaktionshantering för att sätta upp överföringen i windows-kärnan så kan man köra över en ganska stor klump data på liten tid för att återigen ägna ganska mycket tid för att kopplaned transaktionen igen i windows-kärnan.

av erfarenhet med GPIB med HP:s adapter så verkar det ganska vårt att få över 30 transaktioner i sekunden om man inkluderar fullständig reset mellan varje anrop av tex. USB/RS232-anrop - eller om man har 2 st RS232/USB och en GPIB/USB-konverter så får man vara glad om man klarar 5-7 cykler i sekunde om man gör 2 st RS232anrop + 1 GPIB-anrop i varje cyckel... - och nästa allt tid spenderas i windows-kerneln och dess transaktionshanterare mot USB och man kan inte göra ett skit åt detta i användrprogrammet...

Skall man ha realtidsöverföring även vid småpaket så ger förmodligen IEEE1394/firewire betyligt större möjlighet då denna gränssnitt faktiskt gjordes för att kunna hantera raw-video och ljud i realtid och utan avbrott pga. OS-arbete då den har DMA mm. som underlättar realtidsbeteendet - vilkeyt USB inte har haft möjlighet till i dom flesta moderkortschipset utom kanske de senaste chip-seten och man måste alltid räkna med att all USB-hantering alltid sker med PIO-mode och därmet påverkar alla tänkbata mjukvarutimerloopar mm. i windows-kärnan och det enda säkra är 1/32 + någonting sekund HW interupt-referens...

Det är som andra skrev att alla timer-tider under 100 ms är synnerligen osäkra och varierande i windowsmiljö.