Digitala utgånar från PC
> dvs händer just nu,
Vad är "nu" ???
Med min definition av "nu" så klarar *inget* system (dator eller annat)
av "realtid".
I praktiken skulle jag vilja säga att gränsen går någonstans runt 1 ms.,
i alla all när det gäller "riktiga" OS.
När det gäller mindre system (microcontrollers och liknande) så kanske
någonting mindre än 10-20 us skulle kunna kallas "realtid".
*Vissa delar* av Windows skulle kunna ses som "realtid", t.ex kopplingen
mellan musrörelser och muspekare...
Vad är "nu" ???
Med min definition av "nu" så klarar *inget* system (dator eller annat)
av "realtid".
I praktiken skulle jag vilja säga att gränsen går någonstans runt 1 ms.,
i alla all när det gäller "riktiga" OS.
När det gäller mindre system (microcontrollers och liknande) så kanske
någonting mindre än 10-20 us skulle kunna kallas "realtid".
*Vissa delar* av Windows skulle kunna ses som "realtid", t.ex kopplingen
mellan musrörelser och muspekare...
Sorry, lite för mycket vin, gissar jag.
All IO i en PC är buffrad och buffrarna töms när processorn känner för det.
Jämför med förr i tiden, det gick inte att köra serieportn fortare än nånstans runt 9,6k eller så, pga att den gamla 450 kretsen inte hade tillräckligt med buffer.
För att få upp speeden fick man köpa hutlöst dyra seriekort med 550 kretsar som kunde buffra tillräckligt mycket.
Vill minnas att klockan i en PC är nånstans runt 20 ms, vilket (rätta mig gärna) är den tiden mellan avbrott för IO.
Detta gör att snabba förlopp är mycket svåra att hantera för en PC.
Pröva gärna att dra musen mycket snabbt, pekaren kommer bara halvägs, PC'n tappar helt enkelt informationen därför att den kommer för snabbt (för små buffrar)
All IO i en PC är buffrad och buffrarna töms när processorn känner för det.
Jämför med förr i tiden, det gick inte att köra serieportn fortare än nånstans runt 9,6k eller så, pga att den gamla 450 kretsen inte hade tillräckligt med buffer.
För att få upp speeden fick man köpa hutlöst dyra seriekort med 550 kretsar som kunde buffra tillräckligt mycket.
Vill minnas att klockan i en PC är nånstans runt 20 ms, vilket (rätta mig gärna) är den tiden mellan avbrott för IO.
Detta gör att snabba förlopp är mycket svåra att hantera för en PC.
Pröva gärna att dra musen mycket snabbt, pekaren kommer bara halvägs, PC'n tappar helt enkelt informationen därför att den kommer för snabbt (för små buffrar)
Hmm, gammal mus enbart PS2 blir det så. (inga/små buffrar)
Nåväl, jag tror att det är direkt omöjligt att direkt styra förlopp under säg 100 ms direkt från en PC, det krävs nog externa enheter för att göra detta, sedan kan man ju naturligtvis låta PC'n styra dessa externa enheter via normal IO.
Dvs man får ha en extern kontroller av något slag som hanterar timingen och utförandet, och PC'n får "programmera" denna att utföra det som skall göras.
Nåväl, jag tror att det är direkt omöjligt att direkt styra förlopp under säg 100 ms direkt från en PC, det krävs nog externa enheter för att göra detta, sedan kan man ju naturligtvis låta PC'n styra dessa externa enheter via normal IO.
Dvs man får ha en extern kontroller av något slag som hanterar timingen och utförandet, och PC'n får "programmera" denna att utföra det som skall göras.
Senast redigerad av TomasL 4 maj 2007, 22:56:59, redigerad totalt 1 gång.
> Vill minnas att klockan i en PC är nånstans runt 20 ms, vilket
> (rätta mig gärna) är den tiden mellan avbrott för IO.
Nja, jag tror att det är tiden mellan att schedulern går in och kollar.
D.v.s avbryter running task och kollar om det ligger något annat som
ska scheduleras.
Om det kommer *interrupt* (t.ex från I/O) så är jag övertygad om att
även Windows har möjlighet att hantera det *innan* nästa 20 ms timeslot,
d.v.s "direkt". Annars skulle t.ex hårdisks eller firewire I/O blir väldigt
slött....
> Dvs man får ha en extern kontroller av något slag som hanterar timingen
> och utförandet, och PC'n får "programmera" denna att utföra det som skall göras.
Absolut !
Eller att skriva "riktiga" Windows drivers för sina enheter, men det är inget
man gör på en kafferast...
> (rätta mig gärna) är den tiden mellan avbrott för IO.
Nja, jag tror att det är tiden mellan att schedulern går in och kollar.
D.v.s avbryter running task och kollar om det ligger något annat som
ska scheduleras.
Om det kommer *interrupt* (t.ex från I/O) så är jag övertygad om att
även Windows har möjlighet att hantera det *innan* nästa 20 ms timeslot,
d.v.s "direkt". Annars skulle t.ex hårdisks eller firewire I/O blir väldigt
slött....
> Dvs man får ha en extern kontroller av något slag som hanterar timingen
> och utförandet, och PC'n får "programmera" denna att utföra det som skall göras.
Absolut !
Eller att skriva "riktiga" Windows drivers för sina enheter, men det är inget
man gör på en kafferast...
Märker att man börja bli rostig på sådant här
Klockan har hemskt udda takt som runt 18 iterrupts i sekunden eftersom MS i begynnelsen inte initierade registren i HW-timrarna utan kördes på defaultvärdet vid spänningspåslag - det blev standard och ingen vågar rucka på detta sedan dess och windows dåliga tidsupplösning är kvar sedan dess trots olika 'virtuella' olika räknare i OS..
I linux hade man i allafall smaken att sätta dessa HW-räknare till något lämpligt värde som 100 ggr i sekunden...
---
Tror dom flesta MCU skulle få väldigt lite tid över till annat om den måste hantera över 1000 interrupts i sekunden 450-kretsen gav. I PC-världen så är dessutom RS232-interuppten väldigt lågt prioriterat - typ nästan sist och allt annat går före. Block transfer mode var något man fick slå av i BIOS om man skulle modema samtidigt - då diskkrivningarn tog så lång tid om dessa körde mer än en sektor i taget... HD:n sköttes ju med PIO-mode - det var först med CD-brännarna som MS så småningom tvingades införa DMA-transfermode på hårddiskhanteringen (något som linux hade aktiverat åratal innan)
problemet är att USB har ingen DMA-mode utan är PIO-baserad och därmed processorintensiv när den arbetar. Firewire/1394 har DMA-stöd och drar väldigt lite CPU trots full filtransport.
Klockan har hemskt udda takt som runt 18 iterrupts i sekunden eftersom MS i begynnelsen inte initierade registren i HW-timrarna utan kördes på defaultvärdet vid spänningspåslag - det blev standard och ingen vågar rucka på detta sedan dess och windows dåliga tidsupplösning är kvar sedan dess trots olika 'virtuella' olika räknare i OS..
I linux hade man i allafall smaken att sätta dessa HW-räknare till något lämpligt värde som 100 ggr i sekunden...
---
Tror dom flesta MCU skulle få väldigt lite tid över till annat om den måste hantera över 1000 interrupts i sekunden 450-kretsen gav. I PC-världen så är dessutom RS232-interuppten väldigt lågt prioriterat - typ nästan sist och allt annat går före. Block transfer mode var något man fick slå av i BIOS om man skulle modema samtidigt - då diskkrivningarn tog så lång tid om dessa körde mer än en sektor i taget... HD:n sköttes ju med PIO-mode - det var först med CD-brännarna som MS så småningom tvingades införa DMA-transfermode på hårddiskhanteringen (något som linux hade aktiverat åratal innan)
problemet är att USB har ingen DMA-mode utan är PIO-baserad och därmed processorintensiv när den arbetar. Firewire/1394 har DMA-stöd och drar väldigt lite CPU trots full filtransport.
-
JimmyAndersson
- Inlägg: 26558
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
..och därmed är Firewire/1394 snabbare än USB2, trots att USB i sig skulle klara högre hastigheter.
"I PC-världen så är dessutom RS232-interuppten väldigt lågt prioriterat"
Ännu en orsak till att MIDI var trevligare på Atari/Mac än PC.
När det gäller musrörelserna som diskuterades tidigare:
Jämför en gammal Mac med en ny PC. Mac'ens muspekar följer rörelserna *mycket* bättre och snabbare än PC'n (främst om PC'n kör Windows). Det känns nästan som om man flyttar muspilen direkt med handen. En av alla detaljer som gör Mac'en roligare för grafikarbeten...
Tråden blev ganska off-topic, men intressant.
"I PC-världen så är dessutom RS232-interuppten väldigt lågt prioriterat"
Ännu en orsak till att MIDI var trevligare på Atari/Mac än PC.
När det gäller musrörelserna som diskuterades tidigare:
Jämför en gammal Mac med en ny PC. Mac'ens muspekar följer rörelserna *mycket* bättre och snabbare än PC'n (främst om PC'n kör Windows). Det känns nästan som om man flyttar muspilen direkt med handen. En av alla detaljer som gör Mac'en roligare för grafikarbeten...
Tråden blev ganska off-topic, men intressant.
USB är egentligen en ursel protokoll - elektriskt sett så kunde det ha gjorst av ett gäng nyexaminerade digitalknuttar och programerare med noll erfarenhet, transmissionsteori, och verklighet - Man gjorde precis samma misstag som med IDE-bussen i version USB 1.0 och 1.1 och fick fixa till det hjälpligt i efterhand i 2.0 med krav att dest skulle vara bakåtkompatibelt. Därför är gränssnitten så jäkla sörjiga idag och tekniskt sätt inte kommer så mycket högre i hastighet av den orsaken. 1394 har redan idag 800 Mbit/s och i protokollen är det förberett för både 1600 och 3200 Mbit/s och vidare
Sedan är realtidsstrategin också helt olika. USB så måste host polla av slavarna hela tiden om de vill meddela sig någonting - en av orsakerna att man inte kan få omedelbar respons mellan pin-aktivitet och läsning/skrivning av RS232-USB gränssnitt som man är van vid UART-baserat. och iom att den är paketorienterad utan synkronicering så börja man få problem när bus-beläggningen är bit över 50% (som alla paketorienterade nät) och grejor börja få vänta på varandra utan garanterad tillträde i tid - mao. duger det inte för okomprimerad realtidsvideo (ca 35 Mbyte/s) där man verkligen inte har råd med oväntad fördröjning då och då.
1394 är verkligen byggd för detta och kan sägars vara paketorienterade systemets motsats - dvs. kretskopplat med reserverad bandbredd och för applicationen garanterad tillträde till dom tidsslottar som är reseverad.
Nu kan iofs. både USB och 1394 glida över på 'andra' domänen paketorienterat/kretskopplat mer eller mindre men 1394 gör det så mycket bättre - jag menar att det inte skall hacka på USB-HD som en tung kulspruta vid tung filtransfer bara för att jag rör på USB-musen samtidigt - då är det dålig design... att USB heller inte har DMA utan är PIO-intensiv gör också sitt till i 'oanvändbarhet' i nära realtidssammanhang som tex. capturing av video.
Sedan är realtidsstrategin också helt olika. USB så måste host polla av slavarna hela tiden om de vill meddela sig någonting - en av orsakerna att man inte kan få omedelbar respons mellan pin-aktivitet och läsning/skrivning av RS232-USB gränssnitt som man är van vid UART-baserat. och iom att den är paketorienterad utan synkronicering så börja man få problem när bus-beläggningen är bit över 50% (som alla paketorienterade nät) och grejor börja få vänta på varandra utan garanterad tillträde i tid - mao. duger det inte för okomprimerad realtidsvideo (ca 35 Mbyte/s) där man verkligen inte har råd med oväntad fördröjning då och då.
1394 är verkligen byggd för detta och kan sägars vara paketorienterade systemets motsats - dvs. kretskopplat med reserverad bandbredd och för applicationen garanterad tillträde till dom tidsslottar som är reseverad.
Nu kan iofs. både USB och 1394 glida över på 'andra' domänen paketorienterat/kretskopplat mer eller mindre men 1394 gör det så mycket bättre - jag menar att det inte skall hacka på USB-HD som en tung kulspruta vid tung filtransfer bara för att jag rör på USB-musen samtidigt - då är det dålig design... att USB heller inte har DMA utan är PIO-intensiv gör också sitt till i 'oanvändbarhet' i nära realtidssammanhang som tex. capturing av video.
-
PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Hmm för att återgå till ämnet...
Själv skulle jag valt en PIC2550, eller vad heter den mindre modellen? Den som inte lyckas få igång kommunikationen med hjälp av Microchips C-kod, VB-exemplena och de tillgängliga drivrutinerna får nog börja med byggsatsprojekt
Ja jag vet, usb-standarden är mycket komplicerad och allt sånt, men med en USB-PIC är det så enkelt att man nästan blir förvånad att komma igång. Är själv inte någon C-expert eller USB-expert, men det var inga större problem att bygga en USB-ansluten LCD-display som funkar med LCD-smartie.
Själv skulle jag valt en PIC2550, eller vad heter den mindre modellen? Den som inte lyckas få igång kommunikationen med hjälp av Microchips C-kod, VB-exemplena och de tillgängliga drivrutinerna får nog börja med byggsatsprojekt
Ja jag vet, usb-standarden är mycket komplicerad och allt sånt, men med en USB-PIC är det så enkelt att man nästan blir förvånad att komma igång. Är själv inte någon C-expert eller USB-expert, men det var inga större problem att bygga en USB-ansluten LCD-display som funkar med LCD-smartie.
Tack för alla svaren!
Jag gjorde som jag skrev, och nu kan jag tända fyra olika lysdioder från ett program i datorn. Hade lite problem med baudrate och intern oscillator (den gick fel visade det sig), så jag lödade dit en riktig kristall som jag hade hemma.
Min tanke är att jag ska uppgradera till USB om mitt projekt blir en succé, men i utvecklingsläge går det bra såhär.
Det är ett realtidssystem jag håller på med, men jag ska inte styra något kärnkraftverk med det och jag hoppas verkligen inte PC:n är något hinder. Ett fel på 1ms är helt ok, 10 ms förmodligen ok, 50ms förmodligen inte ok.
Jag gjorde som jag skrev, och nu kan jag tända fyra olika lysdioder från ett program i datorn. Hade lite problem med baudrate och intern oscillator (den gick fel visade det sig), så jag lödade dit en riktig kristall som jag hade hemma.
Min tanke är att jag ska uppgradera till USB om mitt projekt blir en succé, men i utvecklingsläge går det bra såhär.
Det är ett realtidssystem jag håller på med, men jag ska inte styra något kärnkraftverk med det och jag hoppas verkligen inte PC:n är något hinder. Ett fel på 1ms är helt ok, 10 ms förmodligen ok, 50ms förmodligen inte ok.
Om det blir oönskade konsekvenser om svarstiden är över 50 ms så skall du nog använda annan typ av OS än windows. och då menar jag inte automatiskt Linux utan kanske en specifik RT-OS och tom. gammal DOS (dvs. glöm alla najsiga GUI och enkla utvecklingsvertyg som visual basic))
Hur mycket du än strippar så kommer windows ha kvar saker som helt plötsligt låser datorn i sekunder och mera med okända regler hur dessa startar. Tex utökning av swapen är en sådan grej som låser datorn i sekunder och som jag har råkat ut på en 150000:- one shot mättur och fick göra om för ytterligare 150000:- bara för den skull...
Detta hade inte visat sig någongång innan under olika, även långa tester och heller inte lyckats framkalla i efterhand. sådant kommer bara då det är jävligt dyra konsekvenser... sådan är windows och du kan aldrig säkra den helt.
Andra saker som verkar högpriroterat är tex flyttning av fönster i GUI:t, start av olika program med medföljande minneshantering, swap på HD och ger tappade frames på BT8x8-baserade videocaprure-kort - dvs. trots 3 GHz CPU och < 10% last vid capturing så kan man inte få garanterad resurs från windows i högprioriterad program för att ta hand om en bildframe, komprimera och stuva ned på HD var 40 ms i jämn takt och mycket resursmarginaler om man samtidigt flyttar ett fönster i GUI:t...
Andra saker som kan få datorn att närmast stanna är nätverkskrångel och inte svar från DNS, olika servrar och certificeringar etc.
---
När DRM blir intergrerat i OS:t som i Vista så kommer detta bli 100-falt värre... då hela grejen med DRM är att det skall strula och sluta fungera så fort det är minsta misstanke på att licenser inte är i ordning...
- svårt att bygga 'six-nine' utrustning då, dvs. utrustning som fungerar planerat och är tillgängligt i minst 99.9999% av tiden, vilket är en standardnivå för telecomutrustning
Hur mycket du än strippar så kommer windows ha kvar saker som helt plötsligt låser datorn i sekunder och mera med okända regler hur dessa startar. Tex utökning av swapen är en sådan grej som låser datorn i sekunder och som jag har råkat ut på en 150000:- one shot mättur och fick göra om för ytterligare 150000:- bara för den skull...
Detta hade inte visat sig någongång innan under olika, även långa tester och heller inte lyckats framkalla i efterhand. sådant kommer bara då det är jävligt dyra konsekvenser... sådan är windows och du kan aldrig säkra den helt.
Andra saker som verkar högpriroterat är tex flyttning av fönster i GUI:t, start av olika program med medföljande minneshantering, swap på HD och ger tappade frames på BT8x8-baserade videocaprure-kort - dvs. trots 3 GHz CPU och < 10% last vid capturing så kan man inte få garanterad resurs från windows i högprioriterad program för att ta hand om en bildframe, komprimera och stuva ned på HD var 40 ms i jämn takt och mycket resursmarginaler om man samtidigt flyttar ett fönster i GUI:t...
Andra saker som kan få datorn att närmast stanna är nätverkskrångel och inte svar från DNS, olika servrar och certificeringar etc.
---
När DRM blir intergrerat i OS:t som i Vista så kommer detta bli 100-falt värre... då hela grejen med DRM är att det skall strula och sluta fungera så fort det är minsta misstanke på att licenser inte är i ordning...
- svårt att bygga 'six-nine' utrustning då, dvs. utrustning som fungerar planerat och är tillgängligt i minst 99.9999% av tiden, vilket är en standardnivå för telecomutrustning
