-
1. Data: 2010-02-09 10:15:27
Temat: COM Windows opóźnienie
Od: Elektrolot <e...@N...pl>
Czy ktoś z szanownych grupowiczów orientuje się ile mogą wynosić opóźnienia przy
zapisie i odczycie
buforów COMa pod Windows XP na PC 1GHz? Przykładowo zapisuję 5 bajtów i czekam na
odbiór 5 bajtów w
pętli, prędkość 9600 bodów. Program pisany z wykorzystaniem najprostszych komend API.
Zdaję sobie
sprawę, że zależy to od wielu czynników, chodzi mi bardziej o orientacyjny zakres.
-
2. Data: 2010-02-09 10:33:51
Temat: Re: COM Windows opóźnienie
Od: J.F. <j...@p...onet.pl>
On Tue, 09 Feb 2010 11:15:27 +0100, Elektrolot wrote:
>Czy ktoś z szanownych grupowiczów orientuje się ile mogą wynosić opóźnienia przy
zapisie i odczycie
>buforów COMa pod Windows XP na PC 1GHz? Przykładowo zapisuję 5 bajtów i czekam na
odbiór 5 bajtów w
>pętli, prędkość 9600 bodów. Program pisany z wykorzystaniem najprostszych komend
API. Zdaję sobie
>sprawę, że zależy to od wielu czynników, chodzi mi bardziej o orientacyjny zakres.
wysylka 5 bajtow to 5ms, urzadzenie musi przetworzyc, odeslac - czyli
kolejne 5ms.
A dalej mamy schody: nowoczesny port zglosi przerwanie nie wiadomo
kiedy, bo odczeka chwile zanim uzna za stosowne. Wszystko bedzie
wielozadaniono, wiec Windows dorzuci swoje. Dostep do portu portu to
jest zatrzymanie procka na ok 1us - wiec tych us uzbiera sie okolo 20.
Nie jest to duzo, bo w ciagu 10ms jednak, no ale procesorek moglby
ladnych pare tysiecy rozkazow wykonac w tym czasie.
Chyba ze port jakis inny niz "standardowy COM".
J.
-
3. Data: 2010-02-10 16:29:38
Temat: Re: COM Windows opó?nienie
Od: "neuron" <n...@n...com.pl>
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:isd2n5la5d1lbjg00c8088ptm6hoofjl6v@4ax.com...
> On Tue, 09 Feb 2010 11:15:27 +0100, Elektrolot wrote:
>>Czy ktoś z szanownych grupowiczów orientuje się ile mogą wynosić
>>opóźnienia przy zapisie i odczycie
>>buforów COMa pod Windows XP na PC 1GHz? Przykładowo zapisuję 5 bajtów i
>>czekam na odbiór 5 bajtów w
>>pętli, prędkość 9600 bodów. Program pisany z wykorzystaniem najprostszych
>>komend API. Zdaję sobie
>>sprawę, że zależy to od wielu czynników, chodzi mi bardziej o orientacyjny
>>zakres.
>
> wysylka 5 bajtow to 5ms, urzadzenie musi przetworzyc, odeslac - czyli
> kolejne 5ms.
> A dalej mamy schody: nowoczesny port zglosi przerwanie nie wiadomo
> kiedy, bo odczeka chwile zanim uzna za stosowne. Wszystko bedzie
> wielozadaniono, wiec Windows dorzuci swoje. Dostep do portu portu to
> jest zatrzymanie procka na ok 1us - wiec tych us uzbiera sie okolo 20.
> Nie jest to duzo, bo w ciagu 10ms jednak, no ale procesorek moglby
> ladnych pare tysiecy rozkazow wykonac w tym czasie.
>
> Chyba ze port jakis inny niz "standardowy COM".
>
To wszytsko nie tak. Zacznijmy od tego co to jest system wielozadaniowy z
wywlaszczeniem - a takim jest xp.
Wszystko co dzieje sie w systemie to procesy. Program to conajmniej jeden
proces ale moze skladac sie z wielu procesow - tzw watkow.
Sa tez procesy systemowe - np sterowniki urzadzen, procesu uslug itp. No i
glowny proces jadra systemu.
Procesy moga byc zawieszone albo nie - czyli dzialaja teraz. Jednoczesnie.
Zaraz... moment ... jak to jednoczesnie - przeciez mamy tylko jeden procesor
ktory robi jeden i tylko jeden ciag rozkazow maszynowych w danej chwili !!!!
(pomijam procesor 2 rdzeniowy i pewne zaawansowane mechanizmy pozwlajace na
sprzetowa, wspolbiezna realizacje czesci kodu - to w tych rozwaznaiach jest
nieistotne)
Ano jest w systemie mechanizm niemaskowanego przerwania ktory co pewien czas
liczony w us przerywa realizacje aktualnego procesu, oddaje sterowanie
procesowi jadra, jadro "zamraza" obraz przerwanego procesu zapisujac go na
stos i "odmraza" inny proces przekazujac mu sterowanie.
Poniewaz nie ma mozliwosci uruchomienia zadnego procesu tak aby po
"cyknieciu" zegara systemowego nie zoastal nagle i bezwarunkowo przerwany to
mowimy ze system wywlaszcza zadania - mija kilka mikrosekund i bach proces
pala w glowe - bez wzgledu co on w tym momencie robi. Dla przykladu -
systemem bez wywlaszczenia byl Windows 3.x - tam mozna bylo zaznaczyc ze
proces nie moze byc przerwany - ale gdy proces sie wykrzaczyl to caly system
stawal w miejscu.
Powiedzialem ze system po zawieszeniu procesu i odeslaniu go na stos
uruchamia nastepny. I tu jest diabel pochowany ;) Jaki proces? Nastepny w
kolejce procesow. Tyle ze ta kolejka jest dynamicznie modyfikowana i jesli w
systemie mamy 120 procesow (menadzer zadan - procesy - kolumna watki - jak
pisze te slowa to mam tam ich okolo 300) to wcale nie oznacza ze kazdy
proces dostanie 1/120 czasu procesora.
Niektore procesy sa zawieszone i wypadaja z kolejki, inne maja niski
priorytet i sa wykonywane co iles tam obiegow a jeszcze inne - te systemowe
maja "chody" i sie ciagle wciskaja poza kolejnoscia. Jakie sa kryteria to
penie juz nawet w microsofcie nie wiedza ;)
Wrócmy wiec o pytanie o opznienie w odczycie / zapisie buforu com. To
pytanie trzeba podzielic na dwa pytania - jaki jest czas zapsu do bufora
i jaki jest czas, a wlasciwie co jaki czas program moze z tych danych
skorzytac.
Powiedzmy ze urzadzenie wysyla do komputera ciag bajtow Sterownik odebiera
bajt i dopisuje do kolejki (bufora). Kiedy jadro "odmrozi" proces sterownika
portu ten wysyla komunikat (sformuowanie wysyla komunikat jest tu
uproszczeniem, jak wszystko zreszta) do innych procesow ze w buforze sa
jakies bajty do odbioru. Kiedy głowny proces Twojego programu powraca z
zaswiatow to odczytuje komunikat i jesli dajmy na to uzywasz komponentu
TCport to uruchomi on procedure obslugi zdarzenia OnChar która sygnalizuje
ze w buforze jest tyle to a tyle bajtow do odczytania - ale uwaga - tyle
było gdy ostatni raz system dopuscil do procesora proces sterownika. Wtedy
Ty mozesz wysylac do bufora swoje znaki - ale po pierwsze nie wiesz ile
razy i na jak długo podczas operacji przygotowania odpowiedzi system pozbawi
Cie swiadomosci zanim uda sie wyslac te znaki do bufora (po glacy dostajesz
co kilkanascie - kilkadziesiat INSTRUKCJI MASZYNOWYCH !! ), po wtore nie
jest wcale powiedziane ze proces obslugi portu dopcha sie za 100mikro
sekund - moze to byc za pol sekundy ;)
Dlatego w windowszie nie da sie takiej kalkulacji wykonac. Koniec, kropka.
Prgram stacji zbierania danych z mojego Golema wysyla i odebiera
symultanicznie pakiety dlugosci ok 30bajtow i przy predkosci 9600 wymienia
ok 30 pakietow na sekunde ale czasami, co widac po diodach monitorujacych
transmisje przysypia sobie na ułamek sekundy na swierzym komputerze i na 2,3
sekundy na moim roboczym ktory jest jednym wielkim smietniskiem roznych
procesow ;)
Inaczej jest w systemach czasu rzeczywistego - tam programista ma wplyw na
kolejkowanie procesow i moze na kilkadziesiat instrukcji zablokowac
wywlaszczenie aktualnie wykonywanego.
wojtek
www.neuron.com.pl
CMMS Maszyna
Golem OEE
Hall2007
-
4. Data: 2010-02-11 12:13:54
Temat: Re: COM Windows opó?nienie
Od: <k...@w...pl>
> Wszystko co dzieje sie w systemie to procesy. Program to conajmniej jeden
> proces ale moze skladac sie z wielu procesow - tzw watkow.
Błędne założenie proces to nie wątek.
Wątek jest częścią składową procesu nawet w Windows
W programowaniu w Windows używa się wątków, dla Uniksów Także procesów.
-
5. Data: 2010-02-11 12:15:58
Temat: Re: COM Windows opó?nienie
Od: J.F. <j...@p...onet.pl>
On Thu, 11 Feb 2010 13:13:54 +0100, <k...@w...pl> wrote:
>W programowaniu w Windows używa się wątków, dla Uniksów Także procesów.
W Unixach procesow, a czasem watkow :-)
Ale jak to zwykle - trzeba zaczac od definicji, bo rozne systemy i
jezyki moga roznie uwazac.
J.
-
6. Data: 2010-02-11 12:33:30
Temat: Re: COM Windows opó?nienie
Od: <k...@w...pl>
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:s5t7n5pgdspl5ml7coc6rahdrpf455utvj@4ax.com...
> On Thu, 11 Feb 2010 13:13:54 +0100, <k...@w...pl> wrote:
>>W programowaniu w Windows używa się wątków, dla Uniksów Także procesów.
>
> W Unixach procesow, a czasem watkow :-)
Tak, dlatego napisałem "Także"
> Ale jak to zwykle - trzeba zaczac od definicji, bo rozne systemy i
> jezyki moga roznie uwazac.
http://pl.wikipedia.org/wiki/Proces_%28informatyka%2
9
http://pl.wikipedia.org/wiki/W%C4%85tek_%28informaty
ka%29
W tym wypadku definicja wątku jest niezbyt ścisła i nie konsekwentna,
ponieważ jest napisane, że wątek to inny rodzaj procesu, to nie jest prawda.
Prawidłowa jest definicja zawarta w procesie. Wątki tworzy się do wykonania
części zadań procesu.
-
7. Data: 2010-02-11 15:13:04
Temat: Re: COM Windows opó?nienie
Od: "neuron" <n...@n...com.pl>
Użytkownik <k...@w...pl> napisał w wiadomości
news:hl0sv8$jn0$1@nemesis.news.neostrada.pl...
>
>> Wszystko co dzieje sie w systemie to procesy. Program to conajmniej jeden
>> proces ale moze skladac sie z wielu procesow - tzw watkow.
>
> Błędne założenie proces to nie wątek.
>
> Wątek jest częścią składową procesu nawet w Windows
>
> W programowaniu w Windows używa się wątków, dla Uniksów Także procesów.
>
A nadmiar precyzji prowadzi do haosu ;)))
Piszac proces mam na mysli task, zadanie, ciag operacji maszynowych, cos co
jest traktowane przez jadro jako spojna calosc, co dostaje swoje zasoby,
swoj numer, uchwyt, adres, przydzielony stos i co najwazniejsze - pewien
czas procesora.
Zaznaczylem ze upraszczam a trzymanie sie slepo definicji w tak rozlazlej
dziedzinie jak informatyka jest bez sensu.
wojtek
www.neuron.com.pl
CMMS Maszyna
Golem OEE
Hall2007
-
8. Data: 2010-02-12 12:43:04
Temat: Re: COM Windows opó?nienie
Od: J.F. <j...@p...onet.pl>
On Thu, 11 Feb 2010 13:33:30 +0100, <k...@w...pl> wrote:
>Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>>>W programowaniu w Windows używa się wątków, dla Uniksów Także procesów.
>>W Unixach procesow, a czasem watkow :-)
>
>Tak, dlatego napisałem "Także"
O kolejnosc mi chodzi - w unixie podstawa sa jednak procesy, watki
doklejono znacznie pozniej i nie zawsze do konca.
J.
-
9. Data: 2010-02-15 09:16:28
Temat: Re: COM Windows opó?nienie
Od: <k...@w...pl>
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:o1jan5hqgjv8frioc6lcaqg4lcosfa5rla@4ax.com...
> On Thu, 11 Feb 2010 13:33:30 +0100, <k...@w...pl> wrote:
>>Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>
>>>>W programowaniu w Windows używa się wątków, dla Uniksów Także procesów.
>>>W Unixach procesow, a czasem watkow :-)
>>
>>Tak, dlatego napisałem "Także"
>
> O kolejnosc mi chodzi - w unixie podstawa sa jednak procesy, watki
> doklejono znacznie pozniej i nie zawsze do konca.
Tak, to prawda.