"Marek" ll1vqh$3et$...@n...news.atman.pl

>>> Nawet priorytety przerwań nie miałyby kompletnie żadnego zastosowania -

>> Wg Ciebie nie ma priorytetowania przerwań w takich systemach?

> System operacyjny o jakim pisałem, jest naszym autorskim (grupa kilku osób). Wiemy
doskonale czy braliśmy pod uwagę
> proiorytetowanie przerwań czy nie. W przypadku końcówek wykonawczych nie było
takiej potrzeby

Bo każda z nich może (albo nie może) wykonać tylko jedno zadanie? ;)

> (byłby to przerost formy nad treścią). W systemie operacyjnym jednostki centralnej
(zarządzającej tymi końcówkami) sprawy mają się
> dokładnie odwrotnie.

Czyli jest -- w systemie odbierającym zgłoszenia od tych urządzeń?
Ale jeśli jest -- to chyba nie ma tam jednoczesności zdarzeń. Albo
inaczej -- mogą przywędrować jednocześnie zgłoszenia/przerwania, ale
obsługę owych przerwań (; też przerwania ;) trzeba pokolejkować wg.
prymitywnego algorytmu zwanego priorytetowaniem.

>>> przeciwnie do sterownika jednostki centralnej, gdzie te i wiele innych
>>> mechanizmów zostało oprogramowanych.

>> Tego już zupełnie nie rozumiem.

> Chyba to niewłaściwe forum aby Ci to wyjaśniać. Po drugie wątpię, że przelewanie
dokumentacji w formę dyskusji publicznej jest
> celowe.
> A z pewnością jest zabójczo czasochłonne.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

W dniu 2014-05-15 13:42, Eneuel Leszek Ciszewski pisze:

>> System operacyjny o jakim pisałem, jest naszym autorskim (grupa kilku
>> osób). Wiemy doskonale czy braliśmy pod uwagę proiorytetowanie
>> przerwań czy nie. W przypadku końcówek wykonawczych nie było takiej
>> potrzeby
>
> Bo każda z nich może (albo nie może) wykonać tylko jedno zadanie? ;)

Nie, 8 lub 16 zadań konkretnie bo tyle portów ma każda z tych końcówek.

>> (byłby to przerost formy nad treścią). W systemie operacyjnym
>> jednostki centralnej (zarządzającej tymi końcówkami) sprawy mają się
>> dokładnie odwrotnie.
>
> Czyli jest -- w systemie odbierającym zgłoszenia od tych urządzeń?

Zgadza się. Tam dużo więcej pracy było potrzebne do oprogramowania.

> Ale jeśli jest -- to chyba nie ma tam jednoczesności zdarzeń.

Zdarzania... z samej definicji nigdy nie są jednoczesne. Nie wiem o
jakie rozdzielczości mówimy. Czy pikosekundach, sekundach, godzinach? To
co w jednej sekundzie jest jednoczesne, to w 1ms już nie musi. Zresztą
nie wiem do czego zmierzasz.

> Albo
> inaczej -- mogą przywędrować jednocześnie zgłoszenia/przerwania, ale
> obsługę owych przerwań (; też przerwania ;) trzeba pokolejkować wg.
> prymitywnego algorytmu zwanego priorytetowaniem.

Nie doczytałeś czegoś w necie :-D Masz na myśli zapewne thread pooling.
Z tego korzystamy. Priorytetowanie to co innego i o tym dalej. Zadania
są kolejkowane i sekwencyjnie przydzielany jest im czas. Jeśli proces
nie zmieści się w przyznanym czasie, to jest przerywany, jego dane
odkładane są na stos, kolejny z procesów uruchamiany jest od punktu
zatrzymania, pobiera dane ze swojego prywatnego stosu i leci dalej. I
tak się kręci ta karuzela. W efekcie równocześnie realizowanych jest do
16 różnych zadań w sekwencyjnie przełączanych procesach. Zdarza się, że
zadanie, które zostało wyznaczone później kończy się wcześniej niż
obecnie trwające. Tak to działa. Każdy z procesów ma przypisane tylko 1
zadanie, które jest po kawałku realizowane i nie zabiera czasu innym
procesom.

W jednostce centralnej jest też priorytetowanie. W tych prostych
sterownikach nie było powodów do zawracania sobie głowy
priorytetowaniem. To jest kolejny mechanizm. W uzupełnieniu do w/w
proces o wyższym priorytecie musi się zakończyć aby te o niższym mogły
dokończyć swojego dzieła. Jak sama nazwa wskazuje - priorytet jest wręcz
zaprzeczeniem kolejkowania, wchodzi bez kolejki. Kolejkowanie o jakim
piszesz działa wśród procesów o jednakowym priorytecie wyłącznie.

Czy coś jeszcze chcesz wiedzieć? Dalej to już odpłatnie :-D

--
Pozdrawiam
Marek

do góry

Dnia 2014-05-15 13:42, *Eneuel Leszek Ciszewski* napisał, a mnie coś
podkusiło, żeby odpisać:
> prymitywnego algorytmu zwanego priorytetowaniem.

Na pocztę miałeś iść

--
Mirek Ptak
kolczan( a t )outlook(kropek) c om

do góry

"Marek" ll21ss$5au$...@n...news.atman.pl

>> Czym są 'systemy operacyjne czasu rzeczywistego' można
>> przeczytać bez trudu w necie.

> Widzisz... ty czytasz o tym w necie

Zanim dowiedziałem się o istnieniu internetu,
wiedziałem o takich systemach.

> co ja tworzyłem (nie zajmuję się tym obecnie). W zasadzie
>nie ja jako 1 osoba lecz grupa kilku pracowników uczelni.

Ciekawe, czy podpisaliby się pod tym, co tu prezentujesz. :)

>> Diabli wiedzą, skąd wzięło się fatalne utożsamianie:

>> 'w czasie rzeczywistym' == 'w czasie zerowym'

> Ja nie spotkałem się z takim sformułowaniem. Nie obracam się w Twoich kręgach.

Być może, choć ja akurat uważam, że obracasz się. :)

>> Marku -- nie gniewaj się, ale Twe myślenie (dotyczące
>> szybkości kart i pojemności buforów

> Sprawdź sobie w systemie Windows ile masz pamięci. Zapewne więcej niż RAM. Ciekawe
co?

Należy zapytać: 'czym jest pamięć'? HDD to także pamięć.
ROMy/PROMy/EPROMy -- także. Pamięć może być wirtualną pulą
adresów możliwa do obsłużenia przez procesor, która nie ma
(bądź ma) pokrycie w RAMkach.

>> oraz jednoczesności
>> zdarzeń) jest modelowym błądzeniem niemożliwym wręcz do
>> uznania za choćby prawdopodobne. Przyznaj się, że po
>> prostu robisz nas w bambuku i testujesz naszą cierpliwość. :)

> To raczej ja wykazuję się cierpliwością angażując się w niecelową
> konwersację. Proponuję EOT zanim dyskusja stanie się niemiła.
> Sam napisałeś, ze bazujesz na wiedzy netowej

Nie napisałem. :)

> w temacie RT więc nie bardzo mnie interesuje dyskusja z Tobą.
> Do tego ignorujesz logikę dyskusji nie przyjmując do wiadomości,
> że implementacja programistyczna czegokolwiek, w tym autorskiego
> systemu RT, zależy wyłącznie od programistów.

Ale akurat określenie RT ma swoją wartość
niezależną od tych konkretnych programistów. :)

> Jeśli mają potrzebę nie wdrażania jednego z wielu mechanizmów
> wykorzystywanych powszechnie w RT, to ich sprawa.

Niby tak, ale cechą systemu operacyjnego czasu
rzeczywistego nie jest współbieżność obsługi zdarzeń.


> O czym tu dyskutować? Piszę jak fizycznie zrealizowano coś
> w konkretnym urządzeniu a Ty w odpowiedzi zachęcasz autorów
> do poczytania w necie o podstawach RT. To jakiś absurd.










> O "wirtualnej" *) pamięci też nie słyszałeś i zamiast sobie
> poczytać to piszesz o tym, że robię Was w bambuko.

Słyszałem. Pierwszym komputerem, który zobaczyłem był komputer
z wirtualną pamięcią. Dopiero później zobaczyłem ZX Spectrum. :)


> W mojej interpretacji Twoja postawa jest w tym momencie
> trollowsko-infantylna, której celem jest przekomarzanie
> się itp. Też się nie obrażaj ale chciałem przedstawić
> moje odczucia w tej dyskusji.

Mnie nie można obrazić. Przegrałem nawet proces sądowy (który
bym wygrał, gdybym nie wycofał zarzutu o słowne znieważenie)
o obrażenie mnie.


> *) użyłem cudzysłów bo w przypadku cyfrówek miałem na myśli
> jedynie to, że równoległe zrzucanie bufora aparatu do SD
> i zapisywanie nowych zdjęć w to miejsce skutkuje w praktyce
> tym, że więcej klatek w szybkim trybie aparat jest zdolny
> wykonać niż bez obecności karty SD. Czyli bufor "wirtualnie"
> powiększył się. Im szybsza karta SD tym bardziej "powiększy
> się" wirtualnie bufor. W informatyce pamięć wirtualna wiąże
> się z możliwością jej adresowania - dlatego cudzysłów bo
> nie to miałem na myśli. Chyba po raz trzeci to piszę
> a z pewnością ostatni. Nie wykorzystasz tej szansy
> i nie zrozumiesz, trudno. Więcej prób nie będę podejmował.

Zrozumiałem. Od początku rozumiem, ale chciałem wiedzieć, jak duży
jest bufor,Chciałem policzyć, ile pstryknąłeś klatek, zanim wybrałeś
tę karte. Jeśli bufor mieści 2 sekundy a Ty testowałeś kilkanaście
kart, mamy:

(2s*12klatek/s)*kilkanaście

do czasu zapełnienia bufora, po czym mamy co najmniej dwie sekundy obliczania

(2s*xklatek/s)*kilkanaście

i każdy z tych pomiarów należy kilkakrotnie powtórzyć; powiedzmy że tylko 3 razy. :)

3((2s*12klatek/s)*k+(2s*xklatek/s)*k) gdzie k oznacza 'kilkanaście'.

Zakładasz, że karta odbiera 2.5 klatki na sekundę, zatem may cos takiego:

3((2s*12klatek/s)*k+(2s*2.5klatki/s)*k)

czyli jakoś tak

3((2*12)+(2*2.5))*kklatek

a wstawiając za k (czyli kilkanaście) powiedzmy 15, mamy:

45(24+5)*klatek
45*29*klatek
1305 klatek

Naprawdę Twój test pochłonął ponad 1300 klatek?...

-=-

Pamięć wirtualna w komputerze to pamięć istniejąca jedynie w adresach.
Program odwołuje się do tych wirtualnych adresów a odpowiednia część
komputera (raczej zintegrowana z resztą CPU) dokonuje przeadresowania
z adresów wirtualnych na lokalnie/chwilowo ważne adresy rzeczywiste.
W danej chwili dany adres wirtualny może zostać powiązany z takim
adresem rzeczywistym, w innym momencie ten sam adres wirtualny może
spotkać się z innym adresem rzeczywistym. Taki sposób adresowania
nazywany też jest chronionym, gdyż programy nie mogą się nawzajem
podglądać -- POKE. ;) Aby nie tracić zawartości zapisanej pod
adresem wirtualnym, gdy adres rzeczywisty zostanie zwolnionym,
zawartość tego adresu wirtualnego można przechować w innym,
zwykle tańszym miejscu, na przykład na HDD. Plik zawierający
takie zrzuty (przechowujący tymczasowo zawartość wirtualnych
adresów) nazywany jest powszechnie SWAPem. Przerzucaniem
zawartości ze SWAPu do RAMu i z powrotem zajmuje się tak
sprzęt/złom, jak i soft/system_operacyjny. Powszechne
PeCetowe procesory Intela od 80286 potrafią wspomagać
tryb chroniony, jednak DOS (system operacyjny dedykowany
tym komputerom -- PeCetom tamtych lat) tego nie oferował
**chyba** nigdy. Pamiętam, że jakoś był wykorzystywany już
wtedy ten wynalazek, ale nie pamiętam, jak dokładnie.
Irytowały wzmianki (w czasie uruchamiani) o istnieniu trybu chronionego.


Do napisania powyższego opisu nie służyły mi wieści czerpane z internetu. :)
W czasie pisania programów (na samym początku pisania) dowiedziałem się tego,
czym jest pamięć wirtualna a o tym, że AT (na 80286) oferuje sprzętowo tryb
chroniony, dowiedziałem się w parę lat po tym, jak zacząłem pisać, czyli
wtedy, gdy spotkałem się z ATem. AT oferował o wiele szerszy dostęp do
RAMek niż XT, co jednak w DOSie jedynie przygnębiało? :) Dawało szybkie
RAMdyski, o wiele szybsze i od HDD, i od innej (bardzo powolnej) konstrukcji
RAMdysków -- znanych mi z XTów. RAMdyski XTowe miały szybkość porównywalną
z szybkością dyskietek -- FDD.

Moje ,,kręgi'' to na przykład Deminet -- to IMO od niego
dowiedziałem się, czym jest 'czas rzeczywisty'. Od niego,
czyli z książki jego autorstwa.

-=-

Podtrzymuję, że jednoczesność/równobieżność nie jest cechą
znamienną/charakterystyczna systemów operacyjnych czasu
rzeczywistego.

-=-

Ponoć pierwszym procesorem x86 dającym równoległa prace był 80486.
O tej równoległości pracy dowiedziałem się tuz po pojawieniu się
tych procesorów, ale później szybko o tym powszechnie zapomniano. :)


Pamiętam tez ludzi szukających w tamtych latach programistów do
pisania procesów równobieżnych. Nie wiem, ani jakiego sprzętu,
ani jakiego softu (jakich systemów) zamierzali używać, ale
pamiętam, że na samym początku zapewnili nas (mnie i ludzi,
którzy razem ze mną tam zgłosili się) że zamierzają dobrze
nam płacić za naszą pracę. Ludzi -- może źle powiedziane,
bo rozmawialiśmy z jedną panią, jąkającą się jak Michnik. :)


Choć zapewne nie warto, jednak napiszę, że jąkanie moich
rozmówców nie przeszkadza mi, albo przeszkadza tak, jak
przeszkadzają okulary moich rozmówców czy ich aparaty
słuchowe... :)

-=-

System, od którego zaczynałem nazywał się RSX11M.
Miał chorągiewki, którymi regulował ruch, gdy któraś
z czynności musiała zaczekać na efekt innej a system
zezwalał na jednoczesną pracę różnych urządzeń.

Można było zlecić kilka czynności tak, że bez potwierdzenia
którejś (podnoszącej chorągiewkę/flagę) nie można było
puścić w ruch kolejnej.

RSX11M był wieloużytkownikowym systemem operacyjnym czasu rzeczywistego
operującym na wirtualnej pamięci. Taki model systemu był dla mnie równie
oczywistym/intuicyjnym/normalnym/zwyczajnym, jak język polski dla Polaka,
który wychowywał się w Polsce, wśród ludzi używających TYLKO języka polskiego.

Ja nazywałem to chorągiewkami inni -- flagami. :)


Tłumaczenie mi zawiłości: wirtualnej pamięci, SWAPu, trybu chronionego,
jednoczesnego używania systemu przez wielu użytkowników, czasu
rzeczywistego itp. jest równie ciekawe, jak tłumaczenie mi zawiłości
języka polskiego przez Chińczyka, który od niedawna uczy się tego
(jakże ciekawego) języka... ;)

Tak właśnie wyglądało tłumaczeni mi VM dawane przez PPalusińskiego.
Podobnie -- tłumaczenie dawane przez GNiemirowskiego dotyczące
transakcyjności NTFS. MKaweckiego pomijam, bo on nie uczył się
NTFSu nawet jako Chińczyk balujący w Polsce. ;)

-=-

Choć tak wygląda adresacja w RSX11M, mój ostatni program ,,mylił'' ;)
pamięć przeznaczona na dane/kod_programu z pamięcią przeznaczona na
zmienne programu. Pewna część tego programu na samym początku pracy
weryfikowała poprawność wczytywanego pliku (ja nazywałem go słowniekiem)
i po tym sprawdzeniu była bezużyteczna aż do końca pracy programu,
okupując jednak miejsce, którego system nie zwracał, choć mógł
zauważyć, że nie ma tam powrotu. :)

Tę część wykorzystałem tak, że bufor na liczbę integer kończył się
zbyt wcześnie, przez co pewne odwołania mogły wchodzić poza tę
liczbę -- i wchodziły właśnie w to niepotrzebne już miejsce.

Deklaracja:

Integer I(100)

ale podczas pracy programu pojawiają się
instrukcje typu

I(200)=J

Całość rzecz jasna pod kontrolą -- moją. :) Był to
ostatni mój program pisany na tym komputerze. I zarazem
był to program służący pisaniu na tym komputerze, bo był
to edytor do szybkiego pisania programów. :) Panowałem
nad niemal całym miejscem niepotrzebnego mi kodu -- nad
całym, poza ostatnim bajtem, którego nie udało się mi
okiełznać, gdyż komputer uległ (niemal na moich oczach)
rozkładowi, żeby nie powiedzieć -- dewastacji. :)

Prawdziwego rozłożenie dokonałem osobiście,
już jako pracownik opłacany przez uczelnię.

-=-

Popędliwym przypomnę, że przepełnienie bufora to
obecny sztampowy sposób wpuszczania szkodników.
Ja przepełniałem bufor celowo i świadomie.

Inna sprawa, że zanim do tego doszedłem, pisałem
programy w deklaracjach których miałem Integer(1)
a w programie były odwołania do różnych miejsc
owej zmiennej, ale leżących nadal w segmencie
poświęconym zmiennym.

Innymi słowy dochodziłem ;) do mego ostatniego programu drobnymi krokami.

Wiele moich programów ogóle nie miało normalnych deklaracji zmiennych. :)

Do ,,oflagowania'' doszło niewielu z moich ówczesnych znajomych.
(znam tylko dwie osoby)
Do IV Fortranu z plusem -- chyba tylko ja z białostoczan. :)
Zezwalał na numerację od zera -- zerowy element macierzy,
pierwszy itd. Upraszczało to pisanie. Późniejsze języki
chyba dawały od razu numerację zaczynająca się od zera.

-=-

Reasumując -- coś słyszałeś o systemach czasu rzeczywistego,
ale nie wiesz, którym uchem. ;) (czy wewnętrzny, czy środkowym,
czy wirtualnym) Wyjaśnienie obsługi (przez system RT) nadchodzących
zdarzeń nie jest trudne. (o ile samemu pisze się te programy)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Mirek Ptak" 5374b44d$0$2242$6...@n...neostrada.pl

> Na pocztę miałeś iść

Sam to zauważam. Matka mi nawet tam pracę wtedy załatwiła. :)
Ale ja poszedłem do pracy innej. I diabli wiedzą, czy źle
uczyniłem, czy dobrze. Katedra Fizyki dała pracę nie przy
pisaniu pod RTOS, ale przy prymitywnej wówczas sieci
NetWare firmy Novell.

Z czasem tak mocno zgłupiałem jako administrator, że
aż mi żal samego siebie. Moje dawne wyczyny puszczono
w niepamięć i zagoniono mnie do niewolniczej pracy
durnowatego, tępego administratora. Chciałem ściągnąć
swoich znajomych, aby móc oddać się rozkoszom pisania,
ale zamiast tego, zleciałem jeszcze głębiej, w niższe
i mroczniejsze głębiny potwornego szeolu...


Ale miałem ambitne plany -- chciałem zarobić, zbudować
własne sieci, odzyskać zmarnowanych (jak ja, lub nawet
gorzej!) ludzi i zbudować (za zarobione pieniądze) szkołę. :)
Zatrudniłbym w niej tych, którzy lubią pisać -- książki
piękne jak baśnie (czyli takich, jak JDeminet) i programy
proste jak cepy...

-=-

Pieniądze lały się strumieniami -- budowa sieci komputerowych
nie była zbyt ryzykowna, a mając te sieci, nie byłbym już przez
nikogo powstrzymywany, ale odwrotnie -- nakręcany! Nakręcany
przez tych, którzy choć z tytułami i kropkami (prof. -- to
kropka) nie zarabiali zbyt wiele. Gdy zyski sięgnęły
10kpln/dzień_roboczy, piękna rzeczywistość zamieniła
się w koszmar. :) Próby odzyskania choć części tego,
co kiedyś kochałem -- grzebali starannie ci, których
tak mocno kiedyś kochałem!

-=-

Idę na Pocztę. ;) Ludzie listy [płac/płaczu] piszą... ;)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

W dniu 2014-05-15 14:57, Eneuel Leszek Ciszewski pisze:

>
>> Sprawdź sobie w systemie Windows ile masz pamięci. Zapewne więcej niż
>> RAM. Ciekawe co?
>
> Należy zapytać: 'czym jest pamięć'?

Już napisałem poniższe, więc nie będę kasował. Niżej wyjaśniłeś, że
pojąłeś o co mi chodzi.


Brawo! Więc zaczynasz doceniać priorytet utworzenia definicji pojęcia
przed rozpoczęciem dyskusji o nim? Skoro tak, to już jesteśmy na dobrej
drodze do sukcesu. Więc teraz zadajmy pytanie czym jest bufor pamięci w
aparacie cyfrowym z punktu widzenia fotografującego, który o elektronice
nie ma pojęcia. A jest miejscem, które limituje ilość zrobionych w
szybkiej serii zdjęć. No i teraz delikwent stwierdza, że po włożeniu
karty SD nagle bufor zaczął mu mieścić np. 4 klatki więcej. Mało tego,
włożył on potem np. 2x szybszą kartę (nawet o mniejszej pojemności) i
nagle okazało się, że już 6 klatek więcej mieści bufor niż pierwotnie
było. Czyli bufor wirtualnie urósł! Prawda?

Nie wiem czemu nie dostrzegasz tego zjawiska. Właśnie ten "wirtualny"
przyrost określiłem buforem "wirtualnym". Czego się tu czepiać?

>
> Ale akurat określenie RT ma swoją wartość
> niezależną od tych konkretnych programistów. :)

Ok, więc ja i koledzy byliśmy wyklętymi programistami :-) Czyniliśmy
zabobony łamiąc porządek tego świata :-D

> Zrozumiałem. Od początku rozumiem, ale chciałem wiedzieć, jak duży
> jest bufor,

To skąd Twoja potrzeba ironicznego komentowania moich twierdzeń co do
"wirtualnego" zwiększenia pojemności bufora za pomocą karty SD?

A co do wielkości bufora to szukałem w międzyczasie informacji.
Producent nie podaje. Pewnie eksperymentalnie można to tylko zbadać.
Nigdy mnie to jednak nie interesowało za bardzo gdyż bufor jest dość
pojemny i w prawie wszystkich sytuacjach wystarcza z nawiązką.

> Chciałem policzyć, ile pstryknąłeś klatek, zanim wybrałeś
> tę karte. Jeśli bufor mieści 2 sekundy a Ty testowałeś kilkanaście
> kart, mamy:

Tak, domyślałem się jak chcesz to liczyć. W sieci byli już tacy, co tak
liczyli. Zawsze bez konkluzji bo wychodziły sprzeczne wyniki.

Trafiłem też na dyskusję, gdzie mierzono czas opróżniania się bufora i
to na karcie jakiej używam. Komuś wyszedł transfer 38MB/s. Natomiast gdy
wsadzono tą samą kartę 45M, czyli z pewnym zapasem, to transfer znacząco
spadł. Ktoś inny testował to na karcie Sony z podobnymi zależnościami.
Nie da się na tej podstawie szacować szybkości transferu ani wielkości
bufora. Aparat ewidentnie coś jeszcze przetwarza.

> Naprawdę Twój test pochłonął ponad 1300 klatek?...

Nie. Sądzę, ze z połowę tego i był dużo bardziej optymalny niż
zaproponowałeś. Wcisnąłem spust, czekałem aż się bufor zatka i słuchałem
z jaką częstotliwością robione są kolejne klatki. Wybrałem kartę
najszybszą, bo różnice były ogromne dla różnych kart.

> Pamięć wirtualna w komputerze to pamięć istniejąca jedynie w adresach.

Cytujesz moje słowa. Tu ucinam bo dalej poszły oczywistości. Nie ma
czego komentować.

>
> Reasumując -- coś słyszałeś o systemach czasu rzeczywistego,
> ale nie wiesz, którym uchem. ;) (czy wewnętrzny, czy środkowym,
> czy wirtualnym) Wyjaśnienie obsługi (przez system RT) nadchodzących
> zdarzeń nie jest trudne. (o ile samemu pisze się te programy)
>

Ok, więc całkiem przypadkiem udało nam się w ten sposób oprogramować
centralę telefoniczną, w tym międzymiastową pracującą do dziś. Niewiedza
matką wynalazków :-D

--
Pozdrawiam
Marek

do góry

"J.F" 53740da9$0$2372$6...@n...neostrada.pl

>>Znasz ceny tych kart? Maksymalna pojemność to 64 GB. I po co ludziom HDD?

> No, jak komus sie marzy 1TB, czy nawet
> 500GB, to troche drogo karty wychodza.

IMO ceny mogą szybko schodzić w milsze rjony. :)

> I kontrolera raid5 na powiedzmy 9 takich kart nie widzialem .. a szkoda, bo wtedy
chyba nawet nie musialyby byc szybkie.

Kontrolery raidowe także mogą powstać. :)

> Tylko ze pewnie klient moze to kupic w postaci "dysku" SSD.

Nośnik SSD nie zawiera chyba wymiennych części a raid5
słynie z możliwości podmiany padniętej części macierzy.
{nie pamiętam, co z ojczyzną/ojcowizną...]

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Alf/red/" ll1lnd$pd3$...@n...news.atman.pl

> Ale to się kłóci co do zasady. Zaletą wykonania pamięci
> w postaci karty SD są jej malutkie wymiary, dokładając
> kontroler tracimy to. Lepiej zastosować właśnie dysk
> SSD (albo kilka w raidzie, a co). Chyba że dla udowodnienia, że można.

A zaletą raid5 jest odporność na awarie.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Marek" ll2c5l$fg1$...@n...news.atman.pl

>>> System operacyjny o jakim pisałem, jest naszym autorskim (grupa kilku
>>> osób). Wiemy doskonale czy braliśmy pod uwagę proiorytetowanie
>>> przerwań czy nie. W przypadku końcówek wykonawczych nie było takiej
>>> potrzeby

>> Bo każda z nich może (albo nie może) wykonać tylko jedno zadanie? ;)

> Nie, 8 lub 16 zadań konkretnie bo tyle portów ma każda z tych końcówek.



> Zdarzania... z samej definicji nigdy nie są jednoczesne. Nie wiem o


Jednocześnie masa ludzi czyta ten sam tekst.
Jednocześnie pada deszcz i szumi wiatr.
System zleca coś kilku urządzeniom -- a one wykonują
to w tym samym czasie, choć niekoniecznie momenty
rozpoczynania pracy pokrywają się ze sobą i momenty
zakończenia pracy pokrywają się ze sobą.

Gdy urządzenia wykonAją pracę, mogą zwrócić systemowi wynik.
Mogą jednocześnie, mogą niejednocześnie. Jedno może nadal
zwracać (bo wszystko trwa) gdy tymczasem innemu zechce
się zwrócić.

Wówczas trzeba albo przydzielać kwant czasu każdemu urządzeniu,
albo spriorytetować zgłoszenia, ustawiając je w kolejkę (takie
urządzenia mają pierwszeństwo przed takimi -- czyli
priorytetowanie przerwań) albo jeszcze inaczej (sposobów
można znaleźć całą masę) rozwiązać ów problem.

Obok priorytetowania przerwań jest także priorytetowanie
zadań wykonywanych przez system. I tu także każdemu procesowi
można wydzielić kwant czas, można spriorytetyzować zadania,
można wymyślić masę różnych rozwiązań.


> jakie rozdzielczości mówimy. Czy pikosekundach, sekundach, godzinach? To co w
jednej sekundzie jest jednoczesne, to w 1ms już nie
> musi. Zresztą nie wiem do czego zmierzasz.


Jak widzisz -- można coś obsługiwać zupełnie współbieżnie:

Konduktror w pociągu sprawdza bilety.
Maszynista prowadzi pociąg.
Telegrafista utrzymuje łączność.




Jedna pani drugiej pani opowiada o tym, jak to jeden pan z drugim panem itd.
Inna pani obserwuje mijaną właśnie okolicę.
Jeszcze ktoś inny zajmuje się dzieckiem lub wiąże sznurowadła.
Albo czyta książkę lub dłubie w nosie.


Równoczesność zdarzeń towarzyszy nam stale.

Ludzie (ich praca) pierwszej grupy są potrzebni do pracy
pociągu, ludzie wymienieni później są potrzebni_inaczej.
Obok opisanych zdarzeń -- współbieżnie funkcjonuje masa
innych zdarzeń na zewnątrz pociągu. Jedne z nich są
ignorowane przez pracowników, ale nie są ignorowane
przez pasażerów, inne są ignorowane przez wszystkich,
jeszcze inne są obsługiwane przez pracowników i pasażerów...






>> Albo
>> inaczej -- mogą przywędrować jednocześnie zgłoszenia/przerwania, ale
>> obsługę owych przerwań (; też przerwania ;) trzeba pokolejkować wg.
>> prymitywnego algorytmu zwanego priorytetowaniem.

> Nie doczytałeś czegoś w necie :-D

Czego nie doczytałem?

> Masz na myśli zapewne thread pooling. Z tego korzystamy. Priorytetowanie to co
innego i o tym dalej. Zadania są kolejkowane i
> sekwencyjnie przydzielany jest im czas. Jeśli proces nie zmieści się w przyznanym
czasie, to jest przerywany, jego dane odkładane
> są na stos, kolejny z procesów uruchamiany jest od punktu zatrzymania, pobiera dane
ze swojego prywatnego stosu i leci dalej. I
> tak się kręci ta karuzela. W efekcie równocześnie realizowanych jest do 16 różnych
zadań w sekwencyjnie przełączanych procesach.

Nic nadzwyczajnego.

> Zdarza się, że zadanie, które zostało wyznaczone później kończy się wcześniej niż
obecnie trwające.


Nadal nic nadzwyczajnego.

> Tak to działa. Każdy z procesów ma przypisane tylko 1 zadanie, które jest po
kawałku realizowane i nie zabiera czasu innym
> procesom.

A tego już nie pojmuję. Co to proces, co to zadanie itd.


> W jednostce centralnej jest też priorytetowanie. W tych prostych sterownikach nie
było powodów do zawracania sobie głowy
> priorytetowaniem. To jest kolejny mechanizm. W uzupełnieniu do w/w proces o wyższym
priorytecie musi się zakończyć

Nie musi. Jeśli zadane ma lepszy priorytet, ale nie
może wykonywać się (na przykład czeka na jakiś sygnał
z zewnątrz -- choćby na wprowadzenie litery) wówczas
proces taki ustąpić powinien miejsca innym procesom,
choć ma od nich lepszy priorytet.


Nie piszę wyższy priorytet i niższy priorytet, bo
u jednego proces z priorytetem nazwany liczbą
0 (zero) ma pierwszeństwo przed wszystkimi innymi,
a u innego najwyższa liczba ma pierwszeństwo przed
innymi, mniejszymi.

> aby te o niższym mogły dokończyć swojego dzieła. Jak sama nazwa wskazuje -
priorytet jest wręcz zaprzeczeniem kolejkowania,
> wchodzi bez kolejki. Kolejkowanie o jakim piszesz działa wśród procesów o
jednakowym priorytecie wyłącznie.

Gdy każdy proces ma ten sam priorytet -- procesy po prostu dostają
po kwancie czasu. Gdy priorytety są różne -- jest ustanowiona kolejka.

====================================================
===========
|| Ale ja akurat pisałem o priorytetowanu przerwań (gdyż chyba
|| właśnie od tego zaczęło się to priorytetowanie w tym wątku)
|| nie o priorytetowaniu zadań wykonywanych przez CPU. Przerwań
|| w sensie zdarzeń nadchodzących z zewnątrz. (IRQ)
====================================================
===========

> Czy coś jeszcze chcesz wiedzieć? Dalej to już odpłatnie :-D

Wybacz, ale gdybyś nawet mi płacił, nie chciałbym Twojej nauki. :)
Chyba, że płaciłbyś sporo i nie nakazywał słuchania. ;)

Centralkę telefoniczną mogłeś **razem z kimś** napisać, ale
sam raczej byś jej nie napisał? Zapewne pokaleczyłbyś się,
co nakłoniłoby Cię do pokory i po jakimś czasie napisałbyś
centralkę samodzielnie. Ja bym z Tobą nie chciał pisać. :)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

W dniu 2014-05-16 14:08, Eneuel Leszek Ciszewski pisze:

>
> Gdy urządzenia wykonAją pracę, mogą zwrócić systemowi wynik.
> Mogą jednocześnie, mogą niejednocześnie. Jedno może nadal
> zwracać (bo wszystko trwa) gdy tymczasem innemu zechce
> się zwrócić.

Dlatego pytałem o rozdzielczość czasu jaka mamy przyjąć i czy pod uwagę
bierzemy proces czy zadanie, które może wymagać wielokrotnego
zadziałania danego procesu. W technice cyfrowej wszystko jest
skwantyzowane.

> Wówczas trzeba albo przydzielać kwant czasu każdemu urządzeniu,
> albo spriorytetować zgłoszenia, ustawiając je w kolejkę (takie
> urządzenia mają pierwszeństwo przed takimi -- czyli
> priorytetowanie przerwań) albo jeszcze inaczej (sposobów
> można znaleźć całą masę) rozwiązać ów problem.

Już o tym rozmawialiśmy nawet w detalach jak fizycznie coś tam było
implementowane w oparciu o powyższe. Po co do tego wracasz?

> Równoczesność zdarzeń towarzyszy nam stale.

Hmmm... A całkiem niedawno nabijałeś się gdy użyłem identycznego
sformułowania...

>
>> Masz na myśli zapewne thread pooling. Z tego korzystamy. (...)
>
> Nic nadzwyczajnego.

Rany... Całkiem do niedawna nazywałeś to nabijaniem w butelkę albo jakoś
tak. A teraz jest to nic nadzwyczajnego.

>> Zdarza się, że zadanie, które zostało wyznaczone później kończy się
>> wcześniej niż obecnie trwające.
>
> Nadal nic nadzwyczajnego.

Normalnie odwracasz kota ogonem w każdym zdaniu. Gdy twierdziłem, że coś
jest czarne, to Ty, że białe i ze jaja sobie robię. A teraz stwierdzasz,
że to co parę razy próbowałem przekazać i co wyśmiewałeś staje się
niczym nadzwyczajnym.

>> Tak to działa. Każdy z procesów ma przypisane tylko 1 zadanie, które
>> jest po kawałku realizowane i nie zabiera czasu innym procesom.
>
> A tego już nie pojmuję. Co to proces, co to zadanie itd.

Zadanie to np. monitorowanie abonenta w centrali telefonicznej. Proces
to techniczna implementacja polegająca, że coś w pętli się odbywa z
podziałem czasowym. Zadanie (może inne słowo...cel?) jest ciągłe i
równoczesne (bo wiele z nich jest wykonywanych w jednym wyposażeniu
abonenckim) a od strony technicznej odbywa się to w naprzemiennych
procesach. Innymi słowy: procesy realizują zadania. W tym sensie używam
w naszym wątku pojęcia zadania.

>> W jednostce centralnej jest też priorytetowanie. W tych prostych
>> sterownikach nie było powodów do zawracania sobie głowy

> Wybacz, ale gdybyś nawet mi płacił, nie chciałbym Twojej nauki. :)
> Chyba, że płaciłbyś sporo i nie nakazywał słuchania. ;)
>
> Centralkę telefoniczną mogłeś **razem z kimś** napisać, ale
> sam raczej byś jej nie napisał?

Napisałbym ale zajęłoby mi to zbyt wiele czasu. Jedna osoba tworzyła
"system operacyjny", inna oprogramowywała sterowniki końcówek
abonenckich, inna projektowała elektronikę. Ja zajmowałem się jednostką
centralną (assembler i C++) - czyli zbieranie informacji z końcówek,
komutacja abonentów, wszelkie usługi abonenckie, taryfikacja oraz
zrządzanie projektem. Jeszcze inne osoby rozliczenia (pod Windows) itp.

> Zapewne pokaleczyłbyś się,
> co nakłoniłoby Cię do pokory i po jakimś czasie napisałbyś
> centralkę samodzielnie.

Spokojnie, dałbym radę.

> Ja bym z Tobą nie chciał pisać. :)
>

Bez obaw, z pewnością nie zaprosiłbym Cię do grupy :-)

Proponuję EOT bo teraz jakaś paranoja z tego wątku się robi. Miało być o
szybkiej karcie SD. Ja wymiękam.

--
Pozdrawiam
Marek

do góry