[linux] kernel recompilen @ 1000Hz

[Ankh]

Net vertelde iemand me, dat ik me linux eens moest recompilen (de kernel) maar dan op 1000Hz. heb al verschillende website's (google) en via hier gezocht.. maar ik kan er bar weinig over vinden. Zijn hier misschien mensen die er ervaringen mee hebben? Heeft het nou zoveel nut?

Misschien heeft ook iemand wat meer info er over, omdat ik er dus bar weinig over kan vinden Sadly enough..

Thanks

[hbokh]

Lekker, zo'n broodje aap!
"man make" en dan de "-j"-optie kan WEL wonderen doen.

[ Voor 55% gewijzigd door hbokh op 13-10-2003 17:31 . Reden: Aanvulling ]

[ArchRAIDen]

Misschien bedoelde die iemand op 1000Mhz? of op 1 Ghz?
dat het dan misschien wat sneller zou gaan?

Heeft hij ook een reden kunnen geven? vraag hem dat eerst eens

[JoostBaksteen]

Volgens mij bedoeld hij op een processor van 1000mhz ofzo?

Snap niet echt wat je 'iemand' bedoelt.

Maar je kan gewoon op elke pc een nieuwe kernel compilen hoor.

[AlterEgo]

Google eens naar "jiffies'

[WHiZZi]

1000Hz is 1MHz hoor.. lijkt me niet dat je je kernel dan wilt compilen

1000MHz (=1GHz) is wel lekker om te compilen. In ieder geval beter dan 500MHz ofzo, maar da's logisch.

[Verwijderd]

Ehm als de persoon uitdrukkelijk 1000Hz heeft gezegd, is dat misschien een soort van gemene hint om je duidelijk te maken dat je je maar beter niet aan Linux oid kan wagen?

[PipoDeClown]

Wordt er bedoelt dat de realtimeclock geherprogrammeert wordt dat ie een signaal van 1000 Hz ipv. de gebruikelijke puls om de 18,2 ms? (in hoever wordt daar uberhaupt nog gebruik van gemaakt eigenlijk?)

edit:
of was het 18,2 Hz

[ Voor 8% gewijzigd door PipoDeClown op 14-10-2003 09:47 ]

[Verwijderd]

WHiZZi schreef op 13 oktober 2003 @ 17:39:
1000Hz is 1MHz hoor.. lijkt me niet dat je je kernel dan wilt compilen

1000MHz (=1GHz) is wel lekker om te compilen. In ieder geval beter dan 500MHz ofzo, maar da's logisch.

[mierenneukmode]
1000hz is 1 K(ilo)Hz
[/mierenneukmode]

en weer ontopic:
wat er bedoeld wordt is dat de kernel een scheduler rate zou moeten hebben 1 KHz
(beter is 1024Hz vanwege binair delen enzo)
't zou beter zijn voor reactietijden in spellen enzo
de nieuwe 2.6 kernel heeft 1KHz overigens als standaard

google eens op : jiffies linux kernel 100hz 1000hz
deze hits geven meer info over de voor/nadelen

[ Voor 12% gewijzigd door Verwijderd op 13-10-2003 18:02 ]

[Creepy]

Ik gok erop dat die persoon bedoelde "compilen met 1000hz" en niet "compilen op of met een 1000hz machine" Die 1000Hz is de kernel grannularity (??) instelling. Het zorgt voor kleinere vertragingen tegenover een iets grote kernel overhead. (zodat voor desktop gebruik je machine wat sneller aanvoelt"

Kijk eens op http://members.optusnet.com.au/ckolivas/kernel/ voor meer uitleg en een kant en klare kernel patch die voor een sneller aanvoelend desktop systeem. (wel zorgen dat je X weer op een nice level van 0 draait, zie ook de faq op de link die ik net gaf.)

[ Voor 4% gewijzigd door Creepy op 13-10-2003 17:58 ]

[ArchRAIDen]

Je kan overigens in je kernel ook iets met time ticks doen, staat standaard op 200Hz
Hertz ja die kan hij ook bedoelen, weet niet waar die optie precies zat, maar iig
in een van de bovenste menus van menuconfig.

[Wilke]

Als je geen idee hebt wat je aan het doen bent, moet je hier niet mee gaan prutsen.

[Verwijderd]

/me heeft Linux draaien op oa. een P-II 450.... en doet 't perfect....
Maar als je nu eerst eens duidelijk maak wat je probleem nu eigenlijk is zou het een stuk makkelijker zijn om te kunnen beoordelen wat er aan de hand is en hoe op te lossen.
Want deze stelling zoals je die nu neerzet heeft wel een extreem hoog wazigheidsgehalte....

[wica]

Wilke: Juist wel. Dan krijgen we weer een topic's.
[linux] boot niet
[linux] herkent me root fs niet
[linux] ....

// on-topic
maar Creepy en ArchRAIDen hebben gelijk.
Wat die iemand bedoelt is. Heet Timer frequency en in de help van de kernel staat 1/2 van je cpu. (make menuconfig -> General setup -> Timer frequency)

Verder wens ik je veel plz en lange nachten met linux

/edit
Ik zie net dat die optie niet in de standaart source voorkomt. En weet ook niet welke distro jij hebt

[ Voor 15% gewijzigd door wica op 14-10-2003 09:40 ]

[Exirion]

PipoDeClown schreef op 13 oktober 2003 @ 17:48:
Wordt er bedoelt dat de realtimeclock geherprogrammeert wordt dat ie een signaal van 1000 Hz ipv. de gebruikelijke puls om de 18,2 ms? (in hoever wordt daar uberhaupt nog gebruik van gemaakt eigenlijk?)

Sowiezo is die 18,2 tikken per seconde nauwelijks bruikbaar en je kon via poortadressen de frequentie van de klokgenerator verhogen naar bijvoorbeeld 100 tikken per seconde. Dat was een stuk praktischer Moest je er wel voor zorgen dat interrupt (als ik het me goed herinner) 1C niet elke keer werd aangeroepen maar dat je de 18,2 tikken per seconde nabootste om de klok niet voor te laten gaan lopen.

Wel ERG offtopic dit

[Kippenijzer]

Tja, best jammer dat bijna iedereen die hier reageert niet echt doorheeft waar het om gaat... Reageer dan gewoon niet mensen... Wilke, misschien een idee om alle reacties (en deze van mij) die betrekking hebben op cpu snelheden ipv kernel gerelateerde grannularity te trashen en dit topic weer mooi terug te brengen tot een reactie of 4 en tevens het nut van dit topic voor de archieven (mensen die hier info over zoeken vooral) verhogen....

[Kippenijzer]

wica schreef op 14 October 2003 @ 09:39:
Ik zie net dat die optie niet in de standaart source voorkomt. En weet ook niet welke distro jij hebt

Deze optie komt wel voor, enkel moet je hem handmatig aanpassen en staat hij idd niet in de standaard (x)(menu)config van de kernel. Uit mijn hoofd iets van /usr/src/linux/include/asm-i386/param.h waarin je hem aan moet (/kunt) passen

[wica]

@Kippenijzer
Zo te zien heb je gelijk
in /usr/src/linux/include/asm-i386/param.h kan je dit aanpassen

C:

#ifndef HZ
#define HZ 200
#endif

Maar ik denk wel dat het verstandig is om een patch te gebruiken aan gezien er nog wat andere dingen extra in param.h staan

[Creepy]

wica schreef op 14 oktober 2003 @ 09:39:
/edit
Ik zie net dat die optie niet in de standaart source voorkomt. En weet ook niet welke distro jij hebt

En anders download je de patch die ik aangegeven heb. Daarin zit die instelling verwerkt. Als je alleen die Hz instelling wilt ophogen dan zet je de Desktop Tuning optie van die patch uit.

Overigens een fijne patch. Je desktop wordt er "merkbaar" sneller door. De patch is overigens NIET aan te raden voor een desktop systeem.

[Kippenijzer]

wica schreef op 14 oktober 2003 @ 09:58:
@Kippenijzer
Zo te zien heb je gelijk
in /usr/src/linux/include/asm-i386/param.h kan je dit aanpassen

C:

#ifndef HZ
#define HZ 200
#endif

Maar ik denk wel dat het verstandig is om een patch te gebruiken aan gezien er nog wat andere dingen extra in param.h staan

Ik heb zelf enkel dit regeltje aangepast in HZ 1000 voor mijn gameservers...

[Creepy]

Kippenijzer schreef op 14 October 2003 @ 12:01:
[...]

Ik heb zelf enkel dit regeltje aangepast in HZ 1000 voor mijn gameservers...

Waarom heb je dat gedaan? Het zorgt ervoor dat er "sneller" wordt gemultitasked (de timeslices per proces zijn kleiner). En zorgt voor server voor meer overhead aangezien alle andere processen ook vaker aan de beurt zijn (en geeft dus een NEGATIEVE impact voor je gameserver(s)).

Als je wilt dat je gameserver processen meer tijd toebedeelt krijgen kan je ze beter renicen (naar een negatieve waarde bijv.) zodat ze meer voorrang krijgen dan de andere processen.

[woutur]

Ik ben dit ook tegen gekomen met het optimalizeren van kernels voor gameservers (UT). Er werd beweerd dat de tickrate van de server zelf (ingame) er een stuk stabieler van werd (wat dat ook moge betekenen).
Volgens de tester was had dit een positief effect ...

[Kippenijzer]

Creepy schreef op 14 oktober 2003 @ 12:11:
[...]

Waarom heb je dat gedaan? Het zorgt ervoor dat er "sneller" wordt gemultitasked (de timeslices per proces zijn kleiner). En zorgt voor server voor meer overhead aangezien alle andere processen ook vaker aan de beurt zijn (en geeft dus een NEGATIEVE impact voor je gameserver(s)).

Als je wilt dat je gameserver processen meer tijd toebedeelt krijgen kan je ze beter renicen (naar een negatieve waarde bijv.) zodat ze meer voorrang krijgen dan de andere processen.

Laat ik het erop houden dat ik dit niet gedaan heb omdat ik het hier en daar gelezen had, maar toch echt wel er "wat voorstudie" naar gedaan heb, en ja, die zin bedoel ik sarcastisch

Het komt erop neer dat inderdaad je gameservers veel meer van je systeem gaan vragen, van de standaard (zover ik weet) 100Hz naar 1000Hz schakelen kan in de vervelendste gevallen je CPU usage per gameserver wel verdubbelen. Echter zal door het effectief vaker verwerken van alle gameserverdata, er veel minder frame-skew (hoe moet ik dit noemen, is een hele pagina uitleg, komt erop neer dat bijvoorbeeld een UT soms de client FPS (server-frames, niet beeld-frames) en de server-FPS net asynchroon kunnen lopen, waardoor er iedere paar frames eentje van de client binnenkomt als de server net zijn eigen frame gedaan heeft) ontstaan, omdat de server-side FPS hoger komt te liggen. Hierdoor krijg je minder snel pingspikes en minder last van een "golvende" game-ping.
Natuurlijk is het renicen van een server process leuk, maar je schiet er nogal weinig mee op om 8 gameservers allemaal naar -10 ofzo te renicen, omdat ze dan elkaar nog steeds in de weg zitten, en met HZ 1000 draaien ze alle 8 soepeler...

Zover voor een stukje gesimplificeerde uitleg ;P

[Creepy]

Kippenijzer schreef op 14 October 2003 @ 15:08:
[...]

Laat ik het erop houden dat ik dit niet gedaan heb omdat ik het hier en daar gelezen had, maar toch echt wel er "wat voorstudie" naar gedaan heb, en ja, die zin bedoel ik sarcastisch

Gelukkig

Het komt erop neer dat inderdaad je gameservers veel meer van je systeem gaan vragen, van de standaard (zover ik weet) 100Hz naar 1000Hz schakelen kan in de vervelendste gevallen je CPU usage per gameserver wel verdubbelen. Echter zal door het effectief vaker verwerken van alle gameserverdata, er veel minder frame-skew (hoe moet ik dit noemen, is een hele pagina uitleg, komt erop neer dat bijvoorbeeld een UT soms de client FPS (server-frames, niet beeld-frames) en de server-FPS net asynchroon kunnen lopen, waardoor er iedere paar frames eentje van de client binnenkomt als de server net zijn eigen frame gedaan heeft) ontstaan, omdat de server-side FPS hoger komt te liggen. Hierdoor krijg je minder snel pingspikes en minder last van een "golvende" game-ping.
Natuurlijk is het renicen van een server process leuk, maar je schiet er nogal weinig mee op om 8 gameservers allemaal naar -10 ofzo te renicen, omdat ze dan elkaar nog steeds in de weg zitten, en met HZ 1000 draaien ze alle 8 soepeler...

Zover voor een stukje gesimplificeerde uitleg ;P

Dankje

[igmar]

Ter info : ftp://ftp.kernel.org/pub/linux/kernel/people/rml/ staan een aantal scheduling related patches, waaronder een voor 2.4 kernels waarmee je de waarde van HZ via een variable in /proc kan aanpassen.

De patch is redelijk simpel, op 2.4.19 was het applyen geen probleem.

[deadinspace]

PipoDeClown schreef op 13 oktober 2003 @ 17:48:
Wordt er bedoelt dat de realtimeclock geherprogrammeert wordt dat ie een signaal van 1000 Hz ipv. de gebruikelijke puls om de 18,2 ms? (in hoever wordt daar uberhaupt nog gebruik van gemaakt eigenlijk?)

edit:
of was het 18,2 Hz

18.2 Hz Een 1.2 MHz clock met counter op 65536 iirc.

Waarom zou dat btw "gangbaar" zijn? MS-DOS maakte er gebruik van, maar verder? Linux 2.4 en eerder zet de timer standaard op 100 Hz iirc.

Creepy schreef op 13 October 2003 @ 17:52:
(wel zorgen dat je X weer op een nice level van 0 draait, zie ook de faq op de link die ik net gaf.)

Het terugnicen van XFree86 naar 0 is iirc vanwege de nieuwe scheduler, niet vanwege een versnelde timer. Ik weet zo snel niet of die nieuwe scheduler bij die patches zit, en ik ben te lam om te kijken, maar toch even die opmerking

Als je je interesseert voor dergelijke effecten, dan wil je misschien ook naar de 2.6.0-testx kernels kijken. 2.6 heeft standaard de timer op 1000 Hz, preempt (als optie) en een nieuwe, verbeterde process scheduler. En nog een bak andere verbeterde zaken, maar ok

[Creepy]

deadinspace schreef op 15 oktober 2003 @ 00:27:
[...]

Het terugnicen van XFree86 naar 0 is iirc vanwege de nieuwe scheduler, niet vanwege een versnelde timer. Ik weet zo snel niet of die nieuwe scheduler bij die patches zit, en ik ben te lam om te kijken, maar toch even die opmerking

IK gaf dit ook aan voor de patch die ik aangaf (Con Koliva's desktop tuning patch, dat is 1000Hz, preempt en nog wat scheduler fixes). Een deel van het werk van Con zit nu ook in de 2.6 kernel.