# kernel "timer frequency" 1000hz e segfault dei programmi

## ema

Dopo aver ricompilato il kernel su un serverino mettendo come timer frequency 1000Hz (per risolvere alcuni problemi con vmware server), alcuni programmini che utilizzo, ad esempio natmonitor, vanno spesso e volentieri in segfault, e pure casualmente... una volta funzionano, una volta no, senza una sequenza particolare. Riavviando, o aspettando qualche decina di secondi, funziona tutto. Al segfault, dmesg riporta l'errore:

```

natmonitorconsole[11856] general protection rip:401343 rsp:7fff0cebc1c0 error:0

```

Vi risulta che tale settaggio nel kernel possa creare questi problemi? Sto su amd64 (5200 x2) gentoo 64 bit, 2gb di ram, hardware nuovo di palla...

----------

## Peach

e riportando a 250Hz funziona tutto come prima??? hai già provato?

----------

## ema

si...   :Confused: 

ho una mezza idea di portarla a 300, per vedere se riesco a mediare tra i 2 problemi... chissà se si può portare, ad esempio, a 500...

Ma mi sembra cosi strano che il problema nasca da questa impostazione!

----------

## Peach

 *ema wrote:*   

> si...  
> 
> ho una mezza idea di portarla a 300, per vedere se riesco a mediare tra i 2 problemi... chissà se si può portare, ad esempio, a 500...
> 
> Ma mi sembra cosi strano che il problema nasca da questa impostazione!

 

posso dirti tranquillamente che il 2.6.19 e il 2.6.20 hanno suscitato non pochi problemini con la loro introduzione... 

provato le stesse impostazioni con il 2.6.18-r7? 

(ho dato per scontato che tu avessi un kernel recente, altrimenti lascia perdere)

----------

## noppy

i processori amd , che io sappia , non gradiscono hz alti , anche perche' da 100 a 1000 hai 10 volte gli irq che avresti a 100 Hz , oltre al fatto che da prove effettuate gli amd lavorano meglio su kernel "server" che non desktop , personalmente ti sconsiglio di salire oltre i 250 Hz su tali processori

----------

## Kernel78

Io ho un AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ con kernel 2.6.19-gentoo-r5 e da quando ho questa macchina (mi pare settembre/ottobre) ho sempre compilato il kernel impostando i 1000 Hz e ho avuto problemi soltanto qualche settimana fa con virtualbox che mi freezava il sistema (risolvevo con i magic sysrq) perchè non supportava ancora amd64 e prima ancora con qemu che semplicemente non compila con gcc 4.

Nessun altro problema nemmeno di striscio e specifico anche che ho uptime mediamente sui 15-20 giorni.

----------

## ema

dopo aver letto i vostri post inizio a pensare che l'unica sia appunto mediare... ma se a 300 non vi fossero risultati apprezzabili dal lato dei problemi con vmware, è possibile, mettendo mano anche ai sorgenti del kernel, portarla a 500? mi sembra un pò riduttivo che non vi siano step ulteriori tra 300 e 1000...

----------

## .:chrome:.

 *ema wrote:*   

> dopo aver letto i vostri post inizio a pensare che l'unica sia appunto mediare... ma se a 300 non vi fossero risultati apprezzabili dal lato dei problemi con vmware, è possibile, mettendo mano anche ai sorgenti del kernel, portarla a 500? mi sembra un pò riduttivo che non vi siano step ulteriori tra 300 e 1000...

 

non capisco dove sia il problema nell'avere un basso valore di HZ

se il tuo sistema funziona bene con valori bassi, tanto meglio. il valore 1000 è stato introdotto per avere sistemi più agili nel rispodere, ma il prezzo da pagare è molto alto, in termini di efficienza, e nel tuo caso anche di stabilità.

puoi benissimo impostare clock bassi, finché non esce il kernel 2.6.21, nel quale HZ sparirà e il kernel diventerà finalmente clockless (come ulteriore prova che un valore elevato di HZ non è buona cosa)

----------

## Sparker

300 è stato introdotto solo per gli stati dove i filmati sono a 30 fps. In italia sarebbe corretto 250.

----------

## Peach

 *.:chrome:. wrote:*   

> puoi benissimo impostare clock bassi, finché non esce il kernel 2.6.21, nel quale HZ sparirà e il kernel diventerà finalmente clockless (come ulteriore prova che un valore elevato di HZ non è buona cosa)

 

oltre a fixare nmila problemi delle ultime due release.

/me aspetta con fiducia.

----------

## ema

grazie delle informazioni

Come già detto ho dovuto alzarlo per risolvere problemi con vmware server, che tende a diventare poco reattivo dopo qualche giorno di uptime, oltre a generarmi una sfilza di errori su dmesg. Attualmente sono su 2.6.20. Il consiglio l'avevo trovato su un forum girando con google, ma non avevo idea degli inconvenienti.

Attendo con ansia il nuovo kernel... dove forse girerà anche il driver x la rtl8187   :Cool: 

----------

## .:chrome:.

 *ema wrote:*   

> ho dovuto alzarlo per risolvere problemi con vmware server, che tende a diventare poco reattivo dopo qualche giorno di uptime

 

non vedo come un valore elevato per il clock dello scheduler possa risolvere questo. se il tuo vmware server fosse poco reattivo sempre, potrebbe anche essere a causa di quello, ma se lo diventa dopo un po' di tempo, non può certamente essere a causa del clock dello scheduler.

----------

## djinnZ

Non è che il problema dipende dall'impostazione preemptive ed dallo scheduler (cfq mi ha quasi del tutto scocciato)?

----------

## ema

non credo, o almeno, variando quell'impostazione gli errori permangono.

Ho ricompilato portando a 300hz il clock dello scheduler, i messaggi dal kernel sono molto meno frequenti (10 in un giorno di uptime) e la macchina virtuale per ora è ben reattiva. Credo manterrò questa impostazione.

L'errore, che adesso ricompare sporadicamente, è:

```

rtc: lost some interrupts at 2048Hz

```

e cercando in rete, pare appaia quando l'ora della vm si sfasa rispetto a quella dell'host. Volendo si può anche far sparire agendo sulla config di vmware, ma cosi facendo la sincronizzazione va a farsi benedire del tutto... cosa che per un mailserver non è proprio il massimo...

Col clock a 1000 gli errori sono del tutto assenti, ma visto il prezzo da pagare, credo lascerò le cose come stanno adesso. Almeno gli altri programmi funzionano bene!

----------

