bachi linux?

[cavay]

Sto provando a fare un timer per linux in c++ ma....qualsiasi primitiva utilizzo mi sembra che portino un ritardo o cmq un nn buon funzionamento.

Testiamo una sleep ad esempio:

#include <sys/time.h>
#include <stdio.h>
#include <unistd.h>

void *TimeZone;
struct timeval Before;
struct timeval After;

int main()
{

while(1)
{
gettimeofday (&Before, TimeZone);
//usleep(1000); //1 ms
sleep(1); //1 s
gettimeofday (&After, TimeZone);

printf("\nIl tempo trascorso è %d(sec) e %d(usec",
After.tv_sec-Before.tv_sec,
After.tv_usec-Before.tv_usec);
fflush(stdout);
}

}

Dall'esecuzione dell'exe prodotto si nota che c'è un ritardo medio di circa 8ms, se lostesso codice lo compilo su piattaforma DIGITAL il ritardo è nullo.

Qualcuno mi sa consigliare qualche soluzione o cmq darmi una spiegazione alla cosa? è INTEL o LINUX OS che nn vanno??

[VICIUS]

forse è meglio che chiedi ad un moderatore di spostare la discussione in Programmazione li trovi di sicuro qualcuno piu adatto a risponderti.

ciao

[cavay]

ops...ho sbagliato...nn me ne ero accorto

[Wyrdmeister]

Ipotesi:
1) puoi provare a impostare il nice del processo a realtime (mi pare che sia -20) altrimenti potrebbe succedere che il tuo processo non sia messo in esecuzione immediatamente... inoltre per quel che ne so io, una sleep(t) ti assicura che il tuo processo non tornerà in esecuzione prima di un tempo t, ma non ti assicura che ritorni in esecuzione immediatamente dopo un tempo t...

2) usi un kernel 2.4? il codice di sistema del 2.4 non è preemptive quindi se un altro processo sta eseguendo una chiamata di sistema nel momento in cui esci dalla sleep devi aspettare che la finisca prima di poter tornare in esecuzione (prova un 2.6 con il supporto preemptive per il codice in modalità kernel)

3) Altri motivi che ignoro.. non conosco l'architettura DIGITAL

[Burns]

Originariamente inviato da Wyrdmeister
2) usi un kernel 2.4? il codice di sistema del 2.4 non è preemptive quindi se un altro processo sta eseguendo una chiamata di sistema nel momento in cui esci dalla sleep devi aspettare che la finisca prima di poter tornare in esecuzione (prova un 2.6 con il supporto preemptive per il codice in modalità kernel)

Sei sicuro?

[cavay]

Hai raggne circa la sleep, è proprio come dici ma...u ritardo di circa 8-9milli al secondo...è eccessivo.
Se si pensa che sulla macchina nn stava girando "niente" poi...


Ho appena provato anche su altre piattaforme(SUN-SOLARIS e LYNX su power pc)...tutto funziona come dovrebbe..

Circa invece il kernel...nn so che sto utilizzando ma è quello di default della RH 9, sai è la piattaforma target(INTEL-LINUX); niente su linux ma...intell....va be lasciamo stare.

Faro' delle indagini in +, grazie per l'aiuto!

[Wyrdmeister]

Originariamente inviato da Burns
Sei sicuro?

http://news.hwupgrade.it/11393.html

[ilsensine]

Originariamente inviato da Wyrdmeister
2) usi un kernel 2.4? il codice di sistema del 2.4 non è preemptive quindi se un altro processo sta eseguendo una chiamata di sistema nel momento in cui esci dalla sleep devi aspettare che la finisca prima di poter tornare in esecuzione (prova un 2.6 con il supporto preemptive per il codice in modalità kernel)

Stai mischiando due cose diverse: latenza di una syscall e latenza dello scheduler.

La prima è sì ridotta da un kernel preemptive, ma non ha un grande effetto sulla usleep (finché le grandezze in gioco rimangono nell'ordine dei ms).

La seconda è ciò che determina il tempo effettivo speso nella usleep: quando un processo va a "dormire", il sistema invoca lo scheduler e passa ad un altro processo. Il tempo assegnato a ciascun processo in ciascuna epoca è rozzamente pari a 1/HZ, dove "HZ" è il "parametro magico" in questione. A meno che il secondo processo non vada anch'esso a dormire con usleep, consuma tutto il timeslice a sua disposizione. E' plausibile quindi che il tempo di attesa _minimo_ (a seconda del carico può salire considerevolmente) è nell'ordine di 1/HZ.

Nei kernel 2.4 HZ è di 100 herts (con un ritardo minimo di scheduling di circa 10 ms); nei kernel 2.6 è stato elevato a 1000 (o 1024 non ricordo; il ritardo minimo è di circa 1 ms ma può crescere per altri fattori).

Altri sistemi possono presentare comportamenti diversi, in quanto lo scheduler è una delle cose più "variegate" dell'informatica. Non mi sorprenderebbe che uno scheduler che sembra "perfetto" per il tuo programma, all'aumentare del carico degradi considerevolmente le sue prestazioni. Anche il numero di processori del sistema influisce, ovviamente.

[Wyrdmeister]

Ho provato il codice su un p3 800 con kernel 2.6.5, compilato con gcc 3.3.3 e ottengo ritardi inferiori ai 2ms...

Il tempo trascorso è 1(sec) e 1701(usec)
Il tempo trascorso è 1(sec) e 1627(usec)
Il tempo trascorso è 1(sec) e 1805(usec)
Il tempo trascorso è 1(sec) e 1782(usec)
Il tempo trascorso è 1(sec) e 1797(usec)
Il tempo trascorso è 1(sec) e 1786(usec)
Il tempo trascorso è 1(sec) e 1806(usec)
Il tempo trascorso è 1(sec) e 1781(usec)
Il tempo trascorso è 1(sec) e 1807(usec)
Il tempo trascorso è 1(sec) e 1780(usec)
Il tempo trascorso è 1(sec) e 1794(usec)
Il tempo trascorso è 1(sec) e 1784(usec)
Il tempo trascorso è 1(sec) e 1810(usec)
Il tempo trascorso è 1(sec) e 1783(usec)
Il tempo trascorso è 1(sec) e 1809(usec)
Il tempo trascorso è 1(sec) e 1786(usec)

Inoltre avviando il programma di prova con il comando:

nice -n "-30" ./prova

il ritardo si riduce fino a 1.4ms e anche meno a volte...
non capisco perchè sulla tua macchina abbia latenze maggiori!


EDIT: il messaggio di ilsensine che non avevo ancora letto spiega perchè!

[Wyrdmeister]

Originariamente inviato da ilsensine
Stai mischiando due cose diverse: latenza di una syscall e latenza dello scheduler.

La prima è sì ridotta da un kernel preemptive, ma non ha un grande effetto sulla usleep (finché le grandezze in gioco rimangono nell'ordine dei ms).

La seconda è ciò che determina il tempo effettivo speso nella usleep: quando un processo va a "dormire", il sistema invoca lo scheduler e passa ad un altro processo. Il tempo assegnato a ciascun processo in ciascuna epoca è rozzamente pari a 1/HZ, dove "HZ" è il "parametro magico" in questione. A meno che il secondo processo non vada anch'esso a dormire con usleep, consuma tutto il timeslice a sua disposizione. E' plausibile quindi che il tempo di attesa _minimo_ (a seconda del carico può salire considerevolmente) è nell'ordine di 1/HZ.

Nei kernel 2.4 HZ è di 100 herts (con un ritardo minimo di scheduling di circa 10 ms); nei kernel 2.6 è stato elevato a 1000 (o 1024 non ricordo; il ritardo minimo è di circa 1 ms ma può crescere per altri fattori).

Altri sistemi possono presentare comportamenti diversi, in quanto lo scheduler è una delle cose più "variegate" dell'informatica. Non mi sorprenderebbe che uno scheduler che sembra "perfetto" per il tuo programma, all'aumentare del carico degradi considerevolmente le sue prestazioni. Anche il numero di processori del sistema influisce, ovviamente.

hai ragione... ... avevo pensato al fatto che la timeslice era troppo lunga ma non sapevo come fosse nel kernel linux... le mie del resto erano solo un'ipotesi... in effetti in un sistema senza carico la latenza di una syscall non è poi fondamentale! soprattutto perchè non c'è ogni volta che il processo esce dalla sleep, ma è casuale!

[/\/\@®¢Ø]

Qui puoi trovare un confronto tra i nanosleep di diversi unix (non aggiornatissimo, ma lettura comunque interessante)
http://www.dragonflybsd.org/docs/nanosleep/

[cavay]

quindi sembrerebbe che nn ci sono soluzioni....il timer inizialmente veniva gestito con una select ma....anch'essa nn si comportava bene...
Quindi...possiamo dire che INTEL-LINUX è ancora un giocattolino?

[cionci]

Ma un giocattolino per fare cosa ?

[ilsensine]

Originariamente inviato da cavay
quindi sembrerebbe che nn ci sono soluzioni....il timer inizialmente veniva gestito con una select ma....anch'essa nn si comportava bene...

Per valori di usleep relativamente bassi (decine di ms) la funzione viene implementata con nanosleep. Se dai una occhiata alla manpage di nanosleep, leggerai alcuni dettagli sul suo comportamento. In particolare, puoi ottenere risoluzioni precise utilizzando una strategia di scheduling real-time (sched-fifo oppure sched-roundrobin; v. man sched_setscheduler). Occhio che questo viene ottenuto a scapito degli altri processi e di un'ottimale allocazione del processore, quindi non ne abusare.

[cn73]

Originariamente inviato da Wyrdmeister
nice -n "-30" ./prova

il ritardo si riduce fino a 1.4ms e anche meno a volte...
non capisco perchè sulla tua macchina abbia latenze maggiori!

Come sarebbe che non capisci? Ilsensine ti ha spiegato che molto dipende dallo scheduler della CPU (che sceglie fra i processi in ready queue quale deve essere eseguito). Quindi dal carico e dalla tipologia di lavoro presente nel sistema al momento in cui lanci il tuo processo. Addirittura eseguendolo sulla tua stessa macchina in momenti diversi, con carichi diversi, potresti avere differenze significative.

[Wyrdmeister]

Originariamente inviato da cn73
Come sarebbe che non capisci? Ilsensine ti ha spiegato che molto dipende dallo scheduler della CPU (che sceglie fra i processi in ready queue quale deve essere eseguito). Quindi dal carico e dalla tipologia di lavoro presente nel sistema al momento in cui lanci il tuo processo. Addirittura eseguendolo sulla tua stessa macchina in momenti diversi, con carichi diversi, potresti avere differenze significative.

Quando ho postato non avevo ancora letto il messaggio... infatti poi ho editato!