Secondo la definizione ufficiale proposta da OSHWA.org: “Le soluzioni hardware aperte sono soluzioni il cui design è pubblicamente disponibile e aperto allo studio, alla modifica, alla distribuzione e alla vendita. Ciò vale sia per la soluzione stessa che per i suoi derivati ​​e componenti. I dati del progetto originale e le sue componenti devono essere presentati in un formato che consenta la loro ulteriore modifica. Idealmente, l’hardware aperto utilizza strumenti e materiali prontamente disponibili, processi standard, infrastrutture aperte, contenuti gratuiti e strumenti di sviluppo open source per offrire agli utenti la massima libertà nel suo utilizzo”.

Vale la pena notare qui che le piattaforme hardware aperte non sono tenute a offrire strumenti di sviluppo gratuiti. Gli "strumenti di sviluppo" si riferiscono a un'ampia gamma di strumenti di progettazione e debug, che vanno dalla strumentazione (multimetri, oscilloscopi) e ambienti integrati (IDE), alle utilità basate sul web che forniscono una gestione funzionale dei progetti. È importante notare che molte delle piattaforme open source più note, come Arduino, LaunchPad, BeagleBone e STM Nucleo, forniscono librerie software gratuite, esempi di codice e persino interi ambienti integrati come l'IDE Arduino o mbed.org.

Alcuni strumenti di sviluppo sono essi stessi piattaforme aperte, il che li rende altamente accessibili grazie al loro costo relativamente basso. Un esempio è la scheda di misurazione universale Red Pitaya che esegue Linux. In sostanza, Red Pitaya è un complesso di misurazione che sostituisce le apparecchiature di laboratorio inaccessibili agli utenti ordinari a causa del suo prezzo elevato. Red Pitaya offre agli sviluppatori ingressi analogici con velocità di misurazione fino a 125 MSPS e uscite con velocità di 100 KSPS. Questo versatile strumento può funzionare come una varietà di strumenti standard, come ad esempio: oscilloscopio con una larghezza di banda di circa 50 MHz, analizzatore di spettro, misuratore di impedenza LCR, analizzatore di Bode, Teslametro, generatore di funzioni con risoluzione a 14 bit, incluso adatto per audio, ecc. . Per visualizzare i risultati della misurazione, Red Pitaya si collega a un tablet, PC o smartphone. Aggiungi il modulo di estensione del sensore e puoi collegare Red Pitaya alle schede Arduino e ai sensori SEEED Studio Grove, che amplieranno ulteriormente la funzionalità di questo complesso di misurazione.

Riso. 1. Il sistema di misurazione universale Red Pitaya è un esempio di piattaforma hardware aperta ed è caratterizzato dalla massima disponibilità. Red Pitaya ha la funzionalità di un oscilloscopio, un analizzatore di spettro, un misuratore di impedenza, un analizzatore di Bode, un Teslametro, un generatore di funzioni, ecc.

Il tabellone Red Pitaya è stato introdotto sulla piattaforma Internet Kickstarter nel 2013. È diventato uno spin-off di un'azienda che sviluppa strumenti per acceleratori di particelle. In sintesi, Red Pitaya è uno strumento di misurazione e controllo open source con supporto di programmazione visiva. Red Pitaya è supportato da Matlab, LabView, Python e Scilab. Grazie al suo codice open source, le capacità di Red Pitaya possono essere ampliate con funzioni e utilità aggiuntive create dagli utenti.

Molte piattaforme aperte possono anche essere trasformate in strumenti di sviluppo. Ad esempio, puoi creare un analizzatore logico digitale utilizzando Arduino UNO. Tuttavia, vale la pena notare che questa non è la funzione principale di tali piattaforme. In sostanza, la maggior parte delle soluzioni open source sono progettate per aiutare con test, debug e risoluzione dei problemi. Tuttavia, anche la migliore scheda di sviluppo è inutile se non dispone di una documentazione completa e dettagliata.

Diamo un'occhiata agli strumenti più comuni utilizzati quando si lavora con piattaforme hardware aperte.

1. Il primo strumento di progettazione è forse il più importante e il meno “tecnico”. Questa è una matita normale. È la matita che ti permette di "incarnare" istantaneamente le idee concepite su carta, contrassegnare i risultati dei test e registrare le modifiche per poi ripristinare l'intero quadro del progetto mesi o addirittura anni dopo.
2. Attrezzatura. Ciò include una vasta gamma di strumenti, che vanno dagli strumenti di misura (multimetri, oscilloscopi) agli organizzatori per la conservazione di componenti elettronici. Sfortunatamente, l'attrezzatura è tutt'altro che gratuita, ma se sei vicino alla comunità degli sviluppatori, prendere in prestito l'uno o l'altro dispositivo di misurazione non sarà un problema. Inoltre, molti strumenti sono ora disponibili nei negozi online e vengono venduti a prezzi molto bassi.
3. La programmazione in codice macchina non è facile, quindi compilatori e interpreti vengono utilizzati per creare software incorporato, consentendo agli sviluppatori di scrivere programmi utilizzando linguaggi di alto livello o persino eseguire programmazione grafica.

Un altro strumento per lo sviluppo di software incorporato sono gli ambienti integrati (IDE). Gli IDE sono piattaforme software che combinano un editor di codice sorgente, un compilatore/interprete, un debugger, uno strumento di automazione della compilazione e talvolta strumenti di test. Molti ambienti integrati consentono di eseguire il debug del codice e di analizzarne il funzionamento in dispositivi reali. Esistono strumenti che possono aiutarti a visualizzare il funzionamento del dispositivo ed eseguire simulazioni prima che venga costruito il prototipo vero e proprio. Gli IDE ottimizzano e accelerano significativamente il processo di sviluppo.

Gli strumenti di sviluppo e modifica del software vengono generalmente creati per core di processore specifici. Per la maggior parte delle schede, i produttori specificano quale ambiente di sviluppo utilizzare.

Diamo un'occhiata ai principali tipi di IDE utilizzati per creare software incorporato:

1. Ambienti di sviluppo integrati (IDE) gratuiti, ad esempio Arduino IDE, Energia IDE per TI LaunchPads, che possono essere scaricati gratuitamente dal sito Web del produttore e installati sul proprio PC.
2. IDE online che non richiedono installazione su PC, ma richiedono l'accesso a Internet. I loro vantaggi sono che non richiedono aggiornamenti e non occupano spazio sul disco rigido. Un esempio di tali programmi è Mbed.org.
3. Ambienti di sviluppo a pagamento. Come accennato in precedenza, i compilatori consentono di lavorare con un certo tipo di core del processore e, per essere precisi, con un certo insieme di processori/microcontrollori specifici. Se ad esempio utilizzate una coppia di processori con core ARM ® Cortex ® -M4, può benissimo darsi che un processore sia supportato dall'IDE, ma l'altro no. Pertanto, prima di acquistare un IDE, dovresti verificare che il processore di destinazione sia nell'elenco dei dispositivi supportati. Esempi di ambienti di sviluppo a pagamento includono Keil di ARM e IAR Embedded Workbench di IAR Systems.
4. Prove gratuite di ambienti a pagamento con limiti di tempo. Molti IDE, come IAR e Keil, offrono prove gratuite con un periodo gratuito limitato. Al termine del periodo di prova, il programma viene bloccato e richiede l'acquisto di una licenza.
5. Versioni gratuite di ambienti a pagamento con funzionalità limitate. Esistono versioni limitate di ambienti a pagamento con funzionalità ridotte. Un esempio di tale ambiente è l'assieme Keil per microcontrollori STM32L0 con una limitazione sulla dimensione del codice.
6. Framework gratuiti e open source, come varie soluzioni GNU. Un esempio di ambiente gratuito è l'IDE Eclipse. Eclipse IDE ti consente di aggiungere plugin per supportare vari linguaggi di programmazione, in particolare C++ o Python. Vale la pena notare che nella maggior parte dei casi i compilatori gratuiti sono inferiori alle loro controparti commerciali in termini di qualità dell'ottimizzazione del codice. Tuttavia, col tempo questo divario si sta riducendo.
7. I microcontrollori vengono forniti dal produttore in forma non programmata. Per programmare fisicamente il "firmware", è necessario un dispositivo speciale: un programmatore. L'eccezione sono i microcontrollori che hanno un bootloader integrato. Il bootloader è un piccolo programma integrato che consente di programmare i microcontrollori utilizzando una delle popolari interfacce USB, UART, CAN, ecc.

Consideriamo le opzioni per programmare i microcontrollori senza bootloader integrato.

• Molte schede popolari (come LaunchPad e Nucleo) hanno programmatori integrati. Ciò consente di collegarli ad un PC tramite USB ed eseguire la programmazione.
• Per le schede che non dispongono di un programmatore integrato, è necessario utilizzare la Programmazione In-System (ISP). Ciò richiede un programmatore esterno. Tipicamente, il programmatore è collegato a un PC tramite porta USB o COM e a un microcontrollore tramite un'interfaccia di programmazione speciale (SWIM, JTAG, SPI, UART, ecc.). Gli esempi includono il programmatore ST-LINK/V2-1 per microcontrollori STM32/STM8 della STMicroelectronics, programmatori Atmel per microcontrollori AVR, programmatori Microchip per microcontrollori della famiglia PIC.

Riso. 2. STM32 Nucleo è un ottimo esempio di piattaforma aperta. Le schede Nucleo sono dotate di un debugger ST-LINK/V2-1 integrato (delineato in rosso)

1. Debugger. Un debugger è un insieme di strumenti che consente ai programmatori di monitorare l'esecuzione del programma e identificare errori nel codice. Il debugger è composto da tre parti principali: la parte software, eseguita nell'IDE, la parte hardware, implementata nel microcontrollore, e la parte hardware, implementata in un dispositivo speciale, chiamato anche debugger. Vale la pena notare qui che per tutti i microcontrollori moderni, il programmatore e il debugger rappresentano lo stesso dispositivo. Pertanto, ad esempio, per la programmazione e il debug di STM32/STM8, sarà sufficiente il programmatore/debugger ST-LINK/V2-1.

Diamo un'occhiata ad alcuni elementi chiave e strumenti utilizzati durante il debug dei sistemi embedded:

• GDB o GNU Debugger sono debugger software popolari utilizzati per funzionare con vari linguaggi di programmazione. Molti di essi supportano la "modalità remota", che ti consente di controllare il dispositivo di cui stai eseguendo il debug utilizzando un'applicazione in esecuzione su un PC.
• JTAG è un'interfaccia originariamente sviluppata per testare i sistemi embedded, ma in seguito è diventata "de facto" uno standard del settore. Attualmente JTAG è ampiamente utilizzato, anche nelle piattaforme aperte.
• I punti di interruzione vengono utilizzati per interrompere l'esecuzione del programma nei punti appropriati. Questa funzione è necessaria per un esame dettagliato del contesto, ad esempio lo stato delle porte I/O, il contenuto dei registri, ecc. Un'altra caratteristica utile dei debugger è la capacità di eseguire il debug di un programma passo dopo passo.
• Open OCD (Open On-Chip Debugger) è un pacchetto open source che fornisce debug su chip, programmazione in-circuit e test per un'enorme varietà di piattaforme, rendendo Open OCD attraente per molti produttori di chip. Open OCD supporta molti debugger, incluso JTAG.

1. Strumenti per il tracciamento dei bug e il controllo della versione

• Avere uno strumento di tracciamento dei bug è un must per le piattaforme aperte, indipendentemente dal numero di sviluppatori e utenti. Sono disponibili molti strumenti di tracciamento dei bug. Ad esempio, Bugzilla o Mantis BT possono essere scaricati e installati sui server gratuitamente, ma esistono anche servizi che possono fornire hosting a un costo simbolico.
• I sistemi di controllo della versione sono un altro strumento fondamentale per le piattaforme aperte, soprattutto perché le piattaforme aperte coinvolgono molti utenti e sviluppatori che lavorano insieme. Strumenti come Git e Subversion sono popolari sistemi di controllo delle versioni e dei contenuti. Servizi simili a GitHub forniscono hosting del contenuto del progetto, tracciamento dei bug e revisioni collaborative del codice.

Le piattaforme hardware aperte aiutano a semplificare il processo di sviluppo e a ridurne significativamente i costi. Allo stesso tempo, la piattaforma deve disporre di strumenti di sviluppo e debug affidabili ed economici, altrimenti difficilmente susciterà interesse tra gli utenti.

Invece di una conclusione, un'altra riflessione dopo

Molto spesso gli sviluppatori si limitano a diventare specialisti di un singolo processore o microcontrollore. Naturalmente, uno studio approfondito di tutti i registri e le caratteristiche del core del processore è un grande vantaggio per un particolare progetto. Tuttavia, vale la pena notare che la tecnologia non si ferma e la capacità di adattarsi rapidamente a diverse piattaforme è un'abilità molto più preziosa che conoscere tutte le complessità di un'unica soluzione. I progetti open source semplificano notevolmente questo tipo di apprendimento su larga scala riducendo costi e tempi. Prova a fare esperienza con Arduino, metti le mani sui microcontrollori PIC, lavora con un programmatore esterno! Questo processo di autoeducazione può anche aiutare gli studenti inesperti a trovare lavoro, ad esempio, se “si presentano” su qualche forum. Padroneggiare diverse soluzioni e architetture affinerà le tue capacità di autoapprendimento, che sarà la chiave per una carriera lunga e di successo.

Preparazione preliminare

- Si prega tutti di osservare l'allacciamento delle cinture di sicurezza e l'accensione dei segnali di divieto di fumo. Siediti e goditi il ​​viaggio.

Quindi, in ordine.
I test vengono eseguiti in tutte le fasi della vita dell’apparecchiatura. I test possono essere iniziali (bringup), componenti, funzionali, di carico, di produzione e persino test sui clienti.

Anche nella fase di sviluppo dell'attrezzatura, l'ingegnere pensa a come far rivivere la sua idea. Le schede sono cosparse di punti di test, connettori di debug, ponticelli, sedi per componenti di ricambio e simili. L'insieme delle funzionalità di test integrate nell'apparecchiatura è chiamato DFT (Design for Testability). Una scheda rilasciata nella fase DFT può contenere il doppio dei componenti di una scheda rilasciata in produzione. Naturalmente, seguendo il principio "funziona - non toccarlo", nessuno lo rifa e l'utente finale guarda con stupore i posti vuoti sulla scheda madre del negozio, inventando varie teorie cospirative sul loro scopo.

Quindi, abbiamo preso la nostra tavola dalla fabbrica: cosa fare dopo? Beh, certo: collegalo a una presa e lascia uscire tutto il fumo bianco.

- Tutti cadono la prima volta.

Foto da Internet, non avevamo circuiti stampati bruciati, ma lo confesso, a volte è così che si fa. Nella mia memoria, c'è una vecchia storia in cui un curioso architetto di sistema si sedette e scelse a caso a quali connettori collegare fase, neutro e terra (beh, non ebbe il tempo di guardare lo schema), e uno sviluppatore si sedette accanto a lui e catturò quello pallido.

Ma di solito le cose vanno diversamente. La prima fase del test è il Bringup (popolarmente “rianimare”).

Nascita del risveglio

- Svegliati, Neo...

Per il riepilogo, vengono solitamente realizzati 3-5 campioni (con l'aspettativa che almeno due vengano distrutti nel delirio del debugging). Se il dispositivo contiene chip costosi, questi non verranno installati su uno dei campioni. Fab potrebbe offrirti di risparmiare sull'oro - NON ACCETTARE IN NESSUN CASO (beh, dovrai solo saldare molto e spesso).

Una tavola senza chip è la prima candidata alla macellazione. Controlla la sequenza di accensione, i ripristini, i valori di tensione e simili. Quindi un tale comitato funge da donatore di organi e/o da banco di prova per testare tutti i tipi di ipotesi. Inoltre, prima di abilitare qualsiasi cosa, devi:

• suonare l'alimentazione di terra, spesso c'è un cortocircuito lì;
• ispezionare visivamente la scheda: la polarità dei condensatori può essere facilmente invertita, i chip sono capovolti, ci sono trucioli, puoi facilmente trovare componenti passivi che sono stati strappati;
• studia separatamente se hanno installato sulla tua scheda componenti che hai chiesto di non installare (trucco: non creare una maschera nera sui primi campioni - non è visibile se i resistori del chip sono installati o meno su di essa).

Abbiamo giocato abbastanza con la prima vittima: andiamo a soffiare il fumo dal tabellone di battaglia. In questo caso, è necessario fare scorta di un pilota con pulsante di interruzione dell'alimentazione e di una termocamera. Il pilota deve essere messo sotto i suoi piedi, nel caso in cui 220 V colpisca le sue mani (o le sue mani siano semplicemente occupate), e il cortocircuito può essere visto nella termocamera.

Ma in generale, quando lo accendi per la prima volta, di solito non devi aver paura: molto probabilmente non si accenderà, dato che probabilmente hai dimenticato di risaldare i componenti le cui gambe sono confuse il design:

E saldare qualche altro filo:

L’adesivo hot melt è il nostro tutto, il migliore amico dello sviluppatore, quasi come il nastro adesivo nella vita di tutti i giorni.
Subito dopo Dremel:

E il martello che deve essere utilizzato per inserire i bulloni nella tavola non sempre esce in modo ordinato.

A volte il paziente deve sottoporsi a una radiografia o a una tomografia. Sembra questo:

Si scopre che la scansione della pellicola non è molto semplice. Abbiamo scattato la foto con il cellulare davanti alla finestra.

Non puoi vedere nulla in questa foto particolare: non guardare da vicino. Ma in generale, su una radiografia puoi vedere perdite, crepe e simili.

Vale la pena menzionare separatamente l'introduzione delle schede madri, perché viene eseguita in modo diverso. I campioni DFT di madri vengono solitamente ordinati in grandi quantità: circa 20 pezzi. È costoso, quindi c'è una strategia qui.

Gli sviluppatori vengono presi e inviati alla fabbrica. Vengono assemblate circa 5 tavole e il trasportatore si ferma. Successivamente, gli sviluppatori hanno circa 30 minuti per accendere la scheda (per i sistemi x86, il criterio di successo è il caricamento del BIOS). Se tutti sono fortunati, vengono raccolti i campioni rimanenti. In caso contrario, la produzione verrà annullata e gli sviluppatori torneranno a casa a pensare. I soldi spesi per il PCB vanno persi, ma i componenti aspettano in magazzino per il prossimo tentativo.

Ok, abbiamo lanciato la nostra bacheca e ne abbiamo anche lanciate altre che dovrebbero funzionare con essa. Qual è il prossimo? Stiamo allestendo uno stand.
E qui probabilmente ti aspetti di vedere questo?

Tutto questo è solo una vetrina per i viceministri. Un vero supporto dovrebbe essere assemblato con bastoncini e ghiande e assomiglia a questo:

- Non ho detto che sarebbe stato facile, Neo, ho solo detto che sarebbe stata la verità.
(un bicchiere per contrappeso, un pennarello - in modo che il radiatore sia ben saldo - è legato lì con un filo)

La seguente orda si sta accalcando nel laboratorio:

E tutti iniziano a correre per eseguire il flashing del firmware, dei programmi e frugare ovunque con un oscilloscopio.
A volte durante il processo si sente di tanto in tanto una richiesta cortese: "Caro collega, per favore toglimi il saldatore dalla mano, fa troppo caldo" o "Per favore, non accendere più l'alimentazione mentre sto avvitando la scheda al telaio."

Nel nostro caso particolare, lo scopo principale del controllo della collaborazione di più dispositivi è scoprire se PCI Express funziona e se è conforme allo standard. È solo che praticamente puoi vivere senza tutto il resto. Di solito la funzionalità inclusa nell'hardware è ridondante. Tonnellate di pin GPIO, bus I2C/SPI, sensori termici, ghiacci e altre cose, di regola, rimangono non reclamate, poiché il loro debugging viene posticipato all'ultimo momento, che non arriva mai.

Naturalmente, non disponiamo di strumenti di misurazione per ogni occasione della vita che costano diversi milioni di rubli: questo è per i deboli. Il software di test dei produttori di componenti ha fretta di aiutarci. Quasi tutti i chip moderni con interfacce ad alta velocità hanno al loro interno un oscilloscopio digitale. Viene fornito con un software specializzato che ti consente di leggere le sue letture. Lanciamo e guardiamo i diagrammi a occhio. Vediamo questo:

A volte vediamo uno strabismo pericoloso:

E a volte prendiamo i calamari:

I calamari sono i più pericolosi. Queste sono distorsioni non lineari e gli equalizzatori integrati non sono particolarmente in grado di gestirle. I calamari significano che da qualche parte nel canale di comunicazione c'è qualcosa di molto brutto: un cavo troppo lungo, un calo significativo dell'impedenza, qualche tipo di irregolarità che cade entro 1/4 o 1/2 della lunghezza d'onda di alcune armoniche nella banda utile. , ecc. simili.

Si potrebbe notare che il calamaro si comporta un po' come fa il DFE al segnale ricevuto nell'equalizzatore del ricevitore PCIe. Ma in questo caso si tratta di un calamaro e non del risultato del lavoro del DFE (è solo che il software che utilizziamo non può visualizzare il risultato del lavoro del DFE).

Separatamente va detto il software di test, che può anche essere estremamente insidioso. Ad esempio, per creare diagrammi a occhio, utilizziamo due versioni dello stesso programma: una versione disegna immagini, ma non scrive i valori di apertura dell'occhio, la seconda viceversa.

Ebbene sì, se hai intenzione di sparare agli occhi tramite l'interfaccia I2C, dimenticalo, sarà molto, molto, molto lento. Solo in banda. Il problema è che per rimuovere l'in-band, il tuo dispositivo deve avere un collegamento PCIe funzionante con il computer su cui è in esecuzione il software di test, il che è molto problematico quando l'hardware non è installato in uno slot PCIe standard. E la cosa più divertente è che dovresti già avere almeno una sorta di collegamento funzionante sul canale di cui stai eseguendo il debug, e esattamente nella modalità (gen2/3) di cui hai bisogno (perché in diverse modalità ci sono occhi ed equalizzatori diversi lavorare diversamente). Niente gambe, niente cartoni animati, niente occhi: è così che vuoi, vattene.

In precedenza ho scritto un articolo separato su come uscire da PCIe.

In generale, quando si sviluppa un server, ovviamente, il supporto da parte dei produttori dei componenti utilizzati è molto importante, poiché oggi la complessità anche dei chip relativamente semplici è tale che senza utilizzare i test integrati in essi, è improbabile che lo facciano. essere possibile controllare completamente ed eseguire il debug del sistema. Generatori di clock, regolatori di tensione, controller di rete, switch PCI Express, redriver: tutto questo ha strumenti integrati per la configurazione, la diagnostica e richiede un determinato set di programmi e cavi per la connessione per la configurazione e il test completi, senza il cui utilizzo lo sviluppo diventa semplicemente impossibile.

Durante il processo di ispezione, a volte diventa chiaro che qualcosa non va bene da qualche parte. E poi inizia l'affascinante processo di localizzazione dell'errore in modo che possa essere corretto nella revisione successiva. Ed è positivo se questo "sbagliato" viene ripetuto costantemente, quindi, di regola, scoprire qual è esattamente la causa dell'errore non è difficile. Ma a volte è molto peggio. Ad esempio, su alcune schede, quando si eseguono test per un lungo periodo, si verificano singoli errori irreversibili sul bus (che non dovrebbero esistere affatto). E qui spesso dobbiamo usare il metodo dello "sguardo ravvicinato", cioè semplicemente sederci, guardare ipoteticamente il diagramma, supporre quale potrebbe essere esattamente la ragione, provare a eliminare questa ipotetica ragione nel diagramma e poi verificare con i test se abbiamo indovinato oppure no.

Abbiamo riscontrato qualcosa di simile qualche anno fa, quando i test NVIDIA (sì, molti produttori forniscono serie specifiche di test che consentono di verificare cose che non sono disponibili a livello di programmazione utilizzando utilità standard) hanno fornito rari errori singoli durante esecuzioni lunghe (un giorno o più) su alcune tavole.. Quindi il punto si è rivelato essere un tracciamento infruttuoso del clock di riferimento (100 MHz), anche se prima di arrivare a questo sono state controllate molte cose, dalla qualità della potenza ai diagrammi a occhio per tutte le linee.

E comunque, va bene. Il più grande incubo di uno sviluppatore è quando tutto funziona contemporaneamente. Ciò significa solo una cosa: da qualche parte è sepolta una mina che esploderà dopo che 100.500 unità di attrezzatura saranno state spedite al cliente. Il fatto è che nel processo di ricerca della causa di un problema globale, vengono testate diverse ipotesi e, di regola, vengono identificati molti piccoli difetti che non sono in alcun modo correlati al problema che si è presentato. Non c'è un grosso problema: non ne troverai di piccoli. I tuoi clienti li troveranno per te.

Controllo rispetto all'elenco

- Tutto quello che faccio è quello che mi dice di fare.

Dopo aver completato i test dei componenti, iniziano i test funzionali, verificando la funzionalità del complesso nel suo insieme e il corretto funzionamento di tutte le funzioni integrate. Questo di solito viene fatto dal QA. Naturalmente qui c'è molto spazio per la creatività, ma in generale l'enfasi principale è sul corretto funzionamento del sistema quando si riproducono scenari di utilizzo standard. Qui gli errori rilevati potrebbero già essere sia di natura hardware che software, quindi prima di tutto è importante scoprire cosa ha causato esattamente l'errore. Spesso le prime supposizioni possono essere fuorvianti, ovvero quello che a prima vista sembra un problema hardware potrebbe essere causato da un funzionamento errato del firmware. Una parte significativa dei test funzionali consiste nel verificare come il sistema gestisce i vari errori che possono verificarsi durante il funzionamento. I moderni strumenti di debug consentono di iniettare artificialmente errori nelle interfacce standard del processore, perché a livello hardware, molti di essi sono piuttosto problematici da creare apposta (beh, non strappare i chip di memoria al volo o cortocircuitare il PCI Express linee di autobus).

E... non ho detto che test funzionale non significhi un sistema assemblato e pronto per la battaglia. Anche qui non tutto fila liscio. Ad un certo punto, si è scoperto che non avevamo in magazzino i cavi OcuLink della lunghezza richiesta e il server aveva coraggio.

E per qualche motivo, in questa configurazione, durante il test di carico, tutto ha iniziato a surriscaldarsi. Ci stiamo ancora chiedendo perché. Probabilmente i cavi si stavano surriscaldando.

Riesci a portare due angurie in ciascuna mano?

- Sei più veloce di così. Non pensare di esserlo, sappi che lo sei...

Ad un certo punto, parallelamente ai test funzionali, iniziano i test di carico: è importante assicurarsi che il server continui a funzionare correttamente in condizioni operative estreme. Inoltre, i test di carico vengono eseguiti sia in relazione ai singoli sottosistemi (dischi, memoria, processori, input-output), sia all'intero sistema nel suo insieme. Di norma, i test localizzati consentono di caricare un modulo specifico in modo più pesante di quanto si possa fare con il carico massimo sull'intero sistema.

Inoltre, in questo caso aiutano gli strumenti di debug del produttore della piattaforma hardware (ad esempio, Hardware Tests Executive di IBM). In questo modo è possibile portare il processore in modalità completamente estreme, che sono fondamentalmente irraggiungibili quando si eseguono applicazioni reali. I principali problemi identificati durante il test di carico sono il surriscaldamento, l'instabilità di potenza o il sovraccarico di corrente massimo, errori durante il lavoro attivo con le interfacce I/O.

Anche i benchmark vengono in soccorso. Perché quando i valori di riferimento effettivi differiscono molto da quelli previsti, significa che qualcosa è andato storto. Un buon motivo per colpire la tavola con un bastone.

Nella fase di test utilizziamo principalmente i microbenchmark:
Per i processori, si tratta solitamente di carichi a thread singolo, come spec2006(già adesso speccpu2017), parsec, ma in generale ce ne sono moltissimi dall'assemblaggio del kernel Linux e dalla compressione ( lzma, gzip), prima di moltiplicare le matrici e calcolare la trasformata veloce di Fourier ( fftw).
Nulla è cambiato nella memoria per molti anni: FLUSSO,Velocità RAM SMP, lmbench.

Per i dischi: fio, iozono.

Se tutti i test funzionali e di carico vengono superati con successo, ci sono ancora una serie di cose da verificare: stabilità di funzionamento nell'intero intervallo di temperature, resistenza alle vibrazioni, verifica della compatibilità con un determinato insieme di componenti standard (memoria, dischi, controller PCI Express).

P.S.: Dopo aver controllato tutto durante i test funzionali della prima revisione del server ed essere rimasti soddisfatti, tre server si sono bloccati improvvisamente nel nostro laboratorio. Abbiamo iniziato a controllare l'alimentazione e sulla linea da 1,2 V (alimentazione per il bus del processore PCIe) abbiamo visto questo:

Vorrei attirare la vostra attenzione su una cella da 500 mV. Il valore nominale è 1,2 V. La resistenza è stata errata nel circuito di compensazione di uno dei VRM. Con questo tipo di alimentazione, tutti i test di carico, parametri di riferimento, test di tostatura, ecc. sono stati superati con successo e il progetto è passato felicemente alla seconda revisione.
Quindi, quando la schermata della morte appare all'improvviso sul tuo accogliente computer di casa di un marchio famoso, non dovresti pensare che questo sia necessariamente "un bug in Windows".

Le tecnologie di virtualizzazione sono ora utilizzate in molte aree dell'IT, sia in ambienti di produzione che da appassionati e utenti domestici per una varietà di attività. Diversi sistemi virtuali in esecuzione contemporaneamente su una macchina fisica aumentano significativamente la flessibilità dell'infrastruttura IT e aumentano l'efficienza nell'utilizzo delle risorse hardware. Il test del software è uno dei casi d'uso più comuni per le piattaforme di virtualizzazione. Ciò non sorprende, perché le macchine virtuali hanno molte proprietà utili che riducono significativamente i tempi di sviluppo e test e aumentano l’efficienza di questi processi.

Nel classico modello di sviluppo del software, i programmatori e gli ingegneri della qualità del software dovevano per la maggior parte del tempo testare un prodotto software su una piattaforma per quasi tutto il periodo di sviluppo, e solo alla fine testarlo in diversi sistemi operativi e ambienti utente (il così- chiamato test di configurazione). Inoltre, i dipendenti dei reparti di test e gli sviluppatori non avevano a disposizione molti computer fisici e su una macchina, in un sistema operativo, è impossibile, ad esempio, installare contemporaneamente più versioni dello stesso prodotto software con cui il programma in fase di sviluppo deve interagire. Di conseguenza, il software, soprattutto quello dei piccoli team di sviluppo, spesso riscontrava errori legati alle peculiarità delle configurazioni utente, poiché non c'erano abbastanza tempo e risorse per testare la configurazione completa. Inoltre, gli ingegneri della qualità dovevano dedicare molto tempo alla distribuzione di una serie di prodotti software sui banchi di prova e all'impostazione del proprio lavoro nell'infrastruttura di rete.

Naturalmente, uno dei problemi più seri nello sviluppo del software è il fatto che nelle prime fasi di sviluppo, l'assemblaggio di un prodotto software durante il suo funzionamento può causare danni irreparabili al sistema (ad esempio, vari driver di dispositivo). Pertanto, è necessario pianificare il ripristino dei sistemi operativi e delle relative impostazioni dopo i guasti dalle copie di backup e dedicare molto tempo al loro ripristino.

Va notato che esiste un altro problema che si verifica abbastanza spesso nello sviluppo del software e richiede una notevole quantità di tempo per risolverlo. Tutti i programmatori che hanno esperienza nell'interazione con i team di test conoscono la seguente situazione: in un sistema di tracciamento dei bug, un tester registra un difetto che il programmatore non può riprodurre. Dopo che il programmatore ha impostato lo stato del problema come risolto, il tester lo chiama sulla sua macchina e gli mostra chiaramente l'errore. In questa situazione, si arriva al punto che il programmatore deve installare sulla macchina del tester molti debugger e altre sciocchezze di cui il tester non ha bisogno e "catturare" il difetto, interrompendo completamente il lavoro del tester. Se a questo aggiungiamo il tempo impiegato dal tester per rimuovere le utilità di programmazione, il risultato è una grave perdita di tempo del team.

Inoltre, le caratteristiche operative di alcuni prodotti software richiedono il test del loro funzionamento in determinate condizioni (varie quantità di RAM, larghezza di banda del canale di comunicazione, frequenza del processore, ecc.). In questo caso, il team di test potrebbe non avere a disposizione la configurazione hardware necessaria (e se avessimo bisogno di dieci dischi rigidi?). Quando si determinano i requisiti di sistema di un prodotto per tali fattori, questa esigenza potrebbe rivelarsi fondamentale.

Per concludere l'elenco dei problemi che sorgono durante il processo di sviluppo e test, dobbiamo aggiungerne uno in più. Spesso si verifica una situazione in cui è necessario controllare l'assemblaggio di un prodotto software “per fumo” (il cosiddetto smoke testing, Smoke Testing), il che significa una rapida esecuzione dei test più importanti. Ma cosa succede se stiamo sviluppando un'applicazione che richiede diverse versioni di Internet Explorer? In questo caso, verrà impiegato molto tempo per caricare un sistema adatto su cui è installata la versione richiesta.

Riassumendo le situazioni descritte, riassumiamo i problemi che spesso si riscontrano nel processo di sviluppo e test di prodotti software:

• la necessità di testare il software in un numero di configurazioni utente maggiore di quelle disponibili per testare i computer fisici
• costi elevati in termini di tempo per l'implementazione e la configurazione di banchi di prova contenenti molti componenti diversi tra i quali è garantita l'interazione di rete
• costi elevati in termini di tempo per la creazione di copie di backup dei sistemi e delle relative configurazioni, nonché per il ripristino dopo un guasto dovuto al funzionamento instabile dei gruppi di prodotti software
• impossibilità di riprodurre un difetto riscontrato da un tester sulla macchina di uno sviluppatore e perdita di tempo per cercarlo e risolverlo
• la necessità di testare il programma in un ambiente hardware che il team di test non ha a disposizione
• la necessità di testare un prodotto software in condizioni che richiedono un rapido passaggio tra le configurazioni utente

Se si calcola quanto tempo e risorse vengono spesi per risolvere questi problemi, si ottiene una cifra molto, molto impressionante, che, espressa in termini monetari, costituisce una parte abbastanza importante del budget del progetto.

Le tecnologie di virtualizzazione, correttamente applicate nel processo di sviluppo e test, possono ridurre significativamente i costi di manodopera e aumentare significativamente l'efficienza del processo, il che avrà un impatto positivo sulla qualità del prodotto software rilasciato. Ecco come la virtualizzazione ti consente di farlo:

• i tester, lavorando con macchine virtuali, possono creare un numero illimitato di configurazioni utente sulla propria macchina fisica, lanciando, se necessario, quella più adatta al momento
• una volta create, le configurazioni multi-macchina possono essere configurate utilizzando gli strumenti della piattaforma di virtualizzazione e semplicemente trasferite su altre apparecchiature, senza necessità di riconfigurazione
• è possibile creare un backup della macchina virtuale copiando una cartella o creando uno snapshot
• Dopo che un tester trova un errore, una macchina virtuale con un difetto ricorrente può essere trasferita allo sviluppatore, liberando così risorse per ulteriori test
• le condizioni necessarie per il test possono essere create rapidamente attraverso la configurazione flessibile dei parametri dell'ambiente hardware della macchina virtuale (la quantità di RAM, il numero di processori virtuali, limitazioni delle risorse)
• la possibilità di ripristinare rapidamente uno stato salvato di una macchina virtuale con la configurazione richiesta o di passare tra diversi sistemi guest in esecuzione contemporaneamente riduce i tempi di test

Tutte le soluzioni di cui sopra devono essere considerate alla luce del fatto che una macchina virtuale con software installato al suo interno è un oggetto molto flessibile che può essere rapidamente distribuito sulle macchine client da un repository centralizzato di modelli di configurazione utente e può essere configurato con il massimo flessibilità in termini di parametri dell'ospite, del sistema e del suo ambiente. La facile portabilità su altre apparecchiature e l'indipendenza dalla piattaforma hardware sono i principali vantaggi delle macchine virtuali.

Macchine utensili virtuali per test e sviluppo

Quando si implementa un'infrastruttura virtuale ai fini dello sviluppo e del test del software, è necessario, innanzitutto, selezionare la piattaforma di virtualizzazione più adatta, affidabile ed efficiente che soddisfi tutti i requisiti per il processo di sviluppo nell'organizzazione. Esistono due modi più comuni per utilizzare le macchine virtuali per testare i prodotti software:

• Distribuzione non gestita di macchine virtuali su macchine client o server di test, in cui i tester stessi creano le configurazioni di cui hanno bisogno o copiano modelli di sistema virtuale sui propri computer da una libreria centrale di modelli virtuali (file server). Il vantaggio di questo approccio è che la soluzione è economica; puoi utilizzare uno dei tanti sistemi di virtualizzazione gratuiti (VMware Server, Virtual PC, VirtualBox e altri). Gli svantaggi principali sono che l’implementazione spontanea delle macchine virtuali crea conflitti nell’infrastruttura di rete, mancanza di controllo sull’uso delle licenze per sistemi operativi e software applicativi e l’impossibilità di integrazione nell’ambiente IT esistente dell’organizzazione.
• Distribuzione gestita di sistemi virtuali da librerie centralizzate di modelli virtuali, con il pieno controllo sull'utilizzo delle macchine virtuali all'interno dell'infrastruttura IT dell'azienda. I vantaggi di questo approccio includono la capacità di risolvere i conflitti tra sistemi virtuali e fisici sulla rete, controllare l'uso delle licenze, la capacità di monitorare l'uso dell'infrastruttura virtuale e creare uno spazio comune tra i vari partecipanti al processo di sviluppo e test, integrazione nella reale infrastruttura IT dell’impresa. Lo svantaggio principale di questo approccio è l’alto costo delle soluzioni. Esempi di prodotti che forniscono la distribuzione gestita di macchine virtuali: VMware LabManager, VMLogix LabManager, Microsoft System Center Virtual Machine Manager.

Le piattaforme di virtualizzazione, oggi presenti in gran numero sul mercato, si stanno sviluppando rapidamente e forniscono agli utenti una gamma sempre crescente di strumenti per aumentare l'efficienza del processo di sviluppo e test. Per risolvere ciascuno di questi problemi, le piattaforme di virtualizzazione di vari fornitori dispongono di propri strumenti che consentono agli utenti di testare in modo efficace i prodotti software nelle macchine virtuali.

1. Creazione di molte configurazioni personalizzate.

   Se è presente una grande quantità di spazio libero su disco sulla macchina del tester, utilizzando la piattaforma di virtualizzazione è possibile creare un numero illimitato di sistemi virtuali, ognuno dei quali può essere caricato su richiesta, senza interrompere il lavoro del lavoratore sul sistema host. Le macchine virtuali possono essere utilizzate anche su server di test specializzati basati sulle piattaforme VMware ESX Server, XenEnterprise o Virtual Iron. In questo caso, è possibile assegnare determinati diritti agli utenti dei sistemi virtuali e le risorse fisiche del server che possono essere utilizzate da un utente specifico sono limitate. Un file server con modelli virtuali può archiviare macchine virtuali preinstallate distribuite su server o workstation di test. In questo caso, è necessario tenere conto delle specifiche dell'utilizzo delle macchine virtuali in conformità con la licenza. Nella maggior parte dei casi, ciascuna macchina virtuale richiede una licenza separata, ma esistono delle eccezioni: ad esempio, una licenza Windows Server 2003 Datacenter Edition consente di eseguire un numero illimitato di istanze virtuali del sistema operativo.

   Se l'ambiente di test configurato è già distribuito su una macchina fisica, può essere migrato su una macchina virtuale utilizzando prodotti di fornitori di piattaforme di virtualizzazione e sviluppatori di terze parti. Tali soluzioni includono i prodotti PlateSpin PowerConvert, VMware Converter e Microsoft Migration Toolkit.

2. Creazione di configurazioni multi-macchina su un server fisico.

   Le piattaforme di virtualizzazione focalizzate sul test del software (VMware Workstation, Virtual PC, VirtualBox, Xen) consentono di creare intere infrastrutture virtuali con vari tipi di interazione di rete all'interno di un host fisico. Ad esempio, puoi creare diversi "blocchi" di server virtuali (server database, server applicazioni, ambiente client), configurare adattatori di rete per macchine virtuali (una macchina può averne diversi, in VMware Workstation - fino a dieci) e avviare un gruppo di server di prova. Allo stesso tempo, le piattaforme di virtualizzazione consentono di connettere adattatori di rete di macchine virtuali a diversi segmenti della rete virtuale.
   

   Dopo aver creato l'infrastruttura virtuale di test, è possibile configurare i parametri dei canali di comunicazione tra le macchine virtuali.
   

   Va notato che le reti virtuali non sono portatili su tutte le piattaforme di virtualizzazione e talvolta devono essere riconfigurate quando si spostano le macchine virtuali su altre apparecchiature.

3. Eseguire il backup delle macchine virtuali durante i test.

   Se i tester utilizzano macchine virtuali sulle proprie workstation, possono eseguirne il backup copiando la cartella dei file della macchina virtuale. In caso di arresto anomalo del sistema, non è necessario ripristinare la copia salvata: è già completamente pronta per l'uso. Inoltre, molte piattaforme di virtualizzazione consentono di creare più snapshot di una macchina virtuale, ognuno dei quali può essere ripristinato in pochi minuti.

   Se il test viene eseguito su server di test dedicati, è possibile utilizzare soluzioni specializzate dei fornitori di piattaforme di virtualizzazione, come vRanger Pro di Vizioncore, VMware Consolidated Backup (VCB) o la soluzione Microsoft Data Protection Manager per Virtual Server 2005 non ancora rilasciata, per creare copie di backup delle macchine virtuali R2, che consentono di creare copie di backup delle macchine virtuali senza fermarle.

4. Dimostrazione dei difetti agli sviluppatori.

   Se viene riscontrato un difetto, il tester può semplicemente salvare in un'istantanea lo stato del sistema in cui appare l'errore e continuare a testare il sistema. Se è necessario dimostrare un difetto, la macchina virtuale può essere trasferita a uno sviluppatore che può lavorarci senza timore di danneggiare l’ambiente del tester. Inoltre, sulla piattaforma VMware Workstation, le macchine virtuali possono fungere da server VNC senza la necessità di installare software aggiuntivo per l'accesso al desktop remoto.
   

5. Configurazione flessibile dell'ambiente hardware.

   Spesso, il test del software richiede una maggiore flessibilità nella configurazione dei componenti hardware. Ad esempio, lo stress test richiede di verificare il funzionamento di un prodotto software in condizioni estreme o limitate (mancanza di spazio su disco, errore di connessione di rete). In questo caso, utilizzando la piattaforma di virtualizzazione, è possibile aggiungere nuovi dispositivi virtuali alla macchina virtuale o limitare le risorse ad essa assegnate.

   Inoltre, se aggiungiamo un disco virtuale nel sistema ospite, possiamo crearlo come espandibile dinamicamente, cosa che ci permette di risparmiare spazio libero su disco, e anche creare i cosiddetti dischi Undo, le cui modifiche diventano effettive solo mentre si lavora con il disco virtuale macchina e può essere annullato, il che è molto comodo per i test.
   

   In termini di controllo delle risorse, molte piattaforme di virtualizzazione consentono di limitare le risorse di una macchina virtuale o di un pool di risorse della macchina virtuale, consentendo di simulare ambienti utente reali.

   Le moderne piattaforme di virtualizzazione supportano lo standard USB 2.0, un gran numero di adattatori di rete virtuali in una macchina virtuale, l'emulazione di dischi SCSI, nonché la rappresentazione di un diverso numero di processori nel sistema ospite tramite SMP virtuale (Symmetric Multi Processing).

6. Lavora con diversi sistemi virtuali contemporaneamente.

   Questa funzionalità consente ai tester non solo di utilizzare istanze di diversi sistemi guest durante i test, ma anche di scambiare facilmente file sia tra il sistema operativo host e guest, sia tra i sistemi operativi guest utilizzando il meccanismo Drag&Drop. Allo stesso tempo, alcune piattaforme di virtualizzazione consentono un semplice scambio di file tramite cartelle condivise sul sistema host (Cartelle condivise) o “trascina e rilascia” file tra sistemi guest (VMware Workstation).

   Molte piattaforme di virtualizzazione consentono di utilizzare appunti condivisi con il sistema host, il che semplifica notevolmente, in particolare, la copia dei messaggi di errore del programma in un sistema di tracciamento dei bug.

Strumenti di sviluppo e test per distribuzioni non gestite

La base per l'implementazione gestita delle macchine virtuali sono soluzioni specializzate per la creazione e la manutenzione di laboratori virtuali di test (Virtual Labs), all'interno dei quali viene esercitato il controllo sull'uso dei sistemi virtuali da parte di diversi gruppi di utenti, l'implementazione automatizzata delle macchine virtuali sui computer del progetto partecipanti e la creazione di un ambiente di lavoro comune. Queste soluzioni sono piuttosto costose (ad esempio, l'infrastruttura VMware LabManager costerà almeno 15.000 dollari), ma sono giustificate su un utilizzo su larga scala. Grandi aziende come Dell fanno ampio uso di macchine virtuali all'interno di laboratori virtuali per testare i prodotti software. Tali sistemi utilizzano reti di storage SAN, in cui i modelli di macchine virtuali si trovano in una libreria comune di modelli virtuali, che vengono distribuiti su richiesta su server di test gratuiti basati su piattaforme di virtualizzazione. L’utilizzo dei laboratori virtuali offre i seguenti vantaggi:

• Lavorando con configurazioni multi-macchina come un singolo modulo, la possibilità di pubblicare questi moduli
• Riduzione del tempo impiegato nella configurazione dei sistemi
• Accesso separato alle macchine virtuali e dimostrazione dei difetti trasmettendo collegamenti alla situazione problematica salvata come istantanea del sistema ospite
• Libreria comune di modelli con la capacità di risolvere i conflitti di rete durante la distribuzione (SID, assegnazione di indirizzi MAC univoci alle interfacce di rete virtuale)
• Manutenzione centralizzata e distribuzione degli aggiornamenti negli ambienti di test
• Monitoraggio del carico del server di prova

Attualmente, le soluzioni più popolari per l'implementazione gestita dell'infrastruttura di test virtuale sono VMware LabManager (per la piattaforma ESX Server) e VMLogix LabManager (per le piattaforme Microsoft, VMware e XenSource).

Laboratori di prova VMware LabManager

VMware offre alle grandi aziende una soluzione di infrastruttura di test virtuale (precedentemente sviluppata dalla società acquisita Akimbi) che distribuisce rapidamente macchine virtuali su server di test e controlla l'uso dei sistemi virtuali, mentre il processo sembra che l'utente stia lavorando su un computer fisico. Di seguito viene presentato il modello operativo del laboratorio virtuale:

Oltre a tutti i vantaggi elencati dei sistemi di gestione dei laboratori virtuali, VMware LabManager fornisce l'integrazione con gli strumenti di test più diffusi e ha la capacità di distribuire modelli con pochi clic del mouse, supporta il protocollo LDAP, si integra facilmente con altre soluzioni di infrastruttura virtuale VMware e ha la capacità di automatizzare le operazioni utilizzando la propria API (Application Program Interface). Lo svantaggio principale di questo prodotto è la capacità di servire server virtuali solo su piattaforme VMware.

Laboratori di prova VMLogix LabManager

A differenza della soluzione VMware, il prodotto supporta piattaforme di virtualizzazione di vari fornitori. Le piattaforme Microsoft (Virtual Server), Xen (XenEnterprise) e VMware (ESX Server e Server) possono essere utilizzate come base per un laboratorio di test virtuale. Inoltre, LabManager di VMLogix supporta la manutenzione dei server fisici di un'organizzazione. Di seguito viene presentata l'architettura della soluzione VMLogix LabManager:

LabManager fornisce un portale self-service che consente agli utenti di distribuire macchine virtuali da una libreria centralizzata di modelli di sistema operativo e immagini ISO, oltre a funzionalità di gestione delle licenze, configurazione della zona di indirizzi IP e funzionalità di controllo della sicurezza dell'infrastruttura di test virtuale. Inoltre, VMLogix LabManager include anche funzionalità di automazione tramite un'API, funzionalità per l'implementazione e il mantenimento di configurazioni multi-macchina e funzionalità per dimostrare situazioni problematiche condividendo snapshot di macchine virtuali.

Conclusione

Il modello per organizzare il processo di sviluppo e test utilizzando macchine virtuali può ridurre significativamente i costi di distribuzione degli ambienti utente di test e di configurazione degli ambienti di test. Secondo le statistiche, quando si testano prodotti software su server e workstation fisici, queste attività richiedono fino al 50% del tempo del team di test. Le macchine virtuali su piattaforme di diversi fornitori possono ridurre notevolmente questo tempo, fino al 5% dei costi totali di test. La maggiore flessibilità dei sistemi virtuali e la loro indipendenza dall’hardware consentono di lavorare con essi come con alcuni blocchi da cui è costruita l’infrastruttura di test virtuale dell’azienda. La capacità di fornire accesso condiviso ai difetti rilevati ai membri del team di sviluppo e agli utenti del prodotto può accelerare notevolmente la ricerca e la correzione degli errori. In molte aziende, i test tramite macchine virtuali sono già diventati uno standard de facto.

Tuttavia, il processo di test sui sistemi virtuali presenta alcune limitazioni: ad esempio, i sistemi virtuali non sono consigliati per testare le prestazioni, così come per testare applicazioni che richiedono elevate risorse fisiche del computer. Per altri tipi di test, un'infrastruttura di test virtuale è una delle migliori soluzioni per aumentare l'efficienza del processo di sviluppo, oltre a semplificare l'interazione tra i membri del team.

Piattaforme hardware

Compatibilità della piattaforma hardware significa che i computer sono costituiti da componenti e dispositivi che hanno lo stesso sistema di comando e codifica dei dati e quindi possono essere intercambiabili. Sebbene ciò non sia necessario, se i dispositivi differiscono notevolmente nelle caratteristiche tecniche, non è possibile sostituirli con un altro. Ma per diverse piattaforme hardware, tutti i componenti sono completamente diversi e incompatibili.

Ora sono rimaste solo due piattaforme hardware competitive per i PC: PC IBM E AppleMacintosh(Figura 3) Inoltre, IBMPC domina chiaramente, oltre il 90% dei computer appartiene a questa piattaforma. Un tempo, gli Apple Macintosh erano più adatti per lavorare con la grafica e l'editoria, ma ora le capacità di entrambe le piattaforme sono uguali. Tuttavia,

I computer Apple non stanno scomparendo, ma vengono ancora utilizzati.
Per i server ad alte prestazioni, o viceversa - chip primitivi, esistono altre piattaforme hardware: SunMicrosystems, Compaq, HewlettPackard, ecc.

Svolge un ruolo importante nella configurazione hardware del computer principio dell’architettura aperta. Questa è la costruzione di un computer su base modulare, quando tutti i dispositivi informatici dello stesso tipo hanno:

1. protocolli (standard) concordati di comune accordo per la trasmissione dei dati;

2. dimensioni geometriche standard e connettori unificati per il collegamento.

L'architettura aperta te lo consente Aggiornamento(Aggiornamento), cioè aggiornare il tuo computer semplicemente sostituendo alcuni dispositivi con altri senza influenzare tutto il resto.

Invece di un dispositivo obsoleto, ne installano uno nuovo con parametri migliori e lo collegano allo stesso connettore. Il sistema operativo registra il nuovo dispositivo e determina i migliori driver per esso. Se non si trovano all'interno del sistema operativo, i driver necessari vengono presi da un supporto esterno o da Internet. Successivamente, il computer inizia a funzionare con parametri molte volte migliori. Procedura semplice ed efficace.

La sostituzione di alcuni dispositivi hardware con altri con caratteristiche migliori viene effettuata in una certa misura in tutti i dispositivi tecnici, ma da nessuna parte raggiunge una tale scala come nella tecnologia informatica. Ad esempio, è difficile immaginare un'auto in cui sono installati nuovi componenti del motore e della trasmissione al posto di quelli obsoleti, a seguito dei quali la potenza dell'auto aumenta più volte.

L'aggiornamento ha i suoi limiti e non è possibile installare tutte le novità su un computer molto vecchio. Di tanto in tanto compaiono standard di connessione fondamentalmente nuovi, i vecchi bus di sistema non vengono più prodotti e cambiano gli standard dei dispositivi di base, come ad esempio la scheda madre. E poi la modernizzazione diventa inutile: è più facile acquistare un nuovo computer.

La piattaforma IBMPC ha un'architettura aperta, mentre la piattaforma Apple ha un'architettura chiusa.

L'architettura aperta ¾ è esattamente ciò che ha permesso alla piattaforma IBM di assumere una posizione di leadership nella produzione di computer e sconfiggere la concorrenza. E ora i computer sulla piattaforma IBM sono dominanti nel mondo.

Tuttavia, la stessa IBM, avendo introdotto l'architettura aperta dei suoi prodotti, ha risolto con successo problemi tattici, ma ha perso strategicamente. Centinaia di aziende in tutto il mondo hanno iniziato a realizzare dispositivi con un'architettura aperta per i computer IBM: in America, Europa e Asia. Non ci sono divieti legali in merito. E l'architettura del bus tecnicamente aperta rende tutto ciò abbastanza semplice.

Di conseguenza, IBM ha cessato di essere l'unico leader nella produzione di apparecchiature informatiche. È diventata solo una delle grandi aziende, uno dei primi cinque produttori.

IntroduzioneDopo aver stabilito le funzionalità 3DMAX delle moderne schede video, è tempo di eseguire gli stessi test per confrontare le moderne piattaforme hardware a processore singolo.
Al momento, sul mercato di massa, ci sono solo due famiglie di processori che possono essere considerate "promettenti": le piattaforme Socket478 e Socket462 (SocketA). Non prenderò in considerazione le piattaforme "obsolete" basate su processori per socket Socket370 e Socket423, poiché non ha senso acquistare sistemi a processore singolo su questi processori per lavorare in 3DMAX.
Naturalmente, i sistemi già acquistati basati su entrambi i processori per il socket Socket370 sul core Tualatin e una cache di secondo livello di 512Kb, nonché i sistemi basati su processori più vecchi per il socket Socket423, consentono di lavorare in modo produttivo in 3DMAX. Tuttavia, il costo di questi sistemi "legacy" oggi li rende poco redditizi da acquistare, poiché i sistemi basati su questi processori non presentano vantaggi in termini di prestazioni o sono addirittura inferiori ai sistemi basati sui processori delle famiglie Socket478 e Socket462 allo stesso prezzo. Questa è una conseguenza della politica di Intel di sostituire le linee di processori "obsolete" con nuove "promettenti", che si manifesta in un aggiornamento più rapido delle linee di processori "promettenti" e, di conseguenza, in una riduzione più rapida dei prezzi per i processori di questi "promettenti" " linee.
I chipset più produttivi per i processori Socket478 e Socket462, le cui schede sono ampiamente disponibili oggi, sono i850 e Apollo KT266A. Oggi non ha senso costruire piattaforme su schede con il chipset i845D che supportano la memoria DDR SDRAM PC2100, poiché la memoria RDRAM PC800 attualmente costa lo stesso o addirittura più economico della SDRAM DDR PC2100, fornendo allo stesso tempo prestazioni notevolmente più elevate.

Quindi, in questo articolo esamineremo le prestazioni di un sistema basato su una scheda con chipset i850 (Abit TH7II) e processori Pentium4 - 2,2 GHz, 2,0 GHz con cache di secondo livello da 512 KB (core Northwood) e processori Pentium4 - 2,0 GHz, 1,7 GHz con cache di secondo livello da 256 Kb (core Willamette). Innanzitutto è interessante il guadagno prestazionale che si può ottenere raddoppiando la cache di secondo livello; vedremo anche come scala la linea di processori Pentium4, ovvero L'aumento della frequenza di clock fornisce miglioramenti prestazionali comparabili?
Per fare un confronto con questo sistema, ho scelto una piattaforma composta da una scheda basata sul chipset Apollo KT266A (Epox 8KHA+) e un processore AthlonXP 2000+ (frequenza di clock reale - 1667Mhz). Ho preso solo un processore per Socket462 perché AMD è molto indietro rispetto a Intel nel processo di aumento delle frequenze di clock dei suoi processori e la frequenza di clock di questo processore "top" è persino inferiore alla frequenza di clock del Pentium4 junior processore discusso in questo materiale.

Descrizione delle configurazioni hardware

Per valutare le prestazioni in termini di velocità, ho utilizzato gli stessi test delle recensioni precedenti. Permettetemi di ricordarvi che questi benchmark sono consigliati per i test in 3D Studio MAX dal produttore del programma stesso.
A partire da questo articolo, ho interrotto i test con l'antialiasing di linea abilitato, poiché tutte le schede video moderne eseguono l'antialiasing di linea senza perdita di prestazioni.

Piattaforma n. 1:

Processore: Pentium 4 2,2 GHz (512 Kb L2), Pentium 4 2,0 ​​A GHz (512 Kb L2), Pentium 4 2,0 ​​GHz (256 Kb L2), Pentium 4 1,7 GHz (256 Kb L2).
Scheda madre – Abit TH7II (i850)
Memoria: RDRAM PC800 da 1024 Mb

Piattaforma n. 2:

Processore – AthlonXP 2000+ (1667 Mhz)
Scheda madre – Epox 8KHA+ (Apollo KT266A)
Memoria: SDRAM PC2100 da 1024 Mb
Scheda video – NVIDIA GeForce4 Ti4600 (Detonator versione 27.51)
Disco rigido: 20 Gb IBM DTLA 7200 giri/min

Software:

Windows 2000 SP2
3ds max 4.26 (rendering OpenGL), 1280x1024 32 bit

Testare le caratteristiche di velocità quando si lavora in finestre di proiezione

1 . Il primo benchmark è uno "stress test": l'animazione di una scena viene riprodotta in quattro finestre di proiezione. Tuttavia, il metodo di rendering è diverso. Nelle due finestre in alto la scena si presenta sotto forma di “Wireframe” (cioè in modalità “wire” o “frame”), in basso a sinistra “Smooth + HighLights” + “Edged Faces” (in modalità ombreggiata con bordi selezionati), in basso a destra in basso - “Smooth + HighLights”:

Questa scena contiene pochissimi poligoni - solo 28mila, tuttavia, a causa della riproduzione simultanea dell'animazione in tutte e quattro le finestre, gli fps “totali” sono molto piccoli.

Poligoni: 28868
Sorgenti luminose: 1
Modalità: Wireframe, Uniforma+Alte luci

Quando l'animazione viene visualizzata contemporaneamente in tutte e quattro le finestre di proiezione, la maggior parte del carico per la visualizzazione della scena ricade sulla connessione processore centrale-memoria. Come possiamo vedere, il processore AMD “regge bene” in questo benchmark, confermando la sua valutazione. L'aumento derivante dall'aumento della cache di secondo livello nei processori Intel è molto ridotto e ammonta a circa il 5%

2 . Il secondo punto di riferimento è una scena con sette oggetti geometrici di base, con una complessità totale di diecimila poligoni.

Sei oggetti sono statici, uno si muove lentamente sulla scena, “passando attraverso” altri oggetti. Questo benchmark verifica la correttezza della visualizzazione dell '"intersezione" degli oggetti e la velocità con cui il driver e l'hardware della scheda video possono farcela.

Poligoni: 9712
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

A differenza del precedente, questo benchmark, in questo caso, carica il bus AGP e mostra la velocità della porta AGP della scheda madre. In caso di errata implementazione dell'AGP, il valore fps in questo benchmark scende a circa 80-100.
Pertanto, vediamo che l'implementazione AGP è buona su entrambe le piattaforme. Tuttavia, in questo benchmark, l'aumento della cache dà un aumento molto maggiore rispetto al precedente, fino al 20%.

3 . La terza scena di riferimento contiene una palla che si muove molto lentamente su uno sfondo di 15.000 geometrie poligonali.

La palla non interseca nessun altro oggetto da nessuna parte. Dato che la palla si muove molto lentamente, il pilota “giusto” apporterà pochissime modifiche ad ogni fotogramma. In altre parole, questo benchmark verifica la capacità della scheda video di non ridisegnare oggetti non aggiornabili in ogni fotogramma.

Poligoni: 15653
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

Questo benchmark è simile al precedente, e anche i risultati dei sistemi sono simili ai risultati mostrati nel benchmark precedente: l'AthlonXP 2000+ dimostra ancora una volta l'"onestà" della sua valutazione e il livello raddoppiato di cache del Pentium4 fornisce un notevole aumento della velocità.

4 . Questo benchmark mostra la capacità di una scheda video di elaborare geometrie molto complesse. Il benchmark mostra le prestazioni delle schede video in modalità Smooth+HighLights in scene con geometria complessa.

Poligoni: 200270
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

In questo benchmark di geometria, il risultato dipende dalla potenza dell'unità FPU (poiché è necessario calcolare geometrie complesse) e dalla larghezza di banda della memoria (poiché è necessario eseguire il rendering delle superfici in modalità Smooth+HighLight). Nel primo, Athlon ha un chiaro vantaggio, tuttavia, la larghezza di banda RDRAM è molto più elevata, quindi la piattaforma Socket462 mostra risultati inferiori a quelli del sistema Pentium4 2.0GHz.

5 . Il quinto benchmark mette alla prova le capacità delle schede video nell'elaborazione di geometrie estremamente complesse. Questa volta il numero dei poligoni è quasi raddoppiato e ammonta a quasi 376mila. Le case ora stanno sulla stessa “superficie”.

Questo benchmark è in grado di mettere in ginocchio qualsiasi scheda video: l'fps medio non supera i tre fotogrammi. Il file stesso è stato creato, ovviamente, non a fps=3, le case sono state create separatamente in file diversi e, una volta "installate a terra", la parte inutilizzata della geometria è stata "disattivata" per migliorare le prestazioni.

Poligoni: 376875
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

In un benchmark di geometria più difficile, la situazione è simile alla precedente, tuttavia, con un aumento della geometria elaborata, l'influenza della memoria cache diminuisce e aumenta l'influenza dell'unità FPU.

6 . Un benchmark che mette alla prova la velocità di elaborazione di più sorgenti luminose. Poiché la maggior parte delle schede video non supporta più di 8 sorgenti luminose, questo test e i due successivi contengono 8 sorgenti luminose di diverso tipo. In questo test, 8 sorgenti luminose SpotLight si muovono e illuminano una sorta di “asteroide”:

Va notato che la visualizzazione dell'illuminazione creata dalle sorgenti Spotlight è un processo molto più dispendioso in termini di risorse rispetto alla visualizzazione dell'illuminazione creata dalle sorgenti luminose Omni e direzionali.

Poligoni: 39600
Sorgenti luminose: 8
Modalità: Uniforma+Alte luci

7 . Lo stesso “asteroide”, solo che ora è illuminato da otto sorgenti luminose direzionali. Le luci direzionali sono “più lente” delle luci Omni, ma “più veloci” delle luci Spotlight.

Poligoni: 39600
Sorgenti luminose: 8
Modalità: Uniforma+Alte luci

8 . Ancora lo stesso “asteroide” e ancora otto sorgenti luminose. Ora queste sono sorgenti di tipo Omni, le sorgenti luminose “più veloci” in 3DMAX.

Poligoni: 39600
Sorgenti luminose: 8
Modalità: Uniforma+Alte luci

Nei benchmarks di illuminazione, l'AthlonXP 2000+ mostra risultati paragonabili a quelli del Pentium4 2.0GHz. Il miglioramento delle prestazioni derivante dall'aumento della memoria cache non supera il 10%.

9 . Una scena con geometria "leggera" e un'unica fonte di luce, solo quattromila e mezzo poligoni, che occupano l'intera finestra di proiezione: questo è un punto di riferimento della velocità di rasterizzazione nella modalità Smoth+Highlights.

Quando si sposta la fotocamera, la scheda video deve rasterizzare i poligoni grandi e piccoli (rispetto alle dimensioni dello schermo)

Poligoni: 4684
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

Nel benchmark di rasterizzazione, l'AthlonXP 2000+ ha mostrato un risultato basso - inferiore a quello del Pentium4 con la stessa frequenza clock (1700Mhz). Ciò si spiega con il fatto che in questo benchmark tutto dipende dalla velocità di trasferimento tra processore e memoria sul bus.

10 . Un benchmark che mostra la velocità delle schede video con texture. Il file contiene molte texture e un minimo di geometria. Il punto di riferimento è una palla rotante con 48 texture sovrapposte sulle sue facce.

La geometria minima e le texture massime di questa scena mostrano al massimo la velocità di elaborazione delle texture da parte della scheda video.

Poligoni: 224
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

11 . Una stanza completamente strutturata con la telecamera che si muove al suo interno. Questo benchmark è il più vicino alle applicazioni della vita reale, poiché contiene molte texture, geometrie complesse e molteplici fonti di luce. Questo benchmark mostra le capacità delle schede video durante l'elaborazione di scene complesse in modalità Smooth+Highlight.

Poligoni: 12413
Sorgenti luminose: 8
Modalità: Uniforma+Alte luci

12 . Le "onde" animate con sovrapposizione di texture mostrano la velocità di elaborazione e modifica delle texture.

Poligoni: 880
Sorgenti luminose: 1
Modalità: Uniforma+Alte luci

In tre benchmark delle texture, i sistemi devono calcolare le texture rotanti (nel primo benchmark delle texture), correggere le texture stazionarie con una telecamera rotante (nel secondo) e deformare la texture (nel terzo).
Non è difficile intuire che nel primo benchmark delle texture, la larghezza di banda della memoria e la dimensione della cache sono principalmente importanti - ecco perché l'Athlon "non è all'altezza" del Pentium4 2.2GHz.
La correzione delle texture viene eseguita dalla FPU, quindi nel secondo benchmark l'Athlon2000+ si avvicina al Pentium4 2.2GHz. Inoltre, aumentando la memoria cache si ottiene un aumento del 15%.
Anche il calcolo della deformazione della texture viene eseguito dalla FPU, e in questo benchmark l'AthlonXP 2000+ mostra un risultato migliore rispetto al Pentium4 2.2GHz.

13 . Il benchmark misura la velocità di funzionamento in modalità Wireframe. 111mila poligoni in modalità wireframe costituiranno un test serio per qualsiasi scheda video moderna.

Poligoni: 111270
Sorgenti luminose: 1
Modalità: Wireframe

Questo benchmark delle texture contiene la stessa scena del benchmark 4, ma a differenza del quarto benchmark, qui questa scena è renderizzata in modalità Wireframe. Pertanto, in questo benchmark tutto dipende dalla potenza dell'unità FPU: Ahtlon mostra un risultato paragonabile ai risultati dei processori Pentium4 che funzionano a una frequenza di 2 GHz e l'aumento della dimensione della memoria cache in questo test non aumenta la velocità.

Tutti i benchmark sopra descritti sono consigliati per testare le schede video del produttore 3DMAX, tuttavia, come abbiamo visto, testano le capacità delle schede video per le singole funzioni e tra questi non esistono test "generali". Pertanto, ho aggiunto un altro punto di riferimento: questa è una scena con otto sorgenti luminose, 61371 poligoni e molti piani trasparenti. La complessità di questo file è abbastanza tipica oggi; l'intero file, comprese le texture, occupa più di 6 Mb. L'animazione è progettata per i migliori test: la telecamera si muove nella stanza, catturando tutti gli oggetti. Ecco come appare il primo fotogramma dopo il rendering finale:

Ho usato questa scena per testare le schede video sia in modalità Wireframe che Smoth+Highlights. Pertanto, abbiamo due parametri di riferimento:

14 . Scena in modalità Wireframe

Poligoni: 61371
Sorgenti luminose: 8
Modalità: Wireframe

Poiché la scena in questo benchmark si riflette nella modalità Wireframe, quindi, come nel benchmark precedente, la dimensione della memoria cache non ha un effetto notevole e il risultato dell'AthlonXP2000+, grazie alla produttiva unità FPU, si è rivelato essere uguale al risultato del Pentium4 2.2GHz, che funziona ad una frequenza superiore del 50% ed ha il doppio della memoria cache.

15 . La stessa scena in modalità Smooth+HighLight

Poligoni: 61371
Sorgenti luminose: 8
Modalità: Uniforma+Evidenzia

Dato che la scena si riflette nella modalità Smooth+HighLight, i risultati dell'Athlon non sono buoni come quelli del benchmark precedente. Tuttavia, i risultati dell'AthlonXP 2000+ sono uguali a quelli del Pentium4 2.0GHz, e Athlon conferma ancora una volta la sua valutazione.
La memoria cache da 512Kb invece di 256Kb, in questo benchmark, come nella maggior parte dei benchmark con geometria “media” e modalità Smooth+HighLight, consente di ottenere un aumento della velocità di circa il 15%.

Testare le caratteristiche di velocità durante il rendering finale

Ho realizzato il rendering finale di tre scene della consegna 3ds max4 con gli stessi parametri, in una risoluzione di 800x600, poiché la percentuale dei risultati delle piattaforme testate è la stessa per tutte le risoluzioni da 640x480 a 1600x1200. Queste sono le scene:

Tabella dei risultati (tempo in secondi: più basso è, meglio è):

La velocità del rendering finale dipende principalmente dalla potenza dell'unità FPU, quindi nel rendering finale l'AthlonXP2000+ si è comportato solo leggermente peggio del Pentium4 2.2GHz.

conclusioni

Sulla base della totalità dei risultati in tutti i benchmark di test operativi nelle finestre di proiezione, l'AthlonXP 2000+ mostra risultati paragonabili ai risultati del Pentium4 2.0A GHz. Inoltre, quando opera in modalità Wireframe, l'AthlonXP2000+, grazie alla sua unità FPU eccezionalmente potente, dimostra risultati vicini o uguali a quelli del Pentium4 2.2GHz (nonostante quest'ultimo operi a +50% di frequenza di clock e abbia il doppio della cache). Pertanto, se trascorri la maggior parte del tuo tempo lavorando in modalità Wireframe, l'AthlonXP2000+ è la scelta migliore. Nei test finali di velocità di rendering, anche i risultati dell'AthlonXP 2000+ sono approssimativamente uguali ai risultati del Pentium4 2.2GHz. Pertanto, il costo del processore AthlonXP 2000+ è di 250 USD. (e con il costo del Pentium4 2.0AGHz e 2.2GHz rispettivamente di 350 e 550 USD) e schede madri più economiche, la piattaforma Socket462 è di gran lunga la più redditizia nella categoria prezzo-prestazioni. Tuttavia, il processore più veloce per 3DMAX è il Pentium4 2.2GHz.
La differenza nelle prestazioni dei processori Pentium4 con una dimensione della cache di 256 Kb e 512 Kb nella stragrande maggioranza dei test che simulano il lavoro nelle finestre di proiezione e nei calcoli di rendering finale non supera il 5%, quindi non ha senso cambiare un processore con una cache da 256 Kb in nuovi processori con cache da 512Kb. D'altra parte, oggi è anche inutile acquistare processori con una cache più piccola: i prezzi per i processori con cache da 265 Kb e 512 Kb sono quasi uguali.