[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [riminilug-general] Re: [riminilug-soci] thin-client LTSP
Il 15.05.2014 15:41 Ivan Tarozzi ha scritto:
Il 15/05/2014 14:00, Giuseppe Ferrara ha scritto:
Il 15.05.2014 12:54 Ivan Tarozzi ha scritto:
[cut]
Ciao Giuseppe,
innanzitutto una curiosita': esiste un motivo per cui avete scartato
il
raspberryPi? Di fatto e' comunque il piu' economico ed essendo il
piu'
diffuso esiste supporto con il progetto BerryTerminal[1]
Ciao Ivan,
ho scartato la scheda raspberry perchè l'ho provata in locale con una
debian. Ho testando le sue prestazioni facendola lavorare come
miniserver e ho notato che richede poca ram ma di contro i picchi
della CPU arrivano spesso al 100%.
Sicuramente l'HW di un raspberryPi non e' particolarmente esoso, anzi,
pero' forse il confronto che hai fatto potrebbe essere poco indicativo
in quanto l'utilizzo come server e' differente rispetto all'utilizzo
come thinclient. Detto questo non l'ho mai provato quindi potrebbe
benissimo essere che tu abbia perfettamente ragione. Bisogna a questo
punto capire quanto le altre schede ARM siano effettivamente piu'
veloci... Vedi sotto
Considerata la mia esperienza pratica nelle aule, non credo che il
raspberry possa
essere una soluzione valida per una rete LTSP.
L'applicativo più usato è impress e quando i ragazzi scaricano le
immagini da internet
per inserirle nelle slide, non tengono conto della risoluzione delle
immagini.
Ciò comporta una decadenza improvvisa di prestazioni delle macchine
client.
Se poi teniamo conto che una presentazione media è composta da almeno
15 slide non credo che il raspy riesca a rimanere indifferente.
Testando i pc riciclati utilizzati nelle aule info delle scuole ho
notato che a parità di ram (512 MB), la differenza in prestazioni è
determinata dai thin client con CPU più veloci; il raspy non ha una
gran CPU.
Questa cosa mi lascia un po' perplesso, anche se non metto in dubbio
l'esperienza che riporti... Sicuramente hai la maggiore esperienza sul
campo e la pratica spesso e' differente dalla teoria :)
La perplessita' deriva dal fatto che la "pesantezza" delle applicazioni
non dovrebbero ripercuotersi piu' di tanto sui ThinClient in quanto RAM
e CPU utilizzata dal processo in questione vengono "allocate" sul
server e non sul client. Quindi il collo di bottiglia dovrebbe essere
semmai la CPU (e la RAM) del server (sempre che parliamo di thinclient
e
tralasciamo fat-client o soluzioni miste).
Ciao Ivan,
escluderei il collo di bottiglia del server perchè dopo aver configurato
le aule
ho eseguito qualche test mentre gli studenti utilizzavano
contemporaneamente 20 postazioni
usando impress (per realizzare un progetto su energie alternative).
Per monitorare il traffico di rete tra server e client ho usato Iptraf e
per controllare
il consumo di ram e l'uso dei 4 processori del server Dell ho usato top
e htop.
Le 4 CPU non superavano il 25% di utilizzo e la ram non arrivava ai 4GB
degli 8GB disponibili.
Ora, gia' in passato avevamo visto che client troppo vecchi (pentium2?)
e schede video troppo lente e con poca RAM potevano causare problemi di
fluidita' e prestazioni. E questo conferma un po' la tua esperienza.
Pero' mi verrebbe da dire che il problema sia rappresentato dai
requisiti minimi per far girare decentemente un linux minimale recente
con la sua sessione X-Server (che e' quello che l'utente client vede e
usa). Soddisfatti questi requisiti minimi la logica direbbe che non mi
dovrei aspettare un ulteriore incremento di prestazioni in quanto
appunto le elaborazioni avvengono sul server.
In tutto questo discorso entra forse anche il collo di bottiglia
rappresentato dalla rete; pero' (sempre in teoria) per un server
grafico
remoto non dovrebbe essere piu' pesante "disegnare a video" un'immagine
da 10Mb rispetto ad un'immagine da 500Kb in quanto al client non viene
trasferita l'immagine in se quanto le informazioni per disegnarla a
video, quindi dipendenti dalla sola risoluzione del monitor del client.
(a questo proposito mi viene in mente che adottare monitor recenti e
quindi magari risoluzioni su client piu' alte potrebbe causare
ulteriori
problemi di banda...)
Ovviamente sarei felice di essere corretto e/o smentito da chi conosce
meglio l'argomento e l'architettura che ci sta sotto.
Quindi, alla fine della fiera, *potrebbe* anche essere (e sottolineo
potrebbe) che la potenza di un raspberry sia sufficiente a far girare
una sessione X remota in maniera sufficientemente fluida.
Altro motivo: avrei intenzione di integrare la parte audio nello
scambio flussi dati tra server e client per provare a rendere la rete
LTSP multimediale e i flussi audio sarebbero un carico di lavoro in
più per la scheda raspy.
[cut]
Se (e dico se - le mie certezze vacillano quando parlo di cose che non
conosco perfettamente) quanto ho scritto sopra risultasse valido, lo
stesso varrebbe anche per la pesantezza dei flussi multimediali. Temo
quindi che il problema maggiore sia il limite di banda (rete ethernet)
e/o l'architettura X distribuita e non la cpu dei singoli client.
Se mi sbaglio pero' sarei contento, perche' vorrebbe dire che con CPU
piu' potenti la cosa sarebbe realizzabile :)
Ivan
Quando ho effettuato il test, lo switch che connetteva i thin client al
server era un full Gb a 24 porte di cui una libera, una per la NIC del
server (in Gb) e 20 per i thin client /circa 50 Gb per thin-client.
Quindi escluderei il limite di banda.
Se avessi la disponibilta' di una scheda migliore della raspy potremmo
fare alcune prove nel
laboratorio del LUG.
P.S.
Ho un dubbio su un applicativo per la gestione studenti (Angel Manager)
sviluppato da un certo Ivan Tarozzi, che potrebbe causare dei forti
rallentamenti alla rete LTSP.
Ovviamente scherzo!!!!
A proposito: per adesso Angel Manager ha funzionato perfettamente con
ubuntu LTSP 10.04 e 12.04......ma funzionerà con la 14.04???
Vi farò sapere.
Alla prossima
Giuseppe
---------------------------------------------------------------------
Per cancellarsi, scrivi a: riminilug-general-unsubscribe@xxxxxxxxxxxx
Se vuoi conoscere altri comandi, scrivi a:
riminilug-general-help@xxxxxxxxxxxx
---------------------------------------------------------------------
Per cancellarsi, scrivi a: riminilug-general-unsubscribe@xxxxxxxxxxxx
Se vuoi conoscere altri comandi, scrivi a: riminilug-general-help@xxxxxxxxxxxx