Jądro Linuksa 1000 Hz jest konieczne, jeśli mam zegar tykający i wysokiej rozdzielczości?

13

Usiłuję poprawić wydajność na moim serwerze. Mam kilka procesów, które wymagają niskiego jittera (wariancja poniżej 10ms).

Mam średnio obciążenie maksymalnie 4 na i7-920 (4 rdzenie fizyczne, 8 z HT). Istnieje około 10 procesów od 40% do 90% trybu podstawowego użytkownika. Zużycie systemu wynosi 3%. Całkowite użycie procesora wynosi maksymalnie 80%.

Czy ustawienie jądra ze 100 Hz na 1000 Hz poprawi fluktuację, jeśli ustawione są już zegary tykające i wysokiej rozdzielczości?

Ta strona wydaje się wskazywać, że nadal coś robi. https://lkml.org/lkml/2009/4/28/401

Co powiesz na zmianę z dobrowolnej (PREEMPT_VOLUNTARY) na preloadable (PREEMPT)?

linux linux-kernel

— Kok
źródło

Szczegóły dystrybucji / wersja systemu operacyjnego?

— ewwhite

Jądro 64-bitowego serwera Ubuntu 11.10 z systemem Linux 3.3.

— Bob

Masz wiele ładowań w trybie użytkownika; czas systemowy jest stosunkowo znikomy. Nie sugerowałbym tańczyć wokół tunerów jądra. A może chcesz uzyskać harmonogram podobny do czasu rzeczywistego?

— yrk

Czy mówisz, że jeśli użycie systemu jest niskie, nic z tego nie wpływa na szybkość reakcji?

— Bob

4

Usiłuję poprawić wydajność na moim serwerze. Mam kilka procesów, które wymagają niskiego jittera (wariancja poniżej 10ms).

Jakikolwiek czas rzeczywisty nie poprawi wydajności, sprawiłby, że cały system działałby płynniej, ale w rzeczywistości byłby nieco wolniejszy. Innymi słowy, jest to przepustowość vs. opóźnienie. Jeśli naprawdę tego potrzebujesz, to kilka opcji:

Używaj 300 Hz, a nawet 1 KHz, PREEMPT, i nie używaj tików
Użyj nice, schedtoolaby przypisać odpowiednie priorytety / klasy w zależności od potrzeb
Spróbuj RT lub BFS

— poige
źródło

Co jest złego w używaniu tików?

— Bob

1

@ Bob, jest dobry do oszczędzania energii, ale jeśli zależy Ci na opóźnieniu, zaleca się wyłączenie, na przykład ck.kolivas.org/patches/bfs/bfs-configuration-faq.txt

— poige

3

Jeśli niski jitter jest dla Ciebie ważny, tak, możesz użyć zarówno 1000 Hz, jak i PREEMPT.

Jeśli te procesy są bardzo wrażliwe na czas, prawdopodobnie będziesz potrzebować kilku łatek / jąder zorientowanych w czasie rzeczywistym lub przynajmniej niektórych parametrów planowania na poziomie procesu, takich jak rtprio.

Typowe zastosowania to serwery audio, patrz na przykład porady od jackaudio

— koollman
źródło

3

1) Nie używaj tików, jest to wciąż bardzo eksperymentalne i nie jest zalecane nikomu poza programistami nad nim pracującymi, ma również pomóc w oszczędzaniu energii.

2) W pełni preemtowalny system ma na celu zwiększenie reaktywności desktora, podczas gdy dobrowolny preloadable ma zastosowanie ogólne (połączenie reaktywności i wydajności). Jeśli twój serwer ma SMP (wiele rdzeni), prawdopodobnie powinieneś przejść do nieprzewidzianych, ponieważ większość pracy będzie wykonywana na ich rdzeniach i bez przerw, co zwykle 1) zajmuje czas 2) pamięć podręczną kosza

3) 1000 Hz to wartość na pulpicie, która wprowadza narzut, ale pozwala na przykład grać w gry i inne rzeczy. 300 Hz to wartość zalecana dla wideo (aby rzeczy mogły zostać ponownie zaplanowane i nadal nie przegapisz klatek), a 100 Hz zapewnia najlepszą przepustowość (choć nie jest nastawiona na sieciowe lowatencje).

Jeśli chcesz być tak stabilny, jak to tylko możliwe (bez używania poprawek RT), powinieneś przejść: okresowe tyknięcia (stabilność) nieprzewidywalna (stabilność) częstotliwość taktowania (do ciebie, 1000 dla najlepszej reakcji i niskich opóźnień, 100 dla najlepsza przepustowość, ale rozdzielczość 10 ms na zegarze, np. rzeczy będą działały co najmniej 10 ms)

Mam nadzieję, że to trochę pomaga.

— pruzinat
źródło