
Il calcolo distribuito riduce le spese generali perchè limita i costi della strumentazione, della gestione e della manutenzione che tipicamente possono essere associati a una rete sismica tradizionale.
Per ulteriori informazioni visitate il thread ufficiale presente nel nostro forum.
QCN è progettato per monitorare rapidamente un gran numero di sensori sismici utilizzando i PC direttamente collegati agli accelerometri sia per la raccolta dati sia per il calcolo degli algoritmi di triggering. L'algoritmo confronta il valore misurato dell'accelerazione con la media registrata nei precedenti 60 secondi e determina se il segnale è fuori dalla norma. Quando l'intensità del segnale misurato (distinguendo tra componente orizzontale e verticale) è maggiore di tre volte rispetto alla deviazione standard dei precedenti 60 secondi, allora al 99% sappiamo che il segnale misurato non è rappresentativo del "rumore di fondo" registrato nel precedente minuto.
Il PC collegato al sensore cancella i suoi dati solamente quando il server conferma di averne una copia digitale, o è stata verificata l'inesistenza dell'evento sismico, o è trascorsa una settimana dal trigger.
Per determinare se una serie di trigger rappresenta un "probabile terremoto" il server QCN utilizza un filtro simile a quello utilizzato dai PC dei volontari. Il server verifica se la frequenza di trigger provenienti da una certa area geografica supera di 6 volte il valore della deviazione standard (dello stesso parametro, trigger al secondo) per quell'area, considerando la media degli ultimi 10 minuti. In questo caso se gli orari dei trigger possono essere rappresentati su una mappa come una propagazione d'onda circolare da un'unica origine allora l'evento è identificato come "probabile terremoto".

Utente / sensore |
Host ID Link |
Stato host |
Ultima attività (*) |
Totale giorni attività (**) |
Elevation |
Sensore |
Città |
Regione |
Aliprandi |
attivo |
|
818 |
? |
24F8 |
Como |
Lombardia |
|
astroale 1 |
attivo |
|
1005 |
10m |
24F8 |
Genova |
Liguria |
|
astroale 2° |
attivo |
|
826 |
10m |
24F8 |
Genova |
Liguria |
|
Baxnimis |
attivo |
|
567 |
215m liv. mare |
24F8 |
Udine |
Friuli V.G. |
|
Baxnimis 2° |
attivo |
340 |
215m liv. mare |
24F8 |
Udine |
Friuli V.G. |
||
Daniele (bdaniele79) |
inattivo |
17/06/2011 |
771 |
? |
24F8 |
Reggio E. |
Emilia R. |
|
Erotavlas (BOINC) |
attivo |
|
205 |
424Fl (!) |
24F8 |
Siena |
Toscana |
|
Erotavlas 2° |
attivo |
|
25 |
? |
Mac Intel |
Siena |
Toscana |
|
cinolorenzo |
attivo |
|
698 |
? |
24F8 |
Aosta |
ValleD'Aosta |
|
Gandalfk7 |
inattivo |
19/01/2010 |
164 |
? |
24F8 |
Bologna |
Emilia R. |
|
xxx (Lord.UniKorn) |
inattivo |
09/11/2009 |
83 |
? |
24F8 |
Caltagirone |
Sicilia |
|
morse |
attivo |
|
477 |
? |
24F8 |
Reggio E. |
Emilia R. |
|
meteochiusi (paolo) |
inattivo |
31/05/2010 |
340 |
? |
24F8 |
|
|
|
Wizard83 |
attivo |
|
866 |
0m |
24F8 |
Padova |
Veneto |
(*) data dell'ultima WU elaborata sull'host più recente (rilevata manualmente il 19/10/2011)
(**) somma dei giorni (WU) di sorveglianza sensore su tutti gli host utilizzati (rilevata manualmente il 19/10/2011)
- PC con CPU > 2 Ghz e una porta USB libera.
È possibile (leggi sotto) usare anche PC più lenti, modificando la priorità del client QCN manualmente da task manager o automaticamente (in vari modi). Naturalmente è preferibile utilizzare un PC che sia acceso 24 ore su 24 per aver maggiori probabilità di registrare un evento. - Programma BOINC installato.
La versione consigliata è almeno la 6.4 poiché sui PC con più di una CPU virtule (core o HT), che utilizzano versioni precedenti, viene lanciato erroneamente un numero di client maggiore di quello corretto che, vista la natura del programma, è 1. Tuttavia se già BOINC è messo in condizioni (configurazione o tipo di CPU) di lanciare un solo client “elaborativo”, non avrà problemi e lancerà anche un solo client QCN, quindi sarà possibile usare anche una versione 5.x di BOINC. - Collegamento diretto a internet.
Il collegamento, come previsto da BOINC può essere diretto oppure via proxy se ad esempio siete connessi a una LAN, tuttavia in questo caso è bene controllare che non sia bloccata da qualche firewall la porta 23 UDP poiché una delle funzioni essenziali per il funzionamento del client QCN è la sincronizzazione temporale degli eventi tramite un client NTP. Nota si parla di sincronizzazione degli eventi e non dell'orologio del PC, infatti il client NTP utilizzato dal QCN non è “invasivo” e si limita a calcolare la differenza tra il clock del PC e quello del server NTP di Stanford.



Join al Team | ![]() |
Applicazioni | ![]() |
Stato del server | ![]() |
Statistiche interne del progetto |
![]() |
Classifica interna utenti |
![]() |
Pagina dei risultati |
![]() |