eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronika › COM Windows opóźnienie
Ilość wypowiedzi w tym wątku: 9

  • 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.


strony : [ 1 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: