Newsgroup: it.comp.reti.locali
Titolo: Fileserver+printserver

Ciao, dovrei acquistare un file server e lo stò cercando da un pò con queste
caratteristiche:
-Ottima marca o almeno molto buona
-2 hdd EIDE sostituibili con qualsiasi modello in commercio
-Raid 1 mirroring :D
-scheda interna 10/100 (ovvio)
-almeno 1 , meglio 2 porte lpt
-compatibile tcp/ip
-software compatibile XP
-prezzo competitivo
-distributore on-line
Sapete come aiutarmi?????
Grazieeeeee
/V\ech
__________________________________________________________________ /V\ech
ICQ#: 68099992 Current ICQ status: + More ways to contact me i See more
about me: __________________________________________________________________

 -software compatibile XP
Cosa intendi per compatibile XP?
Considera che come file e print server per macchine Windows, linux + samba
va benissimo e costa zero.
Ciao
Luca

 linux + samba va benissimo e costa zero.
ed e' meglio di XP, inoltre ti permette di integrare reti Unix-Windows
meglio di quanto XP riuscirà a fare tra 10 anni. Vai con la "Samba"

 della 10/100 come interfaccia.
Forse dimentichi che uno dei compiti principali di un print server e' quello
di liberare il client al piu' presto.
Con un raid 0 (che molti miei Clienti usano), dai al server la possibilita'
di fare lo spool di PostScript di grosse dimensioni senza problemi, proprio
perche' l'input del rip o della coda non va oltre 100Mbps.
Ciao
Luca

 perche' l'input del rip o della coda non va oltre 100Mbps.
riceve il comando sempre dallo stesso mezzo, la rete a 10/100 (1000) che nel
caso del rip non influisce visto che il grosso del lavoro viene eseguito
nella macchina server

 ha scritto nel messaggio
news:SSDL65...@sasdelli.it...
comunque non gli fa male se lo spool (e lo swap) avviene in un Raid 0....
ritengo sia superfluo con i costi della RAM che fanno un caching alla grande
prima di raggiungere il disco.

> ma il collo di bottiglia e' nel 10/100 Mbps!
Appunto. Il client invia uno stream di dati che non puo' essere accettato
subito dalla printer, a meno che questa non disponga di un disco interno di
spool.
In questo modo il client salva (stampa) nello spooler a 100Mbps, poi
quest'ultimo se la vede con la stampante.
Ciao
Luca

 prima di raggiungere il disco.
Nel caso di una sola stampa, puo' darsi. Il guaio e' che e' difficile
riservare tot RAM per lo spool, e che se intervengono parecchi processi di
stampa contemporaneamente, il disco di spool e' indispensabile per
risolverli tutti senza creare intoppi in input.
Forse l'uso di un raid0 non sara' proprio da tutti i giorni, ma i Clienti
presso i quali l'ho installato come spool hanno visto una grossa
compressione dei tempi di stampa da client a print server. E, osservando da
vicino con qualche tool, mi sono reso conto che il disco di spool, specie
con stampe simultanee, fa veramente un lavoro allucinante.
Ciao
Luca

 quest'ultimo se la vede con la stampante.
ma, ma, ma! Se i dati arrivano a 100Mbps (12,5 Mbyte/s teorici, 7 pratici)
tu credi che un disco IBM da 35 Mbyte/s non riesca da solo a ricevere il
flusso senza intoppi?
Fai una prova su un file da 1G e dimmi se ti accelera di piu' di 1-2%! Ti
assicuro che non te ne accorgi.

 flusso senza intoppi?
E perche` mai dovrebbero arrivare a soli 100Mbit/s ? Le schede a 1000
esistono, l'aggregazione di banda esiste ;)
'il client salva (stampa) nello spooler a 100Mbps' non esclude che si
voglia che piu` client *conteporaneamente* sparino i dati nello spooler
a 100Mbit/s.
E poi siamo d'accordo che i dischi riescono a gestire il transfer rate
di una scheda a 100, ma se ho una decina di client che si contendono
le testine di un solo disco, il discorso e` totalmente diverso.
Le specifiche degli hd si riferiscono al 'sustained transfer rate'. 
Avere piu` dischi su cui scrivere ti permette di parallelizzare le 
operazioni di seek ed indubbiamente aumenta il throughput.
-- 
Vincenzo 
Le donne non sanno di essere sedute sulla loro fortuna.

 operazioni di seek ed indubbiamente aumenta il throughput.
se una NIC 100 (200) mi satura il bus verso il disco allora vendo il PC e
lavoro con Linux in DiskLess!

 diverso.
Ma nemmeno per idea. Se ti facessi due calcoli senza nemmeno scendere
troppo nei dettagli, anche prendendo i casi migliori per hd e flusso 
di rete avresti:
- Average seek-time di un disco performante = 8 ms.
- Tempo di ricezione di un pacchetto nel caso migliore per l'hard disk
  (ovvero pacchetto di 1500 byte) : circa 0.1 ms.
C'č una diffrenza di quasi *due* ordini di grandezza.
Metti insieme le cose e cerca di immaginare 10 client che
sparano dati *anche* avendo una sola coda di input a 100Mbit/s.
Immaginando che i dieci client si dividano in modo equilibrato
il canale (non c'č motivo per pensare il contrario), avresti che 
ogni 0.1 ms la testina del disco dovrebbe cambiare zona in maniera 
*non prevedibile* (non stai scrivendo un file contiguo). Peccato 
che la stessa testina lo possa fare mediamente solo in 8 ms.
Ci sono poi tutta una serie di fattori sulla memoria del printer
server (che comunque č una risorsa limitata e costa molto di piů
dello storage magnetico, per cui non avrebbe senso avere una macchina
con 100Giga di ram, avrebbe molto piů senso economico avere una
batteria di storage magnetico in raid) e sulla 'intelligenza' del
controller scsi che puň in parte sopperire ai tempi di seek delle
testine riordinando i comandi e usando altre tecniche. Ma tutto
questo ben difficilmente ti porta ad annullare un fattore di quasi
due ordini di grandezza.
-- 
Vincenzo

 con 100Giga di ram
la cache ovviamente non ha senso se totalmente copre la capacità del disco.
Non ci sono dubbi e nessuno ha accennato a 100G di ram

 ma non posso continuare se non consideri il funzionamento nel suo insieme
Tutti i livelli di cache che vuoi ma... la cache e` una risorsa 
limitata, non basta a far scomparire i colli di bottiglia del sistema nel 
suo complesso. Per essere chiari, dopo un po` la cache si riempie se
ho 10 macchine che vogliono scrivere su 10 parti diverse del disco.
Ed il collo di bottiglia nel tuo printer server di rete con un disco solo
e` indubbiamente il seek time dell'hard disk.


 ho 10 macchine che vogliono scrivere su 10 parti diverse del disco.
balle, e' evidente che non conosci il video editing (Adobe Premiere) o
l'audio editing con programmi quali CuBase!
Queste sono le bestie nere che trovano colli di bottiglia anche nella
profondità-bit del video, oltre che nel IO del disco.
Centinaia di campioni (file aperti e chiusi) in realtime, flussi di dati da
10-15 Mbyte da garantire al fotogramma ed altro.
Credimi che la cache assolve molto bene il suo lavoro, e cosi' pure le nuove
generazioni di dichi "ultraveloci" della IBM e (un po' peggio) della Maxtor.
Chiudo e resto dell'idea che uno stripe per un flusso di stampa basta per un
intera casa editrice.
Inultile continuare questa discussione, restiamo sulle nostre reciproche
posizioni, se vuoi mi trovi (ogni tanto) su it....storage.

 intera casa editrice.
Lontano da me l'intenzione di spingere verso la polemica; l'argomento, oltre
che interessarmi, e' gran parte del mio lavoro; quindi posso portare una
testimonianza diretta e concreta.
Personalmente, posso assicurarti che l'adozione di print server con un
sottosistema veloce di spool risolve *sempre* problematiche di code di
stampa. E non mi riferisco alla tipografia sotto casa, bensi' a grandi
stampatori nazionali o fotolito con decine e decine di client. E anche a
soluzioni specificatamente studiate da Case come Agfa, Creo, Scitex,
Heidelberg, Linotype-Hell.
La sola stampa di una cianografica a colori puo' pesare oltre 2GB, e sul
server di stampa ne arrivano a decine al giorno. Senza il server di stampa,
il processo di stampa puo' comportare tempi inaccettabili che mettono
letteralmente fuori uso parti del workflow.
Cio', per non stare esageratamente OT, non include l'efficienza stessa della
rete, ma la velocita' intrinseca delle unita' di uscita, generalmente per
nulla ottimizzate sotto questo aspetto.
L'aspetto critico dell'intero processo, quindi, e' la banda passante del
processo di stampa, che coinvolge tutti i dispositivi interessati dal
transito dei dati in questione. Una memoria di spool con un sustained
transfer rate di 30-40MB/sec e', in assetto industriale (la "casa editrice"
alla quale accenni), insufficiente.
Se fosse stato perso di vista, non stiamo parlando di multimedialita', ma di
stampa; ricordo che una pagina A4 in bitmap CMYK pesa 38MB; in PostScript si
puo' arrivare tranquillamente oltre i 100MB in composito. Dieci client che
stampano a questo ritmo su due o tre RIP rischiano di restare incollati al
processo di stampa per ore, ovviamente riducendone la banda passante in modo
drammatico.
File di questo tipo non beneficiano per nulla di nessuna cache, poiche' si
tratta di file di grandi dimensioni che nulla o quasi hanno in comune, per
cui il normale funzionamento di una cache hit/miss e' solo uno spreco di
risorse. La memoria di massa, invece, si pone come elemento critico
nell'intero flusso dati e spesso un raid0 riesce a malapena a reggere il
carico. Una cache si saturerebbe nel giro di secondi.
Con un server dotato di spool veloce, il processo si riduce a pochi minuti a
testa, con grande risparmio di tempo e di denaro.
E questo risparmio e' proporzionale alla velocita' del print server.
Questo, quindi, da esperienza personale, quotidianamente verificata sul
campo e confortata dalla scelta progettuale delle massime aziende
produttrici nel settore prestampa.
Ciao
Luca

 File di questo tipo non beneficiano per nulla di nessuna cache
concordo, la cache intervine proprio nei file di piccole dimensioni
Ti ringrazio del chiarimento, completo e preciso. Restiamo tutti
dell'opinione che un tale server e' sovradimensionato per l'uso che il primo
messaggio si era prefissato oppure il suo caso era uno di quelli da Luca
menzionati?

 l'audio editing con programmi quali CuBase!
Ok, stai continuando a paragonare mele con pere. 


 ho 10 macchine che vogliono scrivere su 10 parti diverse del disco.
mah.. sarò scemo ma adesso un 512 mega di ram sono assolutamente abbordabili
e prima che la rete mi riempia la ram il disco fa a tempo ad andarsene in
vacanza  e quando torna si trova gia i blocchi ordinati per minimum seek..
che dite, al sitema operativo gli facciamo fare qualcosa di utile o è solo
un interfaccia grafica per i bambini paciocconi ? :)
