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.
Body są tu akurat dokładnie zupełnie nieważne. Jak już, to prędkość transmisji w bps. Co do XP to jest to dokładnie nie do określenia. Może być kilkadziesiąt milisekund do (w głupim przypadku) kilku sekund.
Waldek
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.
Waldemar Krzok pisze:
Dzięki za odpowiedz.
Jeśli chodzi body vs bps. To ja bym polemizował. Prędkość transmisji podawana w bps i tak nie dotyczy przesyłu danych tylko całej ramki RS-232. W przypadku RS-232 każdy ze stanów logicznych niesie informację o jednym bicie. Więc w tym przypadku 1 bod = 1 bps. Jedyne do czego można by się przyczepić to do tego, że nie podałem ile bitów leci w ramce i ile mam bitów stopu. Domyślnie przyjąłem 8 bitów danych, jeden bit stopu i brak kontroli parzystości. Co daje 10 bitów ramki na 8 bitów danych i jak słusznie podał J.F. czas poświęcony na transmisję 5 bajtów to 5ms.
W RS232 nie ma modulacji i dlatego nie ma mowy o bodach. W modemie połączonym RS232 można mówić o bodach ale od strony linii telefonicznej - w starych standardach było to zaledwie 600 bodów i tylko coraz bardziej zaawansowane metody modulacji QAM tworzyły coraz to szerszy strumień danych na złączu RS232 - ale tu już w bps.
[...]
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
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.
W Unixach procesow, a czasem watkow :-)
Ale jak to zwykle - trzeba zaczac od definicji, bo rozne systemy i jezyki moga roznie uwazac.
J.
Tak, dlatego napisałem "Także"
Użytkownik snipped-for-privacy@wp.pl napisał w wiadomości news:hl0sv8$jn0$ snipped-for-privacy@nemesis.news.neostrada.pl...
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
O kolejnosc mi chodzi - w unixie podstawa sa jednak procesy, watki doklejono znacznie pozniej i nie zawsze do konca.
J.
Tak, to prawda.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.