ARGOMENTO:

Ciao a tutti
apro questo thread per parlare dell'edizione di quest'anno del nostro challenge su TN-grid

Considerando che il primo Sprint di Formula Boinc inizia il 17/3, penso che la settimana precedente possa essere un buon periodo.
Cioè da lun 7/3 alle 12:00 UTC a lun 14/3 alle 12:00 UTC, con inizio bunker mer 2/3
Sarebbe lo stesso periodo dell'anno scorso

Ho sentito ValterC e come periodo potrebbe andar bene.

I miei dubbi riguardano soprattutto la disponibilità di wu: al momento il progetto sta procedendo spedito con circa 40k wu "in corso" e con una scorta che sta sui 24k ( da quel che vedo credo che il work generator cerchi di arrivare ai 25k, e poi non generea altre wu)

Visto che il ritmo di generazione wu è già al massimo, si potrebbe provare ad aumentare tale scorta magari a 40-50k (o più), sfruttando periodi di carico minore nelle prossime settimane prima di rendere ufficiale il tutto, magari verso il 20/2

In caso di poche wu, non credo che convenga annunciare il challenge

Che ne pensate?
Valter, è fattibile come cosa?

Ricordo che l'anno scorso il server era stato saccheggiato alla grande (ho un ricordo di 80k wu in corso, non so se corretto)
In ogni caso presente

tameta ha scritto:

Ricordo che l'anno scorso il server era stato saccheggiato alla grande (ho un ricordo di 80k wu in corso, non so se corretto)
In ogni caso presente

Sì ricordo anche io un valore simile.... e ricordo anche che il server non ha avuto problemi nella ricezione delle wu riconsegnate all'inizio del challenge.
Quindi l'infrastruttura I/O sembra ok

Non so se però lo storage riesce a reggere.
Da quel che vedo una wu pronta per il download pesa 1.3MB, mentre una in upload pesa 8.3KB
non so se gli stessi valori valgano anche per il server

50.000wu da 1.3MB fanno 65GB di dati....

@Valterc
carica tutte le wu disponibili sta per arrivare un uragano gene.disi.unitn.it/test/forum_thread.php?id=330#2492

Cluster di Dual Xeon E5 2680 v4 (14c/28t) e Dual Xeon Platinum 8176 (28c/56t) per circa 4.000 cores

Buone notizie per TN-grid un pò meno per il challenge

Buro87 ha scritto:

@Valterc
... Cluster di Dual Xeon E5 2680 v4 (14c/28t) e Dual Xeon Platinum 8176 (28c/56t) per circa 4.000 cores
Buone notizie per TN-grid un pò meno per il challenge

Mi chiedo a chi avanzassero tutti sti serveroni e se ha tirato la prolunga da chernobyl per dargli da mangiare una volta accesi

più che altro sarei curioso di sapere, quando dice "I'm getting those on the cheap", che si traduce " li sto comprando a poco" cosa intende per "poco"

Comunque, dai ieri ne ha attivati qualcuno. gene.disi.unitn.it/test/hosts_user.php?userid=3542

Ciao ragazzi, oggi a causa di un bug "misterioso" che ogni tanto si ripresenta, il work generator di Tn-grid ha smesso di funzionare e le wu a disposizione sono scese fino a 2.000.
Valerc ha riavviato il tutto e la coda si sta lentamente riformando.

Indipendentemente da questo inconveniente, stavo considerando l'opportunità di fare il challenge di quest'anno.
Come la vedo io, un challenge serve per aumentare l'interese (e quindi la potenza a disposizione) in un progetto.
Ora come ora, la potenza su Tn-grid non manca: siamo stabilmente oltre le 40k wu in corso e un ritmo di +70 geni/giorno

Inoltre come segnalato nei post precedente , l'utente Technologov sta mettendo molti core su Tn-grid: ora è a circa 1500core con 14 bestioni

Non so se abbia senso caricare ulteriormente di lavoro il server con un challenge.
Rischiare di lasciare a secco quei bestioni, potrebbeessere controproducente e portarli su altri progetti

Che ne pensate?

Credo che a questo quesito solo ValterC possa e debba rispondere (e prendersi la responsabilità)

Difficile prevedere il futuro... Ora come ora il server e` praticamente al suo limite teorico (30 TFLOPS), un challenge in queste condizioni non porterebbe granché come beneficio. Tenete presente anche che una percentuale notevole della potenza di calcolo e` legata ai gruppi/utenti gridcoin (che non sono interessati ai challenge). A mio parere sarebbe il caso di non fare nulla nell'immediato e rivalutare la cosa tra qualche mese.

Buro87 ha scritto:

Comunque, dai ieri ne ha attivati qualcuno. gene.disi.unitn.it/test/hosts_user.php?userid=3542

E' già a 180k di rac!!!!
Io fatico a rimanere a 5k....

valterc ha scritto:

Difficile prevedere il futuro... Ora come ora il server e` praticamente al suo limite teorico (30 TFLOPS), un challenge in queste condizioni non porterebbe granché come beneficio.

Mi sono un pò perso, scusate. Questo server è quello "vecchio" o è già quello "nuovo"??

boboviz ha scritto:

Mi sono un pò perso, scusate. Questo server è quello "vecchio" o è già quello "nuovo"??

Dovrebbe essere ancora quello vecchio. Quando un mesetto fa ho sentito Valter per il challenge, mi ha risposto che il passaggio a quello nuovo non era previsto in tempi brevissimi

Io prenoto già un challenge per fare lo stress test

Il server e` ancora quello vecchio, quello nuovo per ora sta facendo altro. Il passaggio da virtuale a "fisico" non e` semplicissimo, dopodiché il vero vantaggio del server nuovo sarebbe il numero di core (oltre a un po' ovviamente di velocità in più). Il collo di bottiglia e` il work-generator, bisognerebbe riscriverlo (in C++, ora e` python) e renderlo 'parallelo'. Il conto che fa per creare le workunit per ogni gene e` intrinsecamente parallelizzabile, pero` la interazione con il file system, con BOINC e con il db che usiamo noi per gestire il tutto non lo e`.... bisognerebbe mettere mano al codice.

valterc ha scritto:

`.... bisognerebbe mettere mano al codice.

Questa è la preghierina di Bobo prima di coricarsi alla sera

sabayonino ha scritto:

valterc ha scritto:

`.... bisognerebbe mettere mano al codice.

Questa è la preghierina di Bobo prima di coricarsi alla sera

Ma no, perchè?
Il progetto ha lavoro costante, è seguito sul forum, ecc, ecc
Sono ben altri i progetti che avrebbero bisogno di una "riscrittura"....

Appunto ...la preghierina per tutti

La butto lì...
Per il challenge prossimo venturo, quando sarà, per evitare assedi al server e saccheggi di wu si potrebbe pensare ad un approccio tipo PrimeGrid cioè conteggiare solo le wu spedite dopo l'inizio e convalidate prima della fine. Non so le la cosa è fattibile o se richiede di "mettere mano al codice" di Nubman...
OK il bunker può dare un bel vantaggio e un po' di adrenalina ma credo che solo alcuni progetti (per lo più di matematica) possano generare wu a tonnellate da dare in pasto a certe "quasi farm".

In realtà la maggiore richiesta di wu si ha proprio all'avvio del challenge, quindi bunker o non bunker, per il serven cambia poco o nulla.
Anche perchè generalmente chi ha una flotta di pc con tanti thread, non sta li a fare decine di client per ogni pc.

l'apparato I/o ha dimostrato di riuscire a gestire la ricezione di moltissime wu. Ricordo che in un challenge le wu "in corso" erano passate da 80k a 35k in pochissimo tempo, senza problemi di assimilazione

bisognerebbe capire come velocizzare la creazione di wu che se ricordo bene, attualmente è di un'espansione (composta da 294wu * 2 copie) ogni 15min

Spot ha scritto:

La butto lì...
Per il challenge prossimo venturo, quando sarà, per evitare assedi al server e saccheggi di wu si potrebbe pensare ad un approccio tipo PrimeGrid cioè conteggiare solo le wu spedite dopo l'inizio e convalidate prima della fine. Non so le la cosa è fattibile o se richiede di "mettere mano al codice" di Nubman...

Non si può.
Non sono informazioni a cui ho accesso.

valterc ha scritto:

Difficile prevedere il futuro... Ora come ora il server e` praticamente al suo limite teorico (30 TFLOPS), un challenge in queste condizioni non porterebbe granché come beneficio. Tenete presente anche che una percentuale notevole della potenza di calcolo e` legata ai gruppi/utenti gridcoin (che non sono interessati ai challenge). A mio parere sarebbe il caso di non fare nulla nell'immediato e rivalutare la cosa tra qualche mese.

Direi che è stata la scelta migliore
Inoltre con lo stop temporaneo di wcg (dal 14/2 al 22/4) alcuni utenti hanno già girato la loro potnza su Tn-grid gene.disi.unitn.it/test/server_status.php