Link alla notizia: http://news.hwupgrade.it/7200.html

Nuova serie di dischi EIDE ad alte prestazioni da IBM: 60 GB per piatto e ben 8MB di cache, per rispondere alla concorrenza, sul mercato già da tempo con soluzioni simili

Click sul link per visualizzare la notizia.

Umm...
Quindi scenderanno di prezzo i GXP 120 ??
Potevano fare anche la versione con 4 dischi così arrivavano a 240 Giga !!! (non che sputerei sopra ai 180....)

Saluti

8MB di cache daranno un vantaggio prestazionale considerevole rispetto ad un IBM 7200 rpm con 2MB di cache? oppure cambia poco?

IBM può pure continuare a non affrontare il discorso serialATA tanto altri HD UATA io non ne compro. :)

Che belli ora li fanno gia' viola , perfettamente in tinta con il colore dei drappi funebri che si espongono quando ne bruci uno dopo 20gg dall' acquisto o il giorno dopo che e' scaduta la garanzia LOL :D

Ma cosa hanno scoperto all'IBM...a me non sembra ci sia niente di cosi ecclatante in questo HDD. Il mio HDD SCSI era cosi 2 anni fa!

mi lascia perplesso il discorso dei 180GB su U100, non si era detto che per sforare i 137GB si doveva usare un U133? cos'è una mezza misura?

IBM batte se stessa in prestazioni...

Visto che questo dischi arrivano a 56 Mb/sec, perchè non li hanno fatti con interfaccia ATA 133??? Con ATA100 due di questi dischi saturano la banda disponibile..... (almeno finchè uno dei due non si rompe :D )

Originariamente inviato da TheBig
[B]Visto che questo dischi arrivano a 56 Mb/sec, perchè non li hanno fatti con interfaccia ATA 133??? Con ATA100 due di questi dischi saturano la banda disponibile..... (almeno finchè uno dei due non si rompe :D )
LOL :D

In effetti ATA 100 arrivano come specifiche a non oltre i 132Giga(mi pare) evidentemente l'IBM xsegue la via del buon vecchio disk overlay che "tranlsa" le chiamate e xmette di montarlo anche su ATA100. Penso anche che il supporto ATA133 debba essere sulla scheda madre x supportare HD sopra ai 132Giga e che non sia necessario sull'HD, ma non ne sono sicuro.....

No l'ata 100 e neccessario solo per non soddisfare 1 disco, non 2....ecco ke l'ATA 100 e' + ke sufficente
anke se ho 2 3 o n diski l'unica cosa ke si satura e' il PCI e non l'ata 100....per i 137 giga non lo so :D

Originariamente inviato da TheBig
[B]Visto che questo dischi arrivano a 56 Mb/sec, perchè non li hanno fatti con interfaccia ATA 133??? Con ATA100 due di questi dischi saturano la banda disponibile..... (almeno finchè uno dei due non si rompe :D )

Ciao,

No, sul cavo EIDE passano i dati di una periferica sola, se sono attaccate due periferiche fanno "a turno".

Quindi, attualmente, basterebbe anche L'ATA66.

Ale
:)

Eh già !
Poi mi chiedo, chi è tanto masochista da lavorare con una singola partizione da 180 GB ?
Valla a deframmentare tutta, o a fare il backup alla necessità di reinstallare il sistema operativo... :rolleyes:
Io partizionavo già quando avevo l'hard disk da 8 GB! :)

secondo voi saranno fragili come i vecchi modelli? sotto quel punto di vista dovrebbero essere miliorati...

Originariamente inviato da Alessandro Bordin
[B]

Ciao,

No, sul cavo EIDE passano i dati di una periferica sola, se sono attaccate due periferiche fanno "a turno".

Quindi, attualmente, basterebbe anche L'ATA66.

Ale
:)

Mi spiace signor Bordin, ma lei ha torto. I dischi non fanno a turno. Sono le cache che fanno a turno. Le cache sul PCB del disco vengono alimentate in modo sostenuto, diciamo a 50 MB/s dai dati provenienti dai piatti. Se ho due dischi, prelevo dati a 100MB/s in media, sostenuti. Ora, se il mio canale, utilizzato questo si' a turno, ha una larghezza di banda di 66 MB/s, non posso leggere tutto quello che i dischi sarebbero in grado di fornire. Questo perche' la cache dei dischi puo' essere riempita a 50 MB/s sostenuti, ma letta con duty cycle del 50% a 100 MB/s, senza perdere dati (ed utilizzando meta' della larghezza di banda teorica del canale). Quindi, prescindendo dagli overhead, due dischi moderni saturano abbondantemente un canale ATA66.
I dischi in oggetto, se hanno 56 MB/s di tranfer rate sostenuto sulle tracce esterne, montati sul medesimo canale ATA100, lo saturano. Peggio con un ATA66. Inutile aggiungere che se si prende anche un controller ATA133, magari Raid e gli si montano dei dischi performanti (ATA133), e' difficile superare i 100 MB/s di trasferimento sostenuto, perche' ci sono problemi di banda anche sul BUS PCI (133 MB/s in modo burst). Chi fa le prove... e vede i risultati se ne avvede facilmente.
Saluti.

Provate a coprare i nuovi Maxtor diamondmax plus , poi vediamo quanto vi durano, il negozio del mio paese ne ha comprati 4, in meno di un mese tutti e 4 rotti............

Originariamente inviato da Mirko1024
[B]

Mi spiace signor Bordin, ma lei ha torto. I dischi non fanno a turno. Sono le cache che fanno a turno. Le cache sul PCB del disco vengono alimentate in modo sostenuto, diciamo a 50 MB/s dai dati provenienti dai piatti. Se ho due dischi, prelevo dati a 100MB/s in media, sostenuti. Ora, se il mio canale, utilizzato questo si' a turno, ha una larghezza di banda di 66 MB/s, non posso leggere tutto quello che i dischi sarebbero in grado di fornire. Questo perche' la cache dei dischi puo' essere riempita a 50 MB/s sostenuti, ma letta con duty cycle del 50% a 100 MB/s, senza perdere dati (ed utilizzando meta' della larghezza di banda teorica del canale). Quindi, prescindendo dagli overhead, due dischi moderni saturano abbondantemente un canale ATA66.
I dischi in oggetto, se hanno 56 MB/s di tranfer rate sostenuto sulle tracce esterne, montati sul medesimo canale ATA100, lo saturano. Peggio con un ATA66. Inutile aggiungere che se si prende anche un controller ATA133, magari Raid e gli si montano dei dischi performanti (ATA133), e' difficile superare i 100 MB/s di trasferimento sostenuto, perche' ci sono problemi di banda anche sul BUS PCI (133 MB/s in modo burst). Chi fa le prove... e vede i risultati se ne avvede facilmente.
Saluti.

Credo che mister Bordin con "a turno" volesse indicare che i dati che transitano sul bus sono di una perfierica per volta...infatti il trasferimento parte dalla cache...in effetti i dischi possono trasmettere contemporaneamente ma i dati finiscono in cache e li rimangono finchè non sono autoriazzati a trasmettere sul bus...la velocità massima possiamo averla quindi solo per gli 8 mega iniziali poi le prestazioni calano fino a livellarsi alle prestazioni del disco che non riesce a riempire la cache e quindi i dati vi transitano ad una velocità inferiore a quella imposta dal protocollo...

Originariamente inviato da edivad82
[B]

Credo che mister Bordin con "a turno" volesse indicare che i dati che transitano sul bus sono di una perfierica per volta...infatti il trasferimento parte dalla cache...in effetti i dischi possono trasmettere contemporaneamente ma i dati finiscono in cache e li rimangono finchè non sono autoriazzati a trasmettere sul bus...la velocità massima possiamo averla quindi solo per gli 8 mega iniziali poi le prestazioni calano fino a livellarsi alle prestazioni del disco che non riesce a riempire la cache e quindi i dati vi transitano ad una velocità inferiore a quella imposta dal protocollo...

Se provi a configurare un controller ATA in RAID, con dischi di prestazioni adeguate, scopri che le congetture in oggetto sono prive di fondamento. Cosa significa "solo per gli 8 mega iniziali"? La cache del disco 1 viene alimentata a 50 MB/s sostenuti dai piatti del disco 1.
La cache del disco 2 viene alimentata a 50 MB/s sostenuti dai piatti del disco 2.
Le due cache a turno sparano i dati sul canale IDE a 100 MB/s sostenuti.
Ci vuole molto a capirlo?
Se ancora insistete, vi consiglio di prendere due dischi decenti (D740X, GXP120) metterli sul medesimo canale del controller, e fare un po' di esperimenti (configurandoli in raid HW se il controller ve lo consente, oppure via software, con OS adeguato).
Poi abbassate ad ATA66 e vederete che spianata alle velocita' di lettura. Se invece scrivete tanto per scrivere... allora potete anche proseguire senza cognizione di causa.
PS: Secondo voi lo SCSI da 160 o 320 MB/s sul canale, per cosa l'hanno introdotto? Pensate che li' i device non trasmettano a turno? Il BUS e' sempre condiviso da tutti i device che ci si affacciano. Pertanto le prestanzioni aggregate crescono solo se il BUS non satura al crescere delle prestazioni aggregate dei device che vi si affacciano.
Cordialita'.

Questa è la prima serie di HD che nasce dalla "collaborazione" di IBM e Hitachi speriamo bene :D

Io cmq ho detto addio alla IBM che mi ha fatto perdere tempo e dati, quindi molto meglio le altre marche tipo Maxtor, che pur andando sempre a fortuna sugli HDD, sono meno difettati rispetto gli IBM.

Originariamente inviato da edivad82
[B]
Credo che mister Bordin con "a turno" volesse indicare che i dati che transitano sul bus sono di una perfierica per volta...infatti il trasferimento parte dalla cache...in effetti i dischi possono trasmettere contemporaneamente ma i dati finiscono in cache e li rimangono finchè non sono autoriazzati a trasmettere sul bus...la velocità massima possiamo averla quindi solo per gli 8 mega iniziali poi le prestazioni calano fino a livellarsi alle prestazioni del disco che non riesce a riempire la cache e quindi i dati vi transitano ad una velocità inferiore a quella imposta dal protocollo...

Credo che edivad82 abbia capito quello che volevo dire, al contrario di Mirko1024.

"Il BUS e' sempre condiviso da tutti i device che ci si affacciano".
Ovvio che sono condivisi. Nell SCSI però in contemporanea. Nell'EIDE no. E' il suo difetto da sempre.

ATA RAID? Le catene vengono gestite in maniera differente.

mi gusta molto il taglio minimo a 60 gb... non vedo l'ora che hd da 160 gb diventino + abbordabili.

partizionare un hd da 180 gb è una mezza cavolata... hd così grandi servono solo per l'archivio ad accesso rapido dei dati, non certo per il SO, non certo per tenere al sicuro dati senza backup (ho amici che ne hanno presi parecchi (decine, WD per ex ma anche Maxtor e IBM) di hd da 160 gb e se usati 24/7 in lavoro continuo se non raffreddati saltano, assicurato, o comunque perdono dati (tipo FAT))

il SO sta bene su due HD piccoli, il primo per il SO, il secondo per lo swap (a meno di farlo su ram), su canali diversi, ovviamente.
HD piccoli perchè sono più affidabili (meno testine, meno dischi, meno usura, meno calore, meno rumore)

ciao!

Si sa nulla della scelta circa la garanzia... si devono continuare a mandare in Papuasia con confezionamento in titanio e platino?

Si ma per uno che usa un solo hd è quindi meglio un ATA133 tipo D740X o un ATA100 tipo GXP120?????

Originariamente inviato da Folgore 101
[B]Si ma per uno che usa un solo hd è quindi meglio un ATA133 tipo D740X o un ATA100 tipo GXP120?????

la differenza è minima...non te ne accorgeresti! solo se sei alla ricerca di prestazioni "over the top" guarda alle caratteristiche...altrimenti guarda la portafogli!!;)

con questo non voglio dire che devi prendere l'hd che costa meno, voglio dire di trovare il giusto compromesso prezzo/prestazioni... se un ata 133 di marca X costa meno di marca Y ata 100 perchè non prenderlo ? (ponendo X e Y come affidabili)

Non avete detto la cosa piu importante:
ovvero che quaesto disco permette di avere il 25% di prestazioni in piu rispetto al modello precedente

Originariamente inviato da Mirko1024
[b]
[CUT]
Comunque è strano, anche io ho sempre saputo che l'IDE può gestire solo un flusso di dati alla volta. Questo è valido per le periferiche sullo stesso canale. Se l'HD master legge, lo slave non può scrivere e viceversa. Possono andare in contemporanea se sono su canali differenti:) , quindi anche un controller ATA 66 basterebbe, dato che la velocità massima è riferita al canale e non alla somma dei canali

Originariamente inviato da Mark-MBR

Comunque è strano, anche io ho sempre saputo che l'IDE può gestire solo un flusso di dati alla volta. Questo è valido per le periferiche sullo stesso canale. Se l'HD master legge, lo slave non può scrivere e viceversa. Possono andare in contemporanea se sono su canali differenti:) , quindi anche un controller ATA 66 basterebbe, dato che la velocità massima è riferita [B]al canale e non alla somma dei canali

Il fatto che si gestisca un solo flusso di dati non implica che l'ATA66 non venga saturato. Questo perche' i dischi dispongono di cache look-ahead.
Ora, ma dopo non replico piu', in quanto le cose che ho visto scritte dimostrano che chi ha fatto le obiezioni non ha fatto prove reali (e scrive senza cognizione di causa...), faccio l'ultimo esempio.
Devo leggere un file di 1 GB e voglio farlo in 10 secondi.
Dati alla mano, scopro che non esistono dischi che sparano 100 MB/s sustained e quindi decido per la soluzione banale di utilizzare due dischi, e scelgo ad esempio gli IBM menzionati.
Ipotizzo di proposito che questi dischi abbiano "per ipotesi" un sustained Transfer Rate di 50 MB/s (cosi' i conti si fanno sulle dita).
Li collego di proposito sul medesimo canale ATA100 (stiamo parlando di un BUS, e di colli di bottiglia). Uno come master, l'altro come slave. Il canale Secondario non lo uso (cosi' abbiamo chiarito come svolgiamo il test).
Memorizzo il file in modo opportuno, ricorrendo allo striping. Scelgo per esempio uno stripe size di 256 KB.
Cosa significa?
Che il mio file e' affettato a "fette" di 256KB ciascuna. Le fette di ordine pari verranno mandate al disco Master, quelle di ordine dispari al disco Slave.
Adesso comincio a leggere.
Leggo la fetta 1, dal disco master.
E questo mi utilizza il canale senza saturarlo. Per un tempo di 5 millisecondi. (non consideriamo gli overhead legati al seek, in quanto stiamo parlando di transfer rate sustained, non di seek sul disco).
Quindi chiedo la fetta 2 al disco slave.
E questo mi impegna il canale per altri 5 ms.
Perche' proprio 5 ms per leggere 256 KB, cioe' un quarto di MB? Beh.. perche' ho detto che i dischi viaggiano a 50 MB/s, pertanto 1s/200 = 5 ms. In 1 secondo potrei leggere 200 "fette" cioe' 50 MB.
Possiamo capire che nella migliore delle ipotesi, le prime due fette arriveranno ad una velocita' pari al massimo throughput del singolo disco (50 MB/s per restare in tema), ipotizzando che avessimo per caso le testine sui settori giusti (no seek, etc, etc.).
Insomma abbiamo letto mezzo mega in 10 ms. Quindi abbiamo lavorato a 50 MB/s di throughput.
Il bello inizia adesso.
I nostri dischi sono dotati di cache.
Mentre leggiamo la fetta 2, dal disco slave, CONTEMPORANEAMENTE nel Disco MASTER la fetta 3 sta alimentando la cache Look-ahead del disco medesimo.
Pertanto, quando andremo a chiedere la fetta 3 al disco Master, questo ce l'ha gia' pronta in ram e ce la spara fuori a 100 MB/s sul canale ATA100. Non gli servono piu' 5 ms... per darcela. Gliene bastano 2,5 di ms. Ovviamente il discorso vale anche per lo slave che alimenta la sua cache... ANCHE QUANDO noi chiediamo le "fette" dispari al disco master. Insomma, a regime i dischi sparano fuori 256 KB in 2,5 ms (leggono tali dati in 5 ms dai piatti, ma li riversano sul canale in meta' tempo, impegnando il canale stesso al 50%).
Se non siete convinti, prendetevi due dischi, metteteli sul medesimo canale ATA, e provate. Per riferimento, quando ho fatto le prove, usando un HPT370 e 3 dischi IBM due anni fa (erano dei DTLA307045), saturava il PCI (suppergiu' un centinaio di MB/s sustained).
Ho scritto 3, non e' un errore, perche' studiavo le inefficienze di soluzioni con due dischi su un canale e un solo disco sull'altro.
Per riferimento, con 2 dischi si arrivava a 75 MB/s sia che fossero sul medesimo canale, sia che fossero su canali distinti. I dischi facevano intorno ai 37 MB/s sustained ciascuno. Anche con 4 dischi non si migliorava, proprio per il problema del PCI che saturava.

Ultima ciliegina: le cose possono cambiare in funzione della strategia di caching dei dischi. Putroppo i Maxtor... non cachano come gli IBM! Incredibile ma vero (provare... per credere!).
Cordialita'.

c'è un errore nella notizia riportata:
la press realise parla di "ATA 6 interface", cioè di UDMA133, cosa che spiega come è possibile che il disco bbia tagli da più di 132GB.

Originariamente inviato da Mirko1024
[B]

Il fatto che si gestisca un solo flusso di dati non implica che l'ATA66 non venga saturato. Questo perche' i dischi dispongono di cache look-ahead.
.................
..............
.................
.................
Ultima ciliegina: le cose possono cambiare in funzione della strategia di caching dei dischi. Putroppo i Maxtor... non cachano come gli IBM! Incredibile ma vero (provare... per credere!).
Cordialita'.
Unico "difetto" di tutto questo ragionamento è l'assumere che in condizioni normali i dati siano sequenziali cosa quasi mai vera ;)
E' chiaro che il transfer rate sustained lo raggiungi solo se non hai bisogno di riposizionamenti.....come tu hai peraltro specificato.....
Il tuo ragionamento è chiaro e spiega perfettamente il concetto...
la mia voleva essere solo una puntualizzazione sul fatto che non ci si deve attendere 1 raddoppio di prestazioni xché i dischi IDE sono "lentissimi" nel seek....
Riguardo agli IBM penso che nessuno metta in discussione che sono degli ottimi HD, ma hanno solo 1 difetto :).....quello riscontrato da molte persone sul forum.....che si rompono di +!!!

Originariamente inviato da gianludovico
[B]c'è un errore nella notizia riportata:
la press realise parla di "ATA 6 interface", cioè di UDMA133, cosa che spiega come è possibile che il disco bbia tagli da più di 132GB.

http://www.linux-1u.net/Disks/

ATA-6 = ATA-100

UDMA Mode 6 = ATA-133

Originariamente inviato da Mirko1024
[B]


Ora, ma dopo non replico piu', in quanto le cose che ho visto scritte dimostrano che chi ha fatto le obiezioni non ha fatto prove reali (e scrive senza cognizione di causa...)


Cordialita'.

:D

Proprio cordiale.

Grazie per aver riportato la tua esperienza.
Hai preso però una situazione utilizzata nell'1% (se va bene) dei PC, in sutiazioni decisamente NON standard.

Scommetto che sei un ingegnere che vuole mettere i puntini sulle i sempre e comunque ;)

Sull'utilizzo normale rimango della mia idea, condivisa da praticamente tutti i produttori e non, fra cui ingenieri IBM e Maxtor contattati personalmente in più occasioni.

Originariamente inviato da Alessandro Bordin
[B]

:D

Proprio cordiale.

Grazie per aver riportato la tua esperienza.
Hai preso però una situazione utilizzata nell'1% (se va bene) dei PC, in sutiazioni decisamente NON standard.

Scommetto che sei un ingegnere che vuole mettere i puntini sulle i sempre e comunque ;)

Sull'utilizzo normale rimango della mia idea, condivisa da praticamente tutti i produttori e non, fra cui ingenieri IBM e Maxtor contattati personalmente in più occasioni.
Allora non sono l'unico ad aver pensato che era 1 ing :D!!!!

Certo che se prendiamo come esempio una soluzione in raid 0 (striping) certo che le prestazioni aumentano ma chi di voi ce l'ha sul suo pc per navigare o giocare??mettiamo caso che abbiamo due banalissimi dischi sullo stesso canale con un banalissimo controller ata...ci sarà un picco massimo e un livello medio di transfer rate che sicuramente sarà inferiore rispetto ai 100mb/s teorici!! il tuo discorso regge sulla carta non lo metto in dubbio, ma in situazione reali le cose sono diverse...non tutti hanno un array in striping...non tutti hanno un solo file sul'hdd su settori adiacenti...hai mai pensato che il bus è condiviso è non solo gli hdd "hanno voglia di chiaccherare" con la ram?? sicuramente quello che hai detto è un valido esperimento per quantificare in qualche termine l'utilità dei dischi ata-100/133 e del raid 0, ma è una situazione troppo dissimile alla realtà quindi è buona solo per la carta sulla quale è scritta...

io parlo con cognizione di causa, non mi metto a fare i discorsi così per "smerdare ";) la gente, ma per esprimere un giudizio, un'opinione, un chiarimento su un argomento...

cordialmente ;) :)

Vorrei soltanto aggiungere che il caso citato rasenta delle condizioni che sono ben lontane dal normale funzionamento di un hd.

2MB di cache si riempiono abbastanza velocemente, dopo di che bisogna attenderne lo svuotamento per cominciare a leggere/scrivere altri settori.

Nel frattempo la testina dell'hd se va a spasso a girarsi i pollici: non può mica stare ferma all'inizio del prossimo settore da leggere, perché il disco ruota. Soltanto quando si sarà liberato dello spazio nella cache si potrà cominciare a leggere/scrivere altri settori.

Considerando che la densità dei dischi aumenta a dismisura, e che in genere in ogni lato di un piatto esistono fino a 10 mila tracce, a conti fatti un hd da 40GB per piatto può arrivare a stipare 4MB o più per traccia, direi che dopo al più mezzo di giro la cache è già satura e si dovrà attendere il successivo passaggio della testina per tornare a leggere/scrivere i successivi dati (siamo sempre nell'ipotesi di una lettura sequenziale).

Tutto ciò senza considerare le varie politiche di allocazione del buffer, che dipendono dall'implementazione scelta dalla casa costruttrice. Inoltre alcune utilizzano parte dello spazio della cache per memorizzare il firmware e/o alcuni dati importanti...

A quanto scritto sopra aggiungiamo poi che è necessario un seek ad ogni spostamento di traccia, e arriviamo alla conclusione che il transfer rate teorico resta, appunto, teorico...

Ho cominciato da una settimana e poco più gli studi di ingegneria informatica all'università di Firenze, cominciando da 01001101011101010110001 e cose varie, e già mi rendo conto di quanto siano complessi gli standard, i BUS, le porte logiche e via dicendo... Purtroppo sono quasi d'accordo sul fatto che di solito gli ingegneri tendono a puntualizzare dall'alto del loro titolo...
Leggete i commenti all'articolo sull'aumento del BUS degli Athlon XP a 333 Mhz e rendetevi conto che non serve avere un processore a xxxx Mhz ma un disco veloce, non serve una Radeon 9700 su un Athlon 1333, non serve un monitor 19' su una GeForce2 MX...
Bisogna bilanciare le prestazioni, non cercare di tendere al massimo assoluto... anche perchè chi è che si può permettere di spendere 1000€ al mese in HW?
Vi parlo dalla modesta esperienza di assemblatore (ho iniziato a 16 anni) e ho visto una Elsa Gladiac 920 sprecata su un Pentium III 700, Case da più di 100€ con dentro M/B, 1 HDD e un CDRW... magari con 5 ventole...
Io volevo il meglio dal PC, ma credo che non si possa pretendere troppo, perchè a forza di tirare fuori novità si fanno errori (vedi KT400 rimarchiati KT333, AGP 8x inutilmente implementato) e spesso è l'utente finale a subirne i danni...
Scusate lo sfogo, ma l'informatica sta collassando su se stessa, nei forum vi scannate per 2fps in più u ATA100/133, ma che importanza ha, in fondo? Tanto tra 2 mesi un PC da 4000€ avrà un costo di meno della metà...

L'equilibrio è la chiave (Secondo ME).

Saluti e non sparate a zero sugli appassionati ma inesperti utenti; tanto di cappello agli ingegneri informatici che magari prendono in un mese quello che un operaio prende in un anno... Saluti ancora

KvL

Saluti e non sparate a zero sugli appassionati ma inesperti utenti; tanto di cappello agli ingegneri informatici che magari prendono in un mese quello che un operaio prende in un anno... Saluti ancora

KvL
[/B][/QUOTE]


Ma in che film???
Non vorrei spegnere i tuoi facili entusiasmi da matricola ma un ingegnere neoassunto prende mano di un operaio che fa i turni. Poi dopo qualche anno riesci a prendere qualcosa di decente ma siamo lontanissimi dalle cifre da te sognate! Poi ci sono delle eccezioni, pochissimi...
E ho molti amici ingegneri che lavorano in fior fior di aziende anche del mib30 in gamba e con esperienza! Se sei consulente informatico ti posso anche dare ragione ma devi essere un manico esagerato e "conoscere"!!!

CIAO!

Ragione, ragione.

Io non sono ne un ingegnere ne un perito informatico, anzi sono un chimico, ma il mio hobbie e' sempre stata l'informatica, e sono un autodidatta, da 6 anni ho imparato a programmare in alcuni linguaggi e ho espanso le mie conoscenze man mano che mi servivano (assemblaggio, grafica web design ecc).
Ho aperto uno studio ed eccola, basta poco con la laurea se sei forunato prendi 1200 € al mese cosa se riesci a prendere con 4 pagine di un sito in asp fatte in 2 ore :) , l'importante non e' il foglio di carta, tanto per le firme dei progetti o cazzate vari servono solo in architettura!.
Mi dispiace per gli Ing ma se devi fare l'impiegato, non buttare via 6 anni di univ!

IBM e' meglio che si metta a fare i cerchioni delle macchine almeno visto che i suoi dischi ,molto resistenti quando la testina spaccandosi va a sbattere contro i piatti, eviteremo di rigare i cerchini sui marciapiedi(premesso che non ho mai rigato un cerchione).
Proprio oggi ho riportato due hd ibm da 40 gb presi da 2 mesi al mio fornitore, due pc diversi , stesso difetto : screeeech screeeeeeecc, message from S.M.A.R.T : your data has fucked up by IBM.

MAxtor for Life

x KVL
Mi trovi assolutamente d'accordo con te. L'equilibrio è fondamentale per non buttare soldi inutilmente.
Purtroppo (ed è questo il mio caso) chi deve acquistare un PC nuovo cerca di puntare su configurazioni che ti garantiscano un minimo di longevità e quindi inevitabilmente si spostano sull'"alto di gamma".
Io ad esempio prenderò un sistema basato su una MB con SiS648, 512 bei MB di DDR/333 e ci metto sopra un bel P4 1,8 Ghz che costa relativamente poco. Poi con quella stessa MB, tra un annetto, mettu un bel P$ da 3GHz ed eventualmente mi diverto con un HDD S-ATA e una SK VID AGP 8X, se si dimostrerà che ne vale la pena.
Per ora bene anche il piccolo P4 e l'HDD ATA133 o addirittura 100.
Io, da NON esperto, la vedo così... ditemi voi...

x KVL
Mi trovi assolutamente d'accordo con te. L'equilibrio è fondamentale per non buttare soldi inutilmente.
Purtroppo (ed è questo il mio caso) chi deve acquistare un PC nuovo cerca di puntare su configurazioni che ti garantiscano un minimo di longevità e quindi inevitabilmente si spostano sull'"alto di gamma".
Io ad esempio prenderò un sistema basato su una MB con SiS648, 512 bei MB di DDR/333 e ci metto sopra un bel P4 1,8 Ghz che costa relativamente poco. Poi con quella stessa MB, tra un annetto, mettu un bel P$ da 3GHz ed eventualmente mi diverto con un HDD S-ATA e una SK VID AGP 8X, se si dimostrerà che ne vale la pena.
Per ora bene anche il piccolo P4 e l'HDD ATA133 o addirittura 100.
Io, da NON esperto, la vedo così... ditemi voi...