[μFluids] Topic ufficiale

[lucab76]

Ecco il thread dal forum di uFluids dove si parla di questo tipo di WU: >>LINK<<

Se guardi il link alla WU del primo post, ti accorgerai che tutti quelli che hanno elaborato quella wu, l'hanno annullata o hanno avuto errori del client.

Certo, a qualcuno wu di quel tipo sono andate a buon fine... ma 19h per il 40% mi sembra un po' troppo! Gli altri che hanno la tua stessa wu che risultati hanno avuto? Anche perchè se troppi utenti hanno avuto problemi con la TUA wu, quella wu verrà annullata comunque, quindi... perchè continuare a perdere tempo?

Vuoi un consiglio? Annullala e segnala sul forum (c'è il thread apposito) il prblema con la wu. Lo sviluppatore del progetto ti darà i crediti anche per il tempo perso.

Putroppo questa è normale amministrazione per uFluids. Il lavoro svolto dagli utenti è più utile allo sviluppatore che agli utenti stessi. Indubbiamente, quelli di uFluids non sono crediti facili. Se ti agganci al progetto su un solo computer e puoi seguirlo, ok. Ma se lo metti su più pc e non hai una sorveglianza continua... otterrai RAC molto bassi. Aspettiamo che il progetto cresca e che le wu bacate diminuiscano...

[djtux]

Io per il momento sto concentrato su altri progetti, ma solo perché ho un solo pc!

[Ma7z0]

uFluids non fa per me animale da classifica, magari nel futuro, se diventerà più stabile (come sono certo accadrà) potrò ritornarci.
Intanto mi dedico agli alieni

Thx Lucab76

[lucab76]

Piccolo UP per questo progetto!

Nell'ultimo burst che ho elaborato, composto da ben 533 WUs, ho avuto soltanto quattro risultati non validi, di cui solo uno imputabile ad una WU bacata. Una volta seganalato l'evento nell'apposito thread, il moderatore ha provveduto ad accreditarmi i crediti in claiming.

Il viaggio verso la stabilità prosegue nel verso giusto e anche il moderatore assiste pazientemente la comunità di utenti.

[lucab76]

Originariamente inviato da lucab76

Piccolo UP per questo progetto!

Si, ok, ma se edito invece di postare.... che UP potrò mai fare???

Me niubbo!!

[Il Capitano]

Originariamente inviato da lucab76

Si, ok, ma se edito invece di postare.... che UP potrò mai fare???

Me niubbo!!

Coraggio coraggio, c'e' una prima volta per tutti

[lucab76]

UP!

Nel primo post trovate informazioni aggiornate relative a questo progetto.
Da leggere e valutare attentamente!
Purtoppo non sono buone notizie!

[schizzobau]

Originariamente inviato da lucab76

UP!

Nel primo post trovate informazioni aggiornate relative a questo progetto.
Da leggere e valutare attentamente!
Purtoppo non sono buone notizie!

azzo, speravo sinceramente che fossero usciti dalla fase alpha...

[lucab76]

Purtroppo no!
Pensa che per un errore dello scheduler, ieri mi ha scaricato 374WUs della serie rect_simple_interface5_*. Oggi ne ho elaborate sei: dovevano durare pochi minuti e invece c'ho passato dalle 2 alle 4h a WU. Riportati i risultati... in pending. Tempo un'ora... 0 crediti e "Workunit error - check skipped"... errore di validazione.
Mi butto sul forum, denuncio il problema... tempo due TUTTE le WUs della serie vengono cancellate. Quindi annullate e rimosse... quindi tutte da buttare... comprese le mie 374!
Reset del progetto e via!

Adesso ho una decina di drops4. Una ha completato dopo 48 minuti. Un'altra dopo 52 minuti è al 110% e sta ancora elaborando... ma almeno so che è un comportamento normale...

Dura la vita dello scaccolatore...

[giopro]

Come accennato, io ho scaricato 4 unità della durata di 27 minuti e le ha completate con una media di 5 minuti l'una. Lo stesso problema si è presentato in nanohive con unità teoricamente lunghe e che si completavano in breve tempo. Ho anche avuto i casi al contrario di tempi di elaborazione più lunghi.

Un'altra cosa che con ufluids non mi è capitata, ma con nano sì, è l'elaborazione che procede per diversi secondi con il timer bloccato, con allungamento dei tempi reali di elaborazione.

Ciao

[lucab76]

Ah, nel caso vi toccasse... è meglio annullare ogni WU a mano, piuttosto che fare il reset del progetto.

So che per fare un reset si impiega un secondo, ma ci sono almeno due motivi per annullare le WUs a mano:
1) Annullandole una per una si possono eliminare SOLO le WUs messe in stato di "Cancelled" dall'amministratore e non vengono gettate WUs di altre serie che magari vanno perfettamente a termine.
2) Facendo il reset le WUs non vengono abortite server-side, ma solo cancellate client-side. A voi non cambia niente, perchè vi liberate comunque delle WUs in cache. Ma sul server le cose cambiano... perchè con il reset, il Manager non comunica al server di abortire le vostre WUs. E queste rimarranno a portare via spazio nel database, fino a quando non andranno in scadenza.

Per contro c'è anche un malus: quando annullate le WUs calerà la vostra quota giornaliera di WUs, ovvero la quantità di WUs che potrete scaricare in un giorno (fissata a 300WUs). Ogni WU annullata a mano o che termina con un errore, vi costa una WU in meno nella quota. Ad ogni risultato ritornato con successo al server , la vostra quota riacquisterà una WU. Quindi, ad esempio, se avessi annullato ogni WU la mia quota sarebbe andata in negativo!! impedendomi di scaricare nuovo lavoro! Con il reset, al contrario, la vostra quota rimane invariata, anche se state buttando via un mare di WUs.

Quindi con il mio reset ho lasciato 374 WUs a prender posto nel database fino al 22 febbraio. Ma ovviamente non potevo annullare a mano 374 WUs, una per una... In più erano tutte dello stesso tipo e tutte erano state cancellate. A mali estremi... estremi rimedi!

[lucab76]

Originariamente inviato da giopro

Come accennato, io ho scaricato 4 unità della durata di 27 minuti e le ha completate con una media di 5 minuti l'una. Lo stesso problema si è presentato in nanohive con unità teoricamente lunghe e che si completavano in breve tempo. Ho anche avuto i casi al contrario di tempi di elaborazione più lunghi.

Sono problemi legati entrambi al RDCF (Result duration correction factor, Fattore di correzione della durata dei risultati). Questo parametro viene impostato di default a 1 e poi può variare a seconda dei tempi di elaborazione.

Ogni volta che ricevete una WU, lo scheduler riceve dal server un'indicazione sulla durata della WU appena scaricata. Lo scheduler correggerà questa indicazione in base al DCF e vi darà la durata prevista dell'elaborazione per la vostra macchina nella colonna To completion. Si potranno verificare due casi:
- il vostro processore impiega meno del tempo previsto. In questo caso, lo scheduler comunicherà il risultato al server e chiederà di abbassare il DCF. Così facendo le successive WUs scaricate avranno una durata prevista più breve, approssimando meglio il tempo di completamento previsto.
- il vostro processore impiega più del tempo previsto. In questo caso, lo scheduler comunicherà il risultato al server e chiederà di aumentare il DCF. Così facendo le successive WUs scaricate avranno una durata prevista più lunga, anche in questo caso per approssimare meglio il tempo di completamento.

Ovviamente questo ragionamento fila se le WUs sono tutte dello stesso tipo e richiedono tutte il medesimo tempo di elaborazione. Ma se le WUs variano di molto il tempo richiesto, si possono verificare spiacevoli situazioni.

E' chiaro infatti che se un PC ha un DCF molto basso, lo scheduler scaricherà maggiori quantità di lavoro per quella macchina, perchè supporrà che la vostra macchina sia in grado di completare più velocemente le WUs.

Ora immaginiamo che il vostro DCF sia diventato molto basso in seguito a WUs molto corte (da 10 minuti, per esempio). Dopo qualche giorno di abbandono, tornate a richiedere lavoro, senza sapere che le WUs sono cambiate e sono diventate mooolto più lunghe (2 ore, per esmpio). Bene, siete nei guai.

Grazie al vostro basso DCF lo scheduler richiederà moooolte WUs in più del normale. Ma queste WUs non saranno più da 10 minuti, ma da 2 ore! Vi ritroverete quindi la cache piena di WUs, cortissime secondo lo scheduler, ma purtroppo lunghissime per voi e molto probabilmente sarete costretti ad abortirne un bel po'. Cose che capitano.

Ovviamente l'effetto inverso (alto DCF e meno lavoro) è meno grave. Per un po' avrete meno lavoro, ma poi il DCF tornerà ad abbassarsi e tutto tornerà alla normalità!

Originariamente inviato da giopro

Un'altra cosa che con ufluids non mi è capitata, ma con nano sì, è l'elaborazione che procede per diversi secondi con il timer bloccato, con allungamento dei tempi reali di elaborazione.
Ciao

Come puoi vedere dal primo post "aggiornato", adesso capita anche su uFluids. Non sempre l'elaborazione procede linearmente e quindi capita anche questo! La cosa grave è che sembra proprio che la WU sia bloccata e magari si rischia di abortirla per nulla!

Problemi da progetti in fase Alpha...

[Fra_cool]

Ciao!

Sono un paio di giorni che non riesco a uppare Wu finite (non ho provato a scaricarne altre perché vorrei girare la macchina su altro)

questo è il log:

12/03/2007 10.39.54|uFluids|Started upload of file bridge2_133_1.05_0.002_0.9_0_0_0_0_0
12/03/2007 10.40.16||Project communication failed: attempting access to reference site
12/03/2007 10.40.17|uFluids|Temporarily failed upload of bridge2_133_1.05_0.002_0.9_0_0_0_0_0: http error
12/03/2007 10.40.17|uFluids|Backing off 2 hours, 5 minutes and 9 seconds on upload of file bridge2_133_1.05_0.002_0.9_0_0_0_0_0
12/03/2007 10.40.18||Access to reference site succeeded - project servers may be temporarily down.
12/03/2007 10.40.48|uFluids|Fetching scheduler list
12/03/2007 10.41.09||Project communication failed: attempting access to reference site
12/03/2007 10.41.13||Access to reference site succeeded - project servers may be temporarily down.
12/03/2007 10.41.13|uFluids|Scheduler list fetch failed: http error
12/03/2007 10.41.13|uFluids|11 consecutive failures fetching scheduler list - deferring 604800 seconds
12/03/2007 10.41.13|uFluids|Deferring scheduler requests for 1 weeks, 0 days, 0 hours, 0 minutes and 0 seconds

Sembrerebbe che il server sia down...
Qualche info?

(dall'homepage non sono riuscito a trovare le info sullo stato dei server)

PS: giusto per essere anche un pò utile al thread, si tratta di WU "rect_simple_interface7_" (circa 5400 secondi su E6600 Conroe @ 3100 Mhz circa) e "bridge2_" (tempi variabili dai 72 agli 800 secondi - stessa macchina)

[lucab76]

Originariamente inviato da Fra_cool

Sono un paio di giorni che non riesco a uppare Wu finite (non ho provato a scaricarne altre perché vorrei girare la macchina su altro)

E' un problema di indirizzi DNS in cache: qualche giorno fa hanno cambiato gli IP delle macchine del progetto e il tuo BOINC non se n'è accorto.

Devi lanciare dal prompt dei comandi "ipconfig /flushdns". Questo comando ripulisce la tabella dei DNS in cache e obbliga il resolver, durante il primo update, a cercare un nuovo indirizzo IP per il sito di uFluids.

Puoi anche vedere con il comando "ipconfig /displaydns" quale indirizzo IP è attualmente associato al server di uFluids. Io, ad esempio, ho questa entry:
www.ufluids.net
----------------------------------------
Nome record . . . . . : www.ufluids.net
Tipo record . . . . . : 1
Durata (TTL). . . . . : 254
Lunghezza dati. . . . : 4
Sezione . . . . . . . : Risposta
Record A (Host) . . . : 74.133.20.134

Per quanto mi riguarda ho uFluids sospeso da un bel po' di tempo, quindi il 74.133.20.134 potrebbe non essere più valido.

Ti consiglio quindi di:
- dare dal prompt dei comandi "ipconfig /displaydns" e annotarti il tuo attuale IP per uFluids;
- dare dal prompt dei comandi "ipconfig /flushdns" per cancellare ogni entry.
- entrare in BOINC e rifare un update manuale di uFluids, accertandosi che trasferisca tutto correttamente.
- dare dal prompt dei comandi "ipconfig /displaydns" per verificare che l'IP associato a uFluids sia cambiato.

Quando avrai risolto il problema, mi posteresti ip vecchio e ip nuovo?
Thanks!

PS1: Lo stato dei server di uFluids è nella home del progetto, nel riquadro in basso a destra:
Status of μFluids server (Updated 03/12/07 07:11:07)
Processes on server: [scheduler] [feeder] [deleter] [transitioner] [validator] [assimilator]

PS2: Grazie dei tempi di elaborazione, appena ho tempo, aggiorno il primo post!

[Fra_cool]

Ok, grazie!

Ho eseguito la procedura che mi hai indicato, ma

12/03/2007 12.34.56|uFluids|Fetching scheduler list
12/03/2007 12.35.16|uFluids|Started upload of file bridge2_180_1.05_0.002_0.8_0_0_0_0_0
12/03/2007 12.35.18||Project communication failed: attempting access to reference site
12/03/2007 12.35.20||Access to reference site succeeded - project servers may be temporarily down.
12/03/2007 12.35.22|uFluids|Scheduler list fetch failed: http error
12/03/2007 12.35.22|uFluids|14 consecutive failures fetching scheduler list - deferring 604800 seconds
12/03/2007 12.35.22|uFluids|Deferring scheduler requests for 1 weeks, 0 days, 0 hours, 0 minutes and 0 seconds

Questi i risultati prima e dopo il rinnovo dei DNS


Per curiosità, ho dato lo stesso comando ad una macchina della stessa rete, che però comunica normalmente col progetto, e tranne che per il TTL ho avuto gli stessi risultati.

[Fra_cool]

Problema risolto!

Dopo aver resettato i DNS (che poi era già aggiornato...), non avevo riavviato!

Dopo un restart di Boinc, tutto ok!

Grazie per l'assistenza!

Ciao, Frà!

[djtux]

Comunque a me il progetto occupa 3.5/4 MB di ram e non 256 o comunque almeno 100 come si può capire dal secondo topic.
Adesso mi viene un dubbio: sono fortunato io a ricevere delle wu così leggere o è il caso di aggiornare il secondo topic?

E poi adesso le wu di chiamano widge*** e non più bannulus*** o upbend***. Per lo meno a me capitano solo le prime.

Grazie.

[lucab76]

Originariamente inviato da lucab76

Requisiti minimi a livello hardware:
Per partecipare al progetto è consigliato almeno un Pentium3 a 500MHz (o equivalente) e almeno 256MB di memoria RAM.

Work units disponibili: Aggiornamento
I tipi di WUs disponibili cambia pressochè settimanalmente.
E' praticamente impossibile star dietro a tutti i nuovi batch di lavoro.
Le WUs sono generalmente brevi e non richiedono molta memoria durante l'esecuzione.
Un paio di WUs del recente passato:
upbend2_jon_*: 5.5KB - 62B - 7 giorni - ~8MB;
bannulus1_*: 9.0KB - 257B - 7 giorni - ~6MB;

Originariamente inviato da djtux

Comunque a me il progetto occupa 3.5/4 MB di ram e non 256 o comunque almeno 100 come si può capire dal secondo topic.
Adesso mi viene un dubbio: sono fortunato io a ricevere delle wu così leggere o è il caso di aggiornare il secondo topic?
E poi adesso le wu di chiamano widge*** e non più bannulus*** o upbend***. Per lo meno a me capitano solo le prime.
Grazie.

Scusami djtux, ma ogni tanto ho grossi problemi a capire i tuoi post!
Ti ho riportato in quote il testo del secondo topic.

Dire, nei requisiti hardware, che occorrono 256MB di memoria RAM non implica che l'esecuzione della Work Unit porterà via 256MB di RAM... è solo un requisito per la macchina che dovrà eseguire la Work Unit. Tali requisiti sono veramente bassi... quindi è lecito aspettarsi Work Unit molto leggere, come, del resto, ho scritto sotto.

Se ci fai caso, nell'elenco delle Work Unit, le upbend e le bannulus richiedevano rispettivamente solo 8 e 6MB di RAM. I requisiti minimi richiesti a livello hardware sono pubblicati dagli sviluppatori e, come tali, vanno riportati in evidenza nel thread ufficiale.

Per quanto riguarda i tipi di Work Unit, non a caso ho scritto: "I tipi di WUs disponibili cambia pressochè settimanalmente. E' praticamente impossibile star dietro a tutti i nuovi batch di lavoro.". L'ho fatto proprio per sottolineare che, registrandosi a uFluids, sarebbero capitate Work Unit diverse da quelle citate in elenco. Ma, visto che gli sviluppatori del progetto cambiano batch quasi ogni settimana, è impossibile, per me, mantenere aggiornato l'elenco... E anche questo, per chi ha voglia di mettere un po' d'attenzione in quello che, forse, legge, si evince chiaramente dal testo.

[djtux]

Originariamente inviato da lucab76

Scusami djtux, ma ogni tanto ho grossi problemi a capire i tuoi post!
Ti ho riportato in quote il testo del secondo topic.

Dire, nei requisiti hardware, che occorrono 256MB di memoria RAM non implica che l'esecuzione della Work Unit porterà via 256MB di RAM... è solo un requisito per la macchina che dovrà eseguire la Work Unit. Tali requisiti sono veramente bassi... quindi è lecito aspettarsi Work Unit molto leggere, come, del resto, ho scritto sotto.

Se ci fai caso, nell'elenco delle Work Unit, le upbend e le bannulus richiedevano rispettivamente solo 8 e 6MB di RAM. I requisiti minimi richiesti a livello hardware sono pubblicati dagli sviluppatori e, come tali, vanno riportati in evidenza nel thread ufficiale.

Per quanto riguarda i tipi di Work Unit, non a caso ho scritto: "I tipi di WUs disponibili cambia pressochè settimanalmente. E' praticamente impossibile star dietro a tutti i nuovi batch di lavoro.". L'ho fatto proprio per sottolineare che, registrandosi a uFluids, sarebbero capitate Work Unit diverse da quelle citate in elenco. Ma, visto che gli sviluppatori del progetto cambiano batch quasi ogni settimana, è impossibile, per me, mantenere aggiornato l'elenco... E anche questo, per chi ha voglia di mettere un po' d'attenzione in quello che, forse, legge, si evince chiaramente dal testo.

Ops!!
Caspita!
Si vede che l'avevo letto proprio Troppo di Fretta quel topic!
Ti prego di scusarmi, la prossima volta non succederà una cosa del genere...
Adesso per punizione scaccolerò su uFluids finché non arrivo almeno a 3000 crediti!

[SickBoy88]

Volevo fare l'attach a questo progetto ma.. pare che per il momento nn funzioni..
Solo a me o anche a voi?