W dniu 2015-07-29 12:35, M.M. pisze:
> On Wednesday, July 29, 2015 at 12:10:56 PM UTC+2, Piotr Chamera wrote:
>> a "ekstremalna sytuacja", to rzeczywisty efekt działania takiego
>> nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
>> wyborów.
> Rozmawiamy o jednym elemencie tego systemu: zbieranie danych.
>
>>> Zaczęli projektować i skopali, jakby po prostu zrobili
>>
>> to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
>> jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
>> rzeczy wymaga przemyślenia i zaprojektowania).
> Jak pisałem kilka postów wcześniej: nie dziwię się że padło jako
> całość. Dziwię się, że stracili dane, że trzeba było wprowadzać od
> nowa, że czekali aż tak długo... i nie wiem jakie tam jeszcze były problemy.
>
>>
>>> 1) połączenie
>>
>> obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
>> więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
>> zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
>> danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
>> robimy z nadmiarowymi? itd...
> Co masz na myśli, pisząc 'itd'? Nie znam specyfikacji tegoż systemu.
> Uczepiłem się tych 2500 paczek danych na 3600 sekund, co nie wydaje się
> zbytnio trudne. Jaki średni rozmiar miała paczka? Jeśli mamy ograniczoną
> pulę połączeń, to co jest złego w odrzuceniu?

Nie paczek danych a połączeń, to jakby co innego. Paczki danych to jakby
najmniejszy składnik całości, kwestia jest przyjąć właśnie te połączenia
i obsłużyć, a nie ile danych trzeba przesłać.


>> na dalszych etapach masz podobne wybory, które wpływają na przyjęte
>> rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
>> nie prowadziła do awarii...
> Zgodzę się, że zgranie każdego, w pobieżnej ocenie 'łatwego', systemu w
> jedną niezawodną całość, może okazać się bardzo trudne. Ale żeby padło na
> etapie zbierania danych i straciło spójność, jakoś wydaje mi się dziwne.

A oprogramowywałeś jakieś większe bazy danych? Coś co musi trzymać
spójność i dane dla bezpieczeństwa powinny być w kilku tabelach
zapisane? Coś do czego dobija się więcej osób jednocześnie?


--
Kaczus
http://kaczus.cba.pl

do góry

On Wednesday, July 29, 2015 at 12:44:18 PM UTC+2, Tomasz Kaczanowski wrote:
> W dniu 2015-07-29 12:35, M.M. pisze:
> > On Wednesday, July 29, 2015 at 12:10:56 PM UTC+2, Piotr Chamera wrote:
> >> a "ekstremalna sytuacja", to rzeczywisty efekt działania takiego
> >> nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
> >> wyborów.
> > Rozmawiamy o jednym elemencie tego systemu: zbieranie danych.
> >
> >>> Zaczęli projektować i skopali, jakby po prostu zrobili
> >>
> >> to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
> >> jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
> >> rzeczy wymaga przemyślenia i zaprojektowania).
> > Jak pisałem kilka postów wcześniej: nie dziwię się że padło jako
> > całość. Dziwię się, że stracili dane, że trzeba było wprowadzać od
> > nowa, że czekali aż tak długo... i nie wiem jakie tam jeszcze były problemy.
> >
> >>
> >>> 1) połączenie
> >>
> >> obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
> >> więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
> >> zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
> >> danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
> >> robimy z nadmiarowymi? itd...
> > Co masz na myśli, pisząc 'itd'? Nie znam specyfikacji tegoż systemu.
> > Uczepiłem się tych 2500 paczek danych na 3600 sekund, co nie wydaje się
> > zbytnio trudne. Jaki średni rozmiar miała paczka? Jeśli mamy ograniczoną
> > pulę połączeń, to co jest złego w odrzuceniu?
>
> Nie paczek danych a połączeń, to jakby co innego. Paczki danych to jakby
> najmniejszy składnik całości, kwestia jest przyjąć właśnie te połączenia
> i obsłużyć, a nie ile danych trzeba przesłać.
Tak, w ścisłym sensie masz oczywiście rację, ale jeśli połączenie (na
etapie zbierania danych) nie jest w głównej mierze 'paczką danych', to
może właśnie dlatego padło?



> >> na dalszych etapach masz podobne wybory, które wpływają na przyjęte
> >> rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
> >> nie prowadziła do awarii...
> > Zgodzę się, że zgranie każdego, w pobieżnej ocenie 'łatwego', systemu w
> > jedną niezawodną całość, może okazać się bardzo trudne. Ale żeby padło na
> > etapie zbierania danych i straciło spójność, jakoś wydaje mi się dziwne.
>
> A oprogramowywałeś jakieś większe bazy danych? Coś co musi trzymać
> spójność i dane dla bezpieczeństwa powinny być w kilku tabelach
> zapisane? Coś do czego dobija się więcej osób jednocześnie?
Poczekaj. Mieszanka pobierania danych, parsowania, normalizacji, dbania
o spójność i zapisywania w bazie jest najgorszym kodem spageti w najbardziej
krytycznym miejscu.

Dla mnie zbieranie danych to zbieranie danych. Jest takie powiedzenie, że
najprostsze rozwiązania działają najlepiej. Jeśli nie miesza się zbierania
danych z całą resztą, to można zbieranie danych oprogramować w miarę
prostym, niezawodnym i wydajnym kodem. I to wszystko można zrobić na
bazie gotowych narzędzi, jak choćby mysqla.

A jeśli w jednym połączeniu chcemy obsłużyć 'wszystko', to co w tym dziwnego, że
nawet wybitna grupa specjalistów źle wyliczyła obciążenie i system padł, no i
padł w momencie bardzo krytycznym dla bezpieczeństwa danych.







>
>
> --
> Kaczus
> http://kaczus.cba.pl

do góry

Dnia 29.07.2015 Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> napisał/a:
>> Ale to i tak nie jest duzy ruch.
>> Poza tym nie przesadzajmy ze w tym samym czasie - moze w ciagu 2-3 godzin
>> ale to dla komputerów nie jest przeciez ten sam czas.
>
> Chyba nie pracowałeś w komisji - ok 80-90% komisji będzie próbowało
> połączyć się w tej samej godzinie. Mamy ok 3tys komisji (z tego co
> pamiętam)

Tylko skoryguję, około 3tys. to było okręgów wyborczych, a obwodów
wyborczych (lokali wyborczych w których są komisje obwodowe) było ponad 20
tysięcy.

do góry

On Wednesday, July 29, 2015 at 3:31:35 PM UTC+2, Pit wrote:
> Dnia 29.07.2015 Tomasz Kaczanowski napisał/a:
> >> Ale to i tak nie jest duzy ruch.
> >> Poza tym nie przesadzajmy ze w tym samym czasie - moze w ciagu 2-3 godzin
> >> ale to dla komputerów nie jest przeciez ten sam czas.
> >
> > Chyba nie pracowałeś w komisji - ok 80-90% komisji będzie próbowało
> > połączyć się w tej samej godzinie. Mamy ok 3tys komisji (z tego co
> > pamiętam)
>
> Tylko skoryguję, około 3tys. to było okręgów wyborczych, a obwodów
> wyborczych (lokali wyborczych w których są komisje obwodowe) było ponad 20
> tysięcy.

To stanowi 'lekką' różnicę. 20tys * 1s to już jest trochę więcej niż
godzina. Obsłużenie w ciągu 0.1s nie zawsze jest możliwe, ale na 10
komputerach powinno śmigać.

do góry

Dnia 29.07.2015 M.M. <m...@g...com> napisał/a:
> On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera wrote:
>> W dniu 2015-07-29 o 09:42, M.M. pisze:
>> > On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
>> >> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
>> >> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
>> >> były niespójne.
>> > Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
>> > ekstremalnej sytuacji.
>>
>> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną sytuację"...
> Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać, nie
> wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas ktoś
> oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie widzisz
> ekstremalną sytuację?
>
> Zaczęli projektować i skopali, jakby po prostu zrobili
> 1) połączenie
> 2) transfer
> 3) zapis
> 4) rozłączenie
> To pewnie by wytrzymało, zwłaszcza na kilku komputerach.

Niestety to tak banalnie nie działa, bo jest do tego jeszcze ustawa o
ordynacji wyborczej. W skrócie protokół wędruje mniej więcej tak:
1) Obwód robi swoje podsumowanie głosów i wysyła do "centrali" protokół
roboczy.
2) Centrala weryfikuje dane i wysyła do obwodu swój protokół jakie dane
odebrała od obwodu i ewentualne poprawki.
3) Jeśli były jakieś błędy/poprawki lub dane odebrane nie są zgodne z
danymi wysłanymi przez komisję, to powrót do punktu 1)
4) Komisja obwodowa zatwierdza protokół otrzymany "z centrali" że jest
wszystko ok, robi wydruk protokołu i składa na nim swoje podpisy (koniec
drogi elektronicznej).

To nie jest zwyczajna akumulacja danych (typu wyślij i zapomnij), bo do
takich rzeczy w ogóle nie trzeba by było bazy "live", wystarczyłby system
podobny do e-maili (gdzie serwer sobie ustawia kolejeczkę i w swoim tempie
wszystko przetwarza). To nie jest tak, że jak teraz wcisnę "SEND" to mogę
czekać godzinkę aż serwer przemieli, bo taką ma kolejkę, wynik powinien być
zwrcony w rozsądnym czasie (maksymalnie kilka sekund). No i tych zapytań do
bazy jest znacznie więcej niż jednorazowe INSERT INTO a i obwodów jest
więcej niż ktoś tam wyżej podał.

do góry

Dnia 29.07.2015 M.M. <m...@g...com> napisał/a:
> Dla mnie zbieranie danych to zbieranie danych. Jest takie powiedzenie, że
> najprostsze rozwiązania działają najlepiej. Jeśli nie miesza się zbierania
> danych z całą resztą, to można zbieranie danych oprogramować w miarę
> prostym, niezawodnym i wydajnym kodem. I to wszystko można zrobić na
> bazie gotowych narzędzi, jak choćby mysqla.
>
> A jeśli w jednym połączeniu chcemy obsłużyć 'wszystko', to co w tym dziwnego, że
> nawet wybitna grupa specjalistów źle wyliczyła obciążenie i system padł, no i
> padł w momencie bardzo krytycznym dla bezpieczeństwa danych.


Ordynacja wyborcza jest jaka jest. Na zwykłe zbieranie danych, to sobie
mogą pozwolić firmy zajmujące się sondażami wyborczymi. W świecie
rzeczywistym ta "paczka danych" to jest protokół roboczy komisji obwodowej,
który musi być na bieżąco sprawdzony pod kątem spójności danych i jego
przyjęcie jest potwierdzane kolejnym protokołem, w którym komisja obwodowa
dostaje informację "co centrala od nich dostała" - w obwodzie te dwa
protokoły (wysłany i odebrany) się porównuje i jeśli wszystko jest ok, to
się ten protokół odebrany "zatwierdza" jako ostateczny (a jeśli się
okazało, że były jakieś błędy, na przykład komisja obwodowa gdzieś zrobiła
błąd w dodawaniu, to cały cyrk zaczyna się od początku). To ma działać w
czasie rzeczywistym, czyli komisja obwodowa od razu musi dostać informację
czy wszystko jest ok i czy może podpisać ostateczną wersję protokołu,
wywiesić ją na zewnątrz lokalu wyborczego, odwieźć worki z kartami do
głosowania i iść do domu.

do góry

Dnia 29.07.2015 szemrany <s...@o...off> napisał/a:
> Możesz się nie zgadzać, ale:
> a) pieniądz idzie natychmiast, bo każdy z tych pośredników ma rachunki we
> wszystkich obsługiwanych bankach i klient robiąc przelew z np. ING na PKO
> robi de facto do ichniego ING, a oni ze swojego PKO do odbiorcy docelowego
> - online.

Tak, jasne, operator takich systemów płatności trzyma sobie po prostu
zamrożoną kase na kontach (jeśli ja wpłacam na ING powiedzmy 500PLN, to ten
operator musi mieć 500PLN "wolnej gotówki" na koncie PKO aby móc Ci od razu
wypłacić). W praktyce jest tak, że Ty dostajesz od razu info, że ja
wpłaciłem, ale kasę na koncie w PKO "zobaczysz" dobiero gdy przejdą
Elixiry.

> b) kompletnie mnie czy Kowalskiego jako klienta nie obchodzi mechanizm
> działania tylko efekt, robię przelew i po 15 sekundach jest u odbiorcy na
> koncie. Koniec tematu. Wszyscy zadowoleni.

Nie, przelew nie jest po 15 sekundach. Po 15 sekundach jest tylko
informacja, że Ty wpłaciłeś kasę.

do góry

On Wed, 29 Jul 2015 13:47:27 +0000 (UTC), Pit wrote:

>> Zaczęli projektować i skopali, jakby po prostu zrobili
>> 1) połączenie
>> 2) transfer
>> 3) zapis
>> 4) rozłączenie
>> To pewnie by wytrzymało, zwłaszcza na kilku komputerach.
>
> Niestety to tak banalnie nie działa, bo jest do tego jeszcze ustawa o
> ordynacji wyborczej. W skrócie protokół wędruje mniej więcej tak:
> 1) Obwód robi swoje podsumowanie głosów i wysyła do "centrali" protokół
> roboczy.
> 2) Centrala weryfikuje dane i wysyła do obwodu swój protokół jakie dane
> odebrała od obwodu i ewentualne poprawki.
> 3) Jeśli były jakieś błędy/poprawki lub dane odebrane nie są zgodne z
> danymi wysłanymi przez komisję, to powrót do punktu 1)
> 4) Komisja obwodowa zatwierdza protokół otrzymany "z centrali" że jest
> wszystko ok, robi wydruk protokołu i składa na nim swoje podpisy (koniec
> drogi elektronicznej).
>
> To nie jest zwyczajna akumulacja danych (typu wyślij i zapomnij), bo do
> takich rzeczy w ogóle nie trzeba by było bazy "live", wystarczyłby system
> podobny do e-maili (gdzie serwer sobie ustawia kolejeczkę i w swoim tempie
> wszystko przetwarza). To nie jest tak, że jak teraz wcisnę "SEND" to mogę
> czekać godzinkę aż serwer przemieli, bo taką ma kolejkę, wynik powinien być
> zwrcony w rozsądnym czasie (maksymalnie kilka sekund). No i tych zapytań do
> bazy jest znacznie więcej niż jednorazowe INSERT INTO a i obwodów jest
> więcej niż ktoś tam wyżej podał.

Jednakowoż nadal ilość danych nie powala na kolana i naprawdę nie robi
efektu wow. Operujemy na marnych tysiącach
operacji/rekordów/paczek/połączeń etc. A dopuszczalny czas wykonania jest
duży (nieduży czas to ma system obronny myśliwca, który wykrywa pocisk
kilometr za ogonem i musi coś z nim zrobić teraz, już, ...bum).

Wrażenie to już bardziej robi na mnie google, które indeksuje bilion stron
a gdy wpiszę w wyszukiwarkę tekst z nosa:

somnambulic intergalactic oarsman

to _od razu_ dostaję wynik: Około 1 020 wyników (0,66 s)

Wiem, że zaokrąglony, że niedopieszczony itd. ale ...bilion stron!

Te tysiące dla sprawnego zespołu i kilku serwerów centralnych to powinien
być pikuś z galaretką, a nie problem rozwalający wybory.


--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry

On Wednesday, July 29, 2015 at 3:47:28 PM UTC+2, Pit wrote:
> Dnia 29.07.2015 M.M. napisał/a:
> > On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera wrote:
> >> W dniu 2015-07-29 o 09:42, M.M. pisze:
> >> > On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
> >> >> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
> >> >> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
> >> >> były niespójne.
> >> > Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
> >> > ekstremalnej sytuacji.
> >>
> >> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną sytuację"...
> > Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać, nie
> > wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas ktoś
> > oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie widzisz
> > ekstremalną sytuację?
> >
> > Zaczęli projektować i skopali, jakby po prostu zrobili
> > 1) połączenie
> > 2) transfer
> > 3) zapis
> > 4) rozłączenie
> > To pewnie by wytrzymało, zwłaszcza na kilku komputerach.
>
> Niestety to tak banalnie nie działa, bo jest do tego jeszcze ustawa o
> ordynacji wyborczej. W skrócie protokół wędruje mniej więcej tak:
> 1) Obwód robi swoje podsumowanie głosów i wysyła do "centrali" protokół
> roboczy.
> 2) Centrala weryfikuje dane i wysyła do obwodu swój protokół jakie dane
> odebrała od obwodu i ewentualne poprawki.
> 3) Jeśli były jakieś błędy/poprawki lub dane odebrane nie są zgodne z
> danymi wysłanymi przez komisję, to powrót do punktu 1)
> 4) Komisja obwodowa zatwierdza protokół otrzymany "z centrali" że jest
> wszystko ok, robi wydruk protokołu i składa na nim swoje podpisy (koniec
> drogi elektronicznej).
>
> To nie jest zwyczajna akumulacja danych (typu wyślij i zapomnij), bo do
> takich rzeczy w ogóle nie trzeba by było bazy "live",
Wszystkie etapy które Ty przytoczyłeś, można rozwiązać tak jak ja
zaproponowałem. Na każdym etapie zadania można wrzucać do kolejki.
Na każdym etapie jakiś demon może kolejne zadania z kolejki wyciągać.
Na każdym etapie można system zapytać, czy jest już gotowa odpowiedź.
Oczywiście takie rozwiązanie nie zadziała live. Ktoś wyśle dokument i
będzie musiał kilka razy zapytać serwer czy jest odpowiedź. Może
otrzymać odpowiedź, że przed jego zadaniem stoi w kolejce 300 innych
zadań, więc pójdzie na kawę. Lepsze takie rozwiązanie, niż całkowity
pad serwera, no chyba że ten pad nazywasz systemem live ;-)




> wystarczyłby system
> podobny do e-maili (gdzie serwer sobie ustawia kolejeczkę i w swoim tempie
> wszystko przetwarza). To nie jest tak, że jak teraz wcisnę "SEND" to mogę
> czekać godzinkę aż serwer przemieli,
No ale zdaje się, że czekali dłużej niż godzinę i w końcu jakoś dali radę.
Gdyby jeden demon odbierał i kolejkował, drugi wykonywał obliczenia, trzeci
odpowiadał, to przynajmniej by nie doszło do rozwalenia danych i przynajmniej
swoje dane by się udało wysłać. Jeśli jakiś algorytm obliczający się nie
wyrabia, to w każde rozwiązanie będzie się muliło. Więc chociaż niech
transfery przebiegają sprawnie.

> bo taką ma kolejkę, wynik powinien być
> zwrcony w rozsądnym czasie (maksymalnie kilka sekund). No i tych zapytań do
> bazy jest znacznie więcej niż jednorazowe INSERT INTO a i obwodów jest
> więcej niż ktoś tam wyżej podał.
Ja też uważam że lepiej w ciągu kilku sekund niż w ciągu godziny. Ale
zapewne i Ty się zgodzisz ze mną, że lepiej w ciągu godziny niż w ciągu 20 godzin
plus pad serwera w punkcie krytycznym dla spójności danych.


Pozdrawiam

do góry

Dnia 29.07.2015 szemrany <s...@o...off> napisał/a:
> Jednakowoż nadal ilość danych nie powala na kolana i naprawdę nie robi
> efektu wow. Operujemy na marnych tysiącach
> operacji/rekordów/paczek/połączeń etc. A dopuszczalny czas wykonania jest
> duży (nieduży czas to ma system obronny myśliwca, który wykrywa pocisk
> kilometr za ogonem i musi coś z nim zrobić teraz, już, ...bum).

Tylko że uwzględniając cały workflow dokumentów, to już się robi z tego nie
"marne tysiące" tylko "marne setki tysięcy" paczek, w każdej paczce jest
kilkadziesiąt rekordów, to wszystko opakowane w XML (więc pharser) i
podpisane cyfrowo (trzeba sygnatury sprawdzić) i przede wszystkim takich
rzeczy może się dziać bardzo wiele równocześnie.
Banałem jest wstawienie powiedzmy 10 tysięcy wierszy w jednym wątku
(domowy pecet to uciągnie w rozsądnym czasie), ale to nie jest to samo co
równoległe działanie 100 wątków w których każdy chce wstawić po 100 wierszy
(wszystkie w tym samym czasie).
System obrony myśliwca to wykrywa pocisk na dziesiątki kilometrów (a często
nawet i setki), minęły czasy Spitfire i walki "oko w oko", już 20 lat temu
radary pokładowe myśliwców wykrywały wystawiony peryskop łodzi podwodnej z
odległości ponad 150km, jak jest teraz, to nawet trudno sobie wyobrazić.
Poza tym myśliwiec nie śledzi tysięcy rakiet jednocześnie.

> Wrażenie to już bardziej robi na mnie google, które indeksuje bilion stron
> a gdy wpiszę w wyszukiwarkę tekst z nosa:
>
> somnambulic intergalactic oarsman
>
> to _od razu_ dostaję wynik: Około 1 020 wyników (0,66 s)
>
> Wiem, że zaokrąglony, że niedopieszczony itd. ale ...bilion stron!
>
> Te tysiące dla sprawnego zespołu i kilku serwerów centralnych to powinien
> być pikuś z galaretką, a nie problem rozwalający wybory.

Google nie musi dawać wyników bezbłędnych, i nie mam tu na myśli tego, że
wyświetla "znalazłem 1000 wyników", tylko konkretne linki. Gdy jakiś
istotny (z Twojego punktu widzenia) link nie zostanie wyświetlony, to tego
nawet nie zauważysz, tylko skorygujesz swoje zapytanie, analogicznie gdy
zostanie wyświetlony jakiś nieistotny link (niezbyt pasujący do Twojego
zapytania), to też nic się nie stanie. Przy okazji nie wiem ile Google ma
serwerów teraz, ale w 2010 roku przekroczyli magiczną liczbę miliona, jest
tego tyle, że Google stworzyła swój własny sektor energetyczny, mają własne
elektrownie do zasilania centrów danych. Chcesz to porównywać z systemem
postawionym na kilku czy kilkunastu rdzeniach, który w dodatku nie może
zwracać wyników heurystycznych (mniej więcej poprawnych) tylko dokładne?

do góry