Sign in to follow this  
Guest

Cella Frigorifera per le vecchissime discussioni

Recommended Posts

Guest

no, per via del fatto che qualcuno un bel di' decise che i MHz erano l'unita' di misura della velocita' del processore...

ed ovviamente non scelse cio' in cui le superworkstation costosissime erano irraggiungibili, cioe' la banda passante a disposizione del processore...

(peraltro anche apple, al tempo dei 180Mhz, se la tirava su questo argomento... a ragione peraltro... fra PPc603 e Pentium c'era un abisso... ah, bei tempi andati...)

riguardo alla latenza, forse (di nuovo) c'e` qualcosa che mi sfugge: mi date una definizione ben precisa di essa?

Share this post


Link to post
Share on other sites

Mi aggiungo alla discussione perche' adesso che la Apple ha messo in giro i nuovi Ti con Combo di serie potrebbe scapparci una bella offerta sulle giacenze di magazzino e vorrei approfittarne. L'unico mio dubbio riguarda, tanto per cambiare, la scheda video. Premetto che l'uso serio del Ti riguarderebbe quasi tutti applicativi ad interfaccia di riga che girano bellamente sotto X in un teminale , pero' vorrei fare anche un po' di videoediting per diletto e magari sfracassare qualche testa a UT (sempre per diletto). La pletora di porte che ha il Ti rispetto all'Ibook mi tranquillizza per quanto riguarda il videoediting, ma per i giochi? Visto che si tratta di una bella spesa mi sto chiedendo se non mi convenga stringere i denti ed aspettare come evolve la situazione, diciamo entro Marzo, visto che per lavorare posso arrangiarmi altrimenti. Infatti comunque vada i nuovi Ti, se ci saranno, verranno ricollocati nelle medesime fascie di prezzo delli attuali e male che vada monteranno la stessa scheda video.Si accettano tutti i punti di vista.

saluti Gianmarco

Share this post


Link to post
Share on other sites

Mi intrufolo nella vostra discussione tecnica aprendo una parentesi, ricollegandomi al topic del thread. Vorrei raccontarvi quello che mi e' successo in questi ultimi 3 giorni.

Da appassionato utilizzatore di Mac ho deciso di approdondire le conoscenze sul mondo Unix introducendo nel mio umile studio casalingo una nuova macchina acquistata da un privato per la modica somma di 400 Euro. Irix era uno dei pochi sistemi Unix che non avevo mai utilizzato, cosi' come non avevo mai messo mano su macchine con processore MIPS. Nella fattispecie si tratta di un SiliconGraphics Indigo2 con processore R4400 a 250 Mhz con 64Mb di RAM, un paio di schede grafiche acceleratrici e architettura scsi. La tentazione di fare test comparativi col mio G4-350PCI e' stata forte, e ha occupato le ultime 48 ore delle mia vita. Non sto qui a farvi un lungo elenco di dati, mi limito a dire che utilizzando software opensource non ottimizzato per SGI (che quindi utilizza solo il processore e non gli acceleratori grafici) ottengo risultati mediamente superiori al G4. L'applicazione dei filtri piu' pesanti di GIMP a immagini superiori ai 50 Mb sono l'unico test nel quale il G4 supera il SGI, forse anche per i suoi 640 Mb di RAM. Al contrario i renderings in Blender sono piu' veloci sul SGI, e in generale la fluidita' dell'interfaccia di questi due software di authoring e' migliore su Irix. Immagino che con software ottimizzati per SGI come Photoshop e Maya si possano ottenere risultati altrettanto buoni se non migliori rispetto al mio G4 e forse anche a G4 piu' potenti. Ora, data per scontata la superiorita' Mac da moltissimi punti di vista, in certi casi credo che altre architetture possano essere altrettanto valide, a parita' di costo, specialmente per tasks ben definiti come (nel mio caso) il 3d orientato al web. Sono rimasto veramente stupefatto di come una macchina del 1995 possa competere con architetture e tecnologie decisamente piu' nuove.

Share this post


Link to post
Share on other sites

Chest: <FONT COLOR="ff0000">Attendiamo Camillo per una definizione della latenza</FONT>

Fondamentalmente, "latenza" è un sinonimo tecnico di "ritardo".

Chest: <FONT COLOR="ff0000">Inutile dire che il throughput può essere 100 volte più grande di quelli di adesso. Almeno, non vedo limiti fisici.

Ma la latenza, se ho ben capito NON PUO' andare oltre il ghz a distanza superiori ai 15 cm.</FONT>

Mi sembra che tu abbia capito bene.

Per la precisione, la latenza è un tempo. Su un bus sincrono, la latenza fra la richiesta di un dato da parte del processore e la sua ricezione è pari al periodo di clock (non alla frequenza).

Il tempo di propagazione di un segnale elettrico su un bus di 15 cm (andata e ritorno) è:

tp = 0.15 m * 2 / (2/3 * 300M m/s) = 1.5 ns

(2/3 c è la velocità del segnale elettrico nel rame.)

Il periodo del bus deve essere pari o superiore alla somma del tempo di propagazione del segnale e dei ritardi imposti dai dispositivi sul bus. Assumendo di avere dispositivi infinitamente veloci, il periodo minimo è pari al tempo di propagazione.

La frequenza massima del bus è l'inverso del periodo minimo, e dunque:

fmax = 1/tp = 666.6_ MHz (decimale periodico)

Ma il limite reale è ancora inferiore, visto che non si possono realizzare dispositivi di velocità infinita.

<FONT COLOR="ff0000">Del resto throughput immensi e latenze basse significa che i processori vengono investiti da quantità immense di dati a fronte di quelli che hanno "realmente" richiesto, per cui devono andare a impelagarsi con tutte le pippe predittive e amenità varie per Orazio di Clarabella.</FONT>

Qui invece mi pare che tu non abbia capito bene. Il throughput è meglio averlo alto, la latenza è meglio averla *bassa*.

Comunque, anche avendo un throughput alto e una latenza alta, i procesori non verrebbero "investiti da quantità immense di dati a fronte di quelli che hanno "realmente" richiesto" (?). A meno che tu non ti stia riferendo al caso in cui il processore è interessato ad una quantità di dati minore della larghezza del bus: per esempio, un PowerPC che vuole leggere 16 bit; in tal caso, è effettivamente "costretto" a ricevere 48 bit in più, per un totale di 64.

<FONT COLOR="ff0000">Se ci pensate è diabolico avere aumentato a dismisura il clock senza avere allargato il bus. Cioè mandare tantissime pippine di dati MA SPESSO anzichè tanti dati alla volta ma meno frequentemente.</FONT>

Mi sa che non hai capito bene. Questo è praticamente il contrario di quello che hai detto prima. E in ogni caso è sbagliato. A parità di throughput, è meglio avere un clock alto e un bus stretto piuttosto che un clock basso e un bus largo. Questo perché un clock più alto permette di avere una latenza più bassa (= migliore).

Il problema dei bus di Intel non è che ha aumentato i MHz, ma proprio il contrario: ha aumentato il throughput, diminuendo però la frequenza reale del bus.

luca: <FONT COLOR="119911">ed ovviamente non scelse cio' in cui le superworkstation costosissime erano irraggiungibili, cioe' la banda passante a disposizione del processore...</FONT>

Un bus da 32 bit a 200 MHz è meglio di un bus da 128 bit a 50 MHz.

Il motivo per cui le workstation si distinguevano soprattutto per la larghezza del bus è semplice: aumentare la larghezza costava, ma era possibile; per aumentare la frequenza, invece, non c'era la tecnologia.

Share this post


Link to post
Share on other sites

Se vi interessa, date un'occhiata a questo vecchio articolo di Stuart Cheshire.

Cheshire si concentra principalmente sulle reti a larga scala, e non tutto quello che vale per esse si applica anche al bus locale di un computer; tuttavia, l'articolo è ugualmente molto interessante.

Share this post


Link to post
Share on other sites

per frank

comunque se ti interessa e' possibile ordinarlo

il codice apple e' 600-9574.

ho chiesto lumi al mio fornitore

il materiale con cui e' costruito deve essere proveniente da qualche laboratorio spaziale visto che il prezzo per questo piccolo adattatore e' di circa 60.000 lire (iva esclusa)

Share this post


Link to post
Share on other sites
Guest

Chest> da <FONT COLOR="ff0000">Olaf, posso sbagliare, beninteso</FONT> a <FONT COLOR="ff0000">La fisica però dice che qualunque sia l'uso dei dati sparati da A, e qualunque sia la loro natura fisica, un eventuale segnalo/dato di ritorno da B che abbia fatto uso di un dato di A non può viaggiare a velocità superiore a quella della luce!!!</FONT>

va tutto bene: i MHz dicono quante volte vengono "sparati i dati".

Il problema è che tu continui a essere convinto che nello stesso ciclo i dati devono partire E arrivare, cosa non vera. Una volta che capirai che questo non è necessario comprenderai il mio discorso.

Infatti il tuo ragionamento è perfettamente corretto, solo che quando si dice che i computer sono "sincroni" non si intende che in un ciclo di clock fanno quello che tu dici (cioè che in un ciclo il dato si fa tutta la lunghezza).

All'istante zero il processore invia una richiesta, che impiega UN CERTO NUMERO DI CICLI ad arrivare alla ram che ci metterà 3 o 2 cicli (il CAS delle ram) a rispedirli, cosa che richiederà tempo: lo stesso richiesto alla richiesta per arrivare alla ram.

Perchè la cache è vicina? proprio per diminuire il tempo morto di percorrenza!!

Non ti sembra logico? il processore invia la richiesta, che ci mette del tempo e viene processata. Se l'unità che la processa è più vicina, il tutto richiederà meno tempo e quindi il processore ha meno "perdite di potenza".

<FONT COLOR="ff0000">Diego: Che io sappia i comuputer lavorano in sincrono. Quindi per ogni ciclo di clock il segnale parte e arriva.</FONT>

<FONT COLOR="119911">Bravo Diego! Questo è proprio il nocciolo della questione.</FONT>

Camillo! mi deludi! pensavo tu correggessi Diego!

Vabbé, l'ho fatto io qui sopra.

Camillo ha ragione quando parla di latenza e throughput, faccio un appunto in generale: i grandi supercomputer hanno tempi di latenza così grandi che nei tempi morti eseguono altri programmi!!!

Per quanto riguarda Hany, gli chiedo una cosa: com'è il istema operativo? tipo linux (quindi un morore fra configurazione e simili) o tipo Mac?

Share this post


Link to post
Share on other sites

Diego: :<FONT COLOR="ff0000">Che io sappia i comuputer lavorano in sincrono. Quindi per ogni ciclo di clock il segnale parte e arriva.</FONT>

Camillo: <FONT COLOR="0000ff">Bravo Diego! Questo è proprio il nocciolo della questione.</FONT>

Olaf: <FONT COLOR="ff6000">Camillo! mi deludi! pensavo tu correggessi Diego!</FONT>

Mi sa che ho fatto un po' di casino. [riguardo i messaggi precedenti] Sì, infatti.

Allora.

Su un bus sincrono, il segnale si deve fare tutta la lunghezza entro un periodo di clock. Su questo non ci piove.

Tuttavia, il protocollo di comunicazione delle RAM moderne non richiede che la richiesta del processore e la risposta della RAM avvengano sullo stesso ciclo. [Così imparo a fidarmi di vecchi documenti tecnici degli anni '70! ^^;;;;;]

Quindi, ecco cosa succede con una SDRAM moderna:

1) il processore attiva una riga di celle (Row Access Strobe + indirizzo riga sull'Address Bus)

2) y cicli dopo, il processore richiede la lettura di una colonna (Column Access Strobe + indirizzo colonna sull'AB)

3) x cicli dopo, la RAM invia i dati richiesti, una cella per clock, secondo la configurazione di burst impostata (in pratica, non manda solo la colonna richiesta, ma anche altre, per ottimizzare il tutto)

x-y-z sono i tre numeri del rating della RAM. x è la latenza CAS (tempo di attesa fra il CAS e l'inizio del data burst), y è il ritardo da RAS a CAS, e z è il tempo di precarica del RAS (non indicato nella sequenza di passi precedente); tutti e tre i tempi sono indicati come multipli del periodo di clock.

Le tre fasi indicate sopra, come si è visto, possono essere separate da uno o più cicli; tuttavia, ciascuna trasmissione (RAS dal processore alla RAM, CAS dal processore alla RAM, singolo dato dalla RAM al processore) si completa in un singolo ciclo.

Di conseguenza, i miei calcoli sulla frequenza massima vanno modificati come segue:

Il tempo di propagazione di un segnale elettrico su un bus di 15 cm (sola andata) è:

tp = 0.15 m / (2/3 * 300M m/s) = 0.75 ns

La frequenza massima del bus è l'inverso del periodo minimo, e dunque:

fmax = 1/tp = 1.3_ GHz (decimale periodico)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this