strikexp pisze: ↑

15 sie 2020, 21:31

Raczej podniszczony

Nie chcę Ci robić wykładu z fizyki, ale jeśli na skutek jakiegoś defektu ciepło wydziela się punktowo, to procesor będzie się przegrzewał ... punktowo.
Naprawiałem kiedyś komputer z takim felernym procesorem - instalowałem czyściutki system operacyjny, a po dwóch tygodniach sprzęt wracał z totalną sieczką na dysku ...
Temperatura wcale nie była jakaś wariacka, po prostu kilkanaście stopni wyższa od przeciętnej tego modelu z identycznym chłodzeniem i pod takim samym obciążeniem.
W końcu wymieniłem procesor, temperatura spadła do normy, a sprzęt już nigdy więcej do mnie nie wrócił ...

strikexp pisze: ↑

15 sie 2020, 19:59

Kwestia odpowiedniego zestawu chłodzącego i odpowiedniej obudowy z dostępem do świeżego powietrza.

Niekoniecznie, zdarzają się egzemplarze grzejące się ponad normę, które jeszcze na dodatek powyżej pewnej temperatury zaczynają robić błędy.
Ale widziałem też radiatory założone krzywo i bez żadnej pasty ...
Można spróbować reinstalacji coolera, ale jeśli procesor osiąga 90 ° C, to może już być ubity na amen.

pitsa pisze: ↑

27 lip 2020, 16:40

Testować jedną oś czy jednocześnie np. 2 lub 3 z jazdą po przekątnej kwadratu lub sześcianu?

Wystarczy jedna oś, ale jechać trzeba po prostej w nieskończoność.
Dlatego w moim configu są tak wariackie liczby.
W skrócie chodzi o to, żeby cały czas jechać ze stałą prędkością, bo jakiekolwiek zwolnienie da komputerowi czas na nadgonienie błędu.

drzasiek90 pisze: ↑

20 lip 2020, 20:07

Pasuje przyglądać się latency-plot a nie latency-test chociaż samo przyglądanie się niewiele pomorze.
Jeśli mamy komputer który raz na kilkadziesiąt sekund wyrzuci nam opóźnienie 100 us a wydajność komputera pozwoli aby to nadrobić nic się strasznego nie dzieje.

Tutaj pełna zgoda.
Ja natomiast szukam prostego sposobu sprawdzenia w praktyce, co dany komputer może, a co jego możliwości przekracza.

drzasiek90 pisze: ↑

20 lip 2020, 19:44

Czyli jednak jest jakiś mechanizm "nadganiania" który jeśli czas procesora pozwoli to "nadgania" tak aby ferror zmniejszyć?
Szukałem czy gdzieś można na żywo podglądnąć wartość tego błędu ale nie znalazłem. Jest coś takiego do podglądu?

Ad 1. To jest najzwyklejsze serwo, tylko zamiast impulsów z fizycznego enkodera są liczone wygenerowane faktycznie impulsy step.
Ad 2. Nie wiem, nigdy nie było mi to potrzebne.

drzasiek90 pisze: ↑

20 lip 2020, 19:05

Ale skoro system wie o tym że przepadło (bo liczy ferror) to czemu tego zadania nie wykona jeszcze raz?

Bo nie ma kiedy.
Celem testu jest ustalenie prędkości przy której komputer przestanie się wyrabiać i wszelkie niewykonane zadania pozostaną niewykonane, więc ferror będzie rósł w czasie.
Natomiast faktycznie, jeśli każesz jechać wolniej, to w następnym cyklu servo_period prędkość zostanie podbita aby nadgonić błąd.

Natomiast co do przebiegu na LPT, to wiadomo skąd się bierze taki a nie inny.
Przerwanie jest generowane co base_period, a program decyduje czy wystawić impuls czy nie.
Przy wolnych przebiegach wygląda to ładnie, przy szybkich już nie, no bo jak przejść z 50 khz na 49,9 kHz ?
Można tylko wyciąć co któryś impuls.

drzasiek90 pisze: ↑

20 lip 2020, 18:27

Zacięcie zataśmowanego karabinu to poważna i niebezpieczna sprawa i nijak ma się to do omawianego tutaj problemu.

Jak najbardziej ma się.
Zaczynam podejrzewać, że doskonale wiesz o czym mówię, tylko głupio Ci się przyznać.
Przykład z karabinem maszynowym jest idealnym przykładem, ale mogę podać inny :
Samochód o prędkości maksymalnej 100 km/h ma do przejechania 100 km, ale po drodze łapie gumę.
Chyba jest oczywiste, że po godzinie ma przejechane mniej niż 100 km ?
Po prostu żeby nadrobić stracony czas musiałby się poruszać szybciej niż może !
No to teraz z innej strony :
Samochód o prędkości maksymalnej 100 km/h ma do przejechania 100 km, ale każesz kierowcy jechać 110 km/h.
Po pierwszej godzinie brakuje Ci przejechanych 10 km, po drugiej 20 km itd.
Dzieje się tak, ponieważ NIE POJEDZIE SZYBCIEJ NIŻ MOŻE !
Czego tu można nie rozumieć ???

drzasiek90 pisze: ↑

20 lip 2020, 17:54

gwarantuję Ci, że jeśli karabin z szybkostrzelnośćią 600 strzałów na minutę zatnie się po 400 strzałach to z pewnością po 2 minutach nie wystrzelisz 1000 pocisków.

Czepiasz się szczegułów bez znaczenia, ale niech Ci będzie że masz rację.
No to teraz, jako specjalista od karabinów maszynowych odpowiedz na następujące pytanie :
Karabin o szybkostrzelności 600 strzałów na minutę strzela dokładnie pięć minut, z tym że w tym czasie się zaciął, ile pocisków wystrzelił ? 3000 (5*600=3000), czy mniej ?

drzasiek90 pisze: ↑

20 lip 2020, 14:04

Zacięcie karabinu w żadnej sposób nie zmienia szybkostrzelności.

Ale zmienia ilość wystrzelonych naboi.
Ilość niewystrzelonych naboi to ferror.
Dopóki nie zrozumiesz tego przykładu, nie mamy o czym rozmawiać.

drzasiek90 pisze: ↑

20 lip 2020, 10:42

A nie jest tak, że "żądanie obsługi" trafia do kolejki FIFO i następnie jeśli starczy czasu procesora to generowanie jest "nadrabiane" czyli wywoła się 3 razy pod rząd?

Nie jest.
Jeśli karabin maszynowy strzela np. 600 strzałów na minutę i się zatnie, to wystrzeli np. 400 przez pierwszą minutę, potem znowu będzie strzelał 600 strzałów na minutę, więc tych dwustu nie nadrobi i po dwóch minutach wystrzeli 1000 a nie 1200. Jeśli wystąpią kolejne zacięcia, to ilość brakujących strzałów będzie rosła.
Test polega na ustaleniu właśnie takich, granicznych warunków, żeby program nie miał kiedy nadrobić straconego czasu.