Mah direi che non serve. RC.LOCAL è l' ultimo ad essere eseguito. Quindi anche con RC3.d non risolvi.
Lo sospettavo. Non c'è un parametro di delay direttamente dentro la configurazione watchdog ?
c'è interval = <interval> Set the interval between two writes to the watchdog device. The kernel drivers expects a write command every minute. Otherwise the system will be rebooted. Default value is 10 seconds. An interval of more than a minute can only be used with the -f command-line option. Dici che può fare al caso nostro? Per quanto riguarda il blocco del modem anche a me capitava (modem 3g) che si disconnettesse (e non sembrava esserci modo di riconnetterlo senza riavviare)
Si, stessa cosa capita anche a me. Forse le chiavette non sono fatte per continuare a funzionare interrottamente. Poi ogni tanto l'operatore 3 riavvia la rete (di solito a notte fonda) e li salta la connessione. ho risolto con uno script che ogni minuto controllava se c'era internet o meno e in caso negativo, tramite uno script che faceva delle apposite chiamate al kernel, emulava la disconnessione/riconnessione fisica del modem che tornava poi ad essere funzionale (e quindi poi lo riconnetteva a internet).
E condividi i dettagli di questo script bertani, non essere avido  Io tolgo le chiamate al kernel, ci metto il reboot e ho sistemato. (sul rig ho anche hamachi, visto che la connessione della 3 è nattata e hamachi non torna up dopo la disconnessione senza fare reboot) Linux non è affatto complicato, anzi è molto semplice.. questo non significa che sia facile  Aspé, vuoi ridere? Ho cercato di settare in modo permanente la time zone e il cambio d'ora... e ho fallito più e più volte. Prima di scoprire che non basta settarla, bisogna anche dare il comando per scriverla nel cmos... Non mi pare proprio semplice FaSan, se condividi anche tu i dettagli dello script, magari mixandoli risolvo In ogni caso ringrazio entrambi |
|
|
|
Sarebbe utile a questo punto sapere come lanci la connessione. Hai parlato di una chiavetta 3G quindi dovrebbe esserci un demone PPPd
A boh. Ho configurato la chiavetta, inserito i parametri di connessione, settato disponibile per tutti gli utenti e "connetti automaticamente". Impostazione di base di network manager. All'avvio, appena compare il desktop dopo qualche secondo la chiavetta si logga e la connessione diventa disponibile. Il reboot con il watchdog avviene "ore prima" che si presenti il desktop. Non ci arrivo nemmeno a vederlo il desktop Ho idea che anche rc3.d lavori troppo d'anticipo ma ora provo cmq. |
|
|
|
grazie mille degli ulteriori consigli!
per oggi basta andare sotto la scrivania in ufficio
Ti capisco!! |
|
|
|
Per rc.local ti basta mettere, prima del "touch" il comando da lanciare (per esempio) :
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/etc/init.d/watchdog start
touch /var/lock/subsys/local
FaSan
Ok, questo non funziona (sto provando su debian) Disabilitato il watchdog al boot. Aggiunto il watchdog al rc.local secondo la tua linea ma non succede nulla (nel mio file cmq non era presente touch, ma exit 0 e basta). Se avvio il watchdog a mano dal terminale e la connessione non è attiva, il reboot avviene correttamente Proviamo un po' quella cosa dei link rc3.d EDIT: cambiando la linea in rc.local da /etc/init.d/watchdog start a Il pc torna in un loop di reboot infinito. Suppongo che quindi il watchdog parta, ma anche stavolta troppo presto rispetto allo stabilirsi della connessione internet. |
|
|
|
mi sto convincendo di darla indietro  Non te la prendere ma mi consola vedere qualcuno che sta entrando nel mio stesso inferno Un mese fa ero esattamente al tuo posto. BTW, consiglio della nonna. Io ho dato indietro ad amazon 2 schede (amazon santo subito). La prima perché sbagliavo io, la seconda perché effettivamente difettosa (non partiva una ventola). Ciò che ho imparato è questo. Ogni scheda ha le proprie impostazioni, applicare i settagli di una scheda ad un altra, quasi sempre porta al crash. Durante la fase di test cancellare SEMPRE i file bin nella cartella di cgminer. Influenzano di brutto il rendimento! E' come se cgminer facesse casino con i file di configurazione. Per l'overclock provare a seguire questa guida: https://github.com/ckolivas/cgminer/blob/master/SCRYPT-README (sezione tuning). A me la guida non ha mai funzionato, non ho mai trovato quel punto dove l'hash inizia a decrescere. Però cmq ho pian piano raggiunto una configurazione stabile. Ho tre schede 7950. mi danno rispettivamente 650 - 670 - 680. Totale 2 mhs. Temperature sui 79 gradi con ventole al 70%. In casa, quando le porterò in montagna mi aspetto temperature più basse. La prima scheda ha un OC minore rispetto alle altre perché ha la posizione in alto nel case e altrimenti scalda parecchio. Ventila a più non posso, miraccomando! Compra qualche ventola aggiuntiva da pochi euro e attaccala dove puoi mantenendo un corretto orientamento del flusso d'aria. Una scheda che tiene le ventole sempre al 100% dicono che muoia nel giro di qualche mese. |
|
|
|
Ma che bellini |
|
|
|
Il fatto che la scheda non venga proprio rilevata sullo slot 1x16x... è stranissimo. A me le rileva senza problemi, al massimo freezano dopo 6 ore di mining ma forse è anche una questione di overclock non adatto allo slot da 1. Moltissima gente poi monta le 7950 sugli slot da 1 con i riser (alimentati e non). Dovrebbero magari esserci prestazioni diffenrenti ma quantomeno dovrebbe essere riconosciuta dal sistema. Ovviamente scordati il monitor, la MoBo non prevede monitor sullo slot 1x, quindi quello è normale che non funzioni. tra l'altro, curiosità a cui non avevo fatto caso (la seconda scheda non l'avevo ancora aperta), la prima 7950 ha 2 connettori di alimentazione 8 pin, la seconda (quella che non va) ha un 8 pin e uno da 6.
Questa cosa è stranissima. Io ne ho 3 e tutte e 3 hanno connettori 2x8. |
|
|
|
Hai due strade:
- Modifichi manualmente i link in rc3.d impostando un numero più alto di startup e facendolo eseguire dopo il network
- Non lo fai partire in automatico al boot ma lo lanci da rc.local (che è l' ultimo ad essere eseguito a macchina avviata)
Senza dilungarmi troppo, i demoni vengono eseguiti nell' ordine che trovi nel link simbolico, dal numero 1 al numero 99, quindi ti basta vedere a che livello (numero) parte il network per farlo poi partire dopo.
Un giorno qualcuno dovrà spiegarmi perché con linux è sempre tutto così complicato Cmq vado a spulciare i link rc3.d Nel frattempo puoi darmi qualche info in più su come lanciarlo da rc.local? Anche un link va benissimo Mi tengo una possibilità aperta prima di fare casino con rc3.d Altra cosa importante da dire è che non vengono eseguiti in background ma in ordine. Mettendo quindi un delay nello script non risolvi nulla se non rallentare la macchina nella fase di startup.
Teamviewer "devo" lanciarlo con 120 secondi di ritardo rispetto all'avvio del sistema, perché altrimenti tutte le connessioni in entrata si freezzano. Pensavo di cavarmela aggiungendo lo watchdog allo stesso script, ma era pia illusione |
|
|
|
O mamma, 14 risposte? che cosa ho scatenato? Le mie necessità al momento sono molto modeste. Controllare che sia attiva una connessione internet e nel caso riavviare, capita infatti che ogni tanto la chiavetta 3g si blocchi. Ovviamente se il sistema si riavvia anche nel caso di freeze ecc, meglio ancora. Per questo motivo stavo guardando lo watchdog software sebbene, sfortunatamente, non funziona come dovrebbe. Mi capita la stessa cosa riportata nel link del mio primo post. Il demone si avvia al boot ma al boot la chiavetta internet 3g non è stata ancora inizializzata, quindi il ping scade e il sistema entra in un ciclo di reboot infinito. Disabilitando l'avvio di watchdog al boot, il sistema si avvia, solo che poi non so come avviare in automatico il demone dopo il login. uno script di questo tipo: #!/bin/bash
sleep 120
teamviewer &
watchdog & piazzato in /usr/bin e richiamato da un file .desktop in autostart... Non funziona (teamviewer parte ma il watchdog no). Qualche suggerimento? se riuscissi a far partire il watchdog al login mi andrebbe più che bene. L'idea di un watchdog hardware (se ho capito la proposta di bertani) è troppo complessa per me ora, quello software sarebbe più che sufficiente se funzionasse Per chi ha il rig lontano da casa, voi come fate?
windows: teamviewer e simili, linux: ssh Che sono le stesse cose che utilizzo io Tuttavia se si pianta la connessione c'è poco da fare (con la chiavetta ho notato che succede ogni tanto), per questo mi serviva un watchdog sul ping. Poi fin tanto che il sistema è online lo gestisco o tramite ssh o tramite teamweaver. |
|
|
|
Stavo pensando a uno watchdog per il rig, qualcosa che effettui un reboot se la connessione non è attiva, se il sistema si blocca ecc. So che debian/ubuntu ha uno watchdog ma sembra che il test della connettività dia qualche problema. Il ping parte all'avvio quando ancora la connessione di norma non è attiva e la macchina va in in ciclo di riavvio infinito: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=30&t=20149Un alternativa potrebbe essere crontab + uno script. Tuttavia mi chiedevo se esiste qualche pacchetto bello comodo per la gestione di queste cose, magari anche con la GUI Per chi ha il rig lontano da casa, voi come fate? Grazie |
|
|
|
utilizza uno slot pci-e 16x e lo "divide" in 4 per le 4 schede esterne.. quindi non vedo come un x1 non possa andare bene per il nostro caso di sopra
Infatti dovrebbe andare bene Però ho imparato che nella realtà ci sono un sacco di variabili impreviste purtroppo prodotto spettacolare ad un prezzo impossibile!
In effetti è un bell'oggetto, peccato il prezzo che taglia le gambe. Dai un occhio a questo topic: https://bitcointalk.org/index.php?topic=243255.0All'interno ci sono vari link interessanti. Al momento non c'è ancora nulla di pronto, però chissà |
|
|
|
no...non è quello dei 5 sec...ma è quello attuale! ha ragione gdassori
Eh, gdassori è saggio, anche se nn mi risponde ai pm! Cmq grazie a tutti, ora molte cose sono più chiare! Quando ho visto questa immagine non capivo quale scheda fosse in grado di produrre 820! Troppi per una GPU e troppo pochi per un asic. Poi ho visto BLF e mi è venuto in mente che hanno effettivamente prodotto qualcosa (FPGA?) di simile tempo addietro Questi prodotti si trovano ancora in giro da acquistare seduta stante? |
|
|
|
spettacolare quella discussione!  ci sono delle soluzioni veramente interessanti e altre da fuori di crapa... e stiamo parlando di 2 anni ed è già storia.. grazie dei consigli, come dici tu son tante cose nuove e le si imparano a proprie spese.. se la corrente gratis ce l'avessi a casa, farei anche io un mega rig da 5-6 schede, pultroppo a lavoro non posso mettere un aereo sotto la scrivania..  Ok, per onestà devo fare una aggiunta. La scheda montata sul riser 1x16x non era stabile. Dopo circa 7-8 ore di funzionamento continuo, continuavo a trovare il rig frezzato. Un reboot sistemava tutto ma il problema si ripresentava dopo le solite ore. Ho notato questa cosa solo con un test di lunga durata, tenendo acceso per un paio d'ore non c'erano segni di instabilità. Non so se fosse il riser difettoso, se servisse un riser alimentato o altro. Siccome non volevo sbattermi, ho rimesso un riser 16x16x non powered e il rig è stabile da 24 ore. |
|
|
|
|
Ciao a tutti,
qualcuno può spiegarmi, nella schermata iniziale di cgminer a cosa corrispondono i doppi valori nella sezione hash? Uno è il valore reale (a dx) ma l'altro?
Ora ad esempio ho: GPU0: 78C° 2825 RPM | 660.3K / 662.8 Kh/s | Acc Rrr Hw U:3.28/m I:20
Avrei inoltre curiosità di sapere a cosa corrisponde la U...
Grazie
|
|
|
|
Vediamo se riesco a rendere un po' dell'aiuto che ho ricevuto da quando sono qui grazie per l'info, è un problema comune quindi.. non ho trovato nessuno che ne parlava qui sul forum,
In realtà non è un problema così comune è comune tra chi (come te e me) preferisce usare dei case chiusi, che di solito non sono fatti per il mining e quindi generano un sacco di scomodità. La maggior parte delle persone si attrezza con "frame" appositi. In questa discussione trovi un sacco di foto da cui prendere ispirazione, come ho fatto io. E' anche storia, perché si passa dai primi case con una scheda, alle farm di gpu sugli scaffali, fino agli asic https://bitcointalk.org/index.php?topic=7216.0Io ora, come dicevo, ho un thermaltake armor+, con tre schede (stesso modello delle tue). Il mio prossimo passo probabilmente sarà qualcosa del genere: http://ecoinomist.com/weather-proof-gpu-litecoin-mining-rig-pictures pensavo fosse perchè le vapor-x sono piu alte delle altre..
Si, effettivamente sono le più grasse del mercato L'ho imparato anche io a mie spese. mi confermi quindi che si possono utilizzare i pci 1x senza problemi?
Confermo, ho tre schede 7950 e quella sul riser 1x16x da lo stesso rendimento delle altre, a parità di impostazioni. Fin tanto che ti fermi a max 3 schede non dovrebbero nemmeno servire dei riser "powered". Da quanto ho capito (ma se interviene qualche esperto è meglio), i riser alimentati tipo quelli di cablesauros, servono quando monti più di 4 schede sulla stessa MoBO altrimenti può bruciarsi il connettore di alimentazione. Ma attenzione, non il connettore delle schede, che sono alimentate a parte, quello della MoBO che non è fatto per assorbire la corrente richiesta da 4 schede. Detto ciò ti do un consiglio che se lo avessero dato a me mi avrebbe salvato da un intero pomeriggio di panico. Sotto Linux (win nn so). se metti una scheda sullo slot da 1x tramite riser, cgminer sposta l'ordine di riconoscimento. E la mette in coda a tutte le schede montate sui PCI 16x. Esempio pratico: Se hai 3 schede, A-GPU0 (slot 16x) B-GPU1 (slot 16x) e C-GPU2 (slot 16x) e sposti la A-GPU0 sullo slot 1x (tramite riser) cambierà l'ordine di riconoscimento. Cgminer riconoscerà in questo ordine: B-GPU0 (slot 16x) C-GPU1 (slot 16x) A-GPU2 (slot 1x). Questo discorso si applica anche se hai solo due schede, nel momento in cui ne piazzi una sullo slot 1x. E questa cosa può portare piccoli drammi perché tutti i settaggi impostati in cgminer vengono applicati alle schede, senza tener conto del cambio di slot. Spesso due schede hanno tolleranze e limiti diversi, per cui i settaggi di una possono far crashare l'altra. A me è successo questo Quindi quando sposti le schede, ricordati di far partire sempre cgminer con un settaggio base. Almeno nn corri il rischio di incasinare tutto come è successo a me. buon mining! |
|
|
|
sono l'unico che è incappato in questo problema o come avete risolto?
Ci incappiamo tutti agli inizi In un termaltake armor+ ci stanno due schede 7950 sapphire vapor x. Io ne ho tre e ho optato per una soluzione simile a questa: https://bitcointalk.org/index.php?topic=7216.msg2203057#msg2203057+ riser ovviamente. 16x(2) e 1x16x(1) Cmq per tenere il case chiuso, dovrai avere un buon buon set di ventole. |
|
|
|
Ok, ora ci sono. E' un reverse tunneling (credo si chiami così) Il rig che inizia la connessione ssh e la mantiene sempre attiva con mioproxy.it (uno script in autostart basterebbe). E quando si ha necessità da PCHome ci si logga a mioproxy.it. L'aveva già proposto FaSan (credo!) Puoi fare un tunnel ssh con un IP statico esterno
Detto ciò, il punto centrare di questo ragionamento è "mioproxy.it" Mi vengono in mente due possibilità: mettersi su un "server mioproxy.it" (mi sembra ne parlasse gdassori). utilizzare un servizio di terze parti. Avevi in mente qualcuno che offre un servizio mioproxy.it free? |
|
|
|
Quando dico "il server remoto sia raggiungibile a mioproxy.it" intendo dire che il proxy (il server remoto insomma) ha come indirizzo ip quello a cui punta il dominio mioproxy.it.. ti torna ora?
Molto poco Abbi pazienza, riesci a fare un esempio pratico? RIG - ip pubblico assegnato dal provider: 99.99.99.1 (porta 22 chiusa) - ip interno alla rete del provider: 11.11.11.1 mioproxy.it - ip pubblico 99.99.99.2 PChome - ip pubblico 99.99.99.3 PChome --> porta 22 ----> mioproxy.it ----> porta 22 ----| RIG (99.99.99.1) porta 22 chiusa.| Se mioproxy.it punta a RIG, punterà a 99.99.99.1 E qui si ferma, perché non arriverò a 11.11.11.1. Quindi sicuramente continuo a non capire qualcosa |
|
|
|
Strano, se leggi con calma e googlei per quelle cose che non capisci dovresti aver tutti gli strumenti per comprendere quanto ho scritto..
In realtà qualcosa avevo capito ma c'è un punto che non mi torna. Il rig è il computer che mina, insomma il server al quale vogliamo accedere da remoto.
PcHome è il computer dal quale vuoi accedere al rig.
mioproxy.it è un server remoto sul quale abbiamo già accesso ssh.
Quindi se non ho capito male. Considerando che la porta sshd sia quella di default (22), che il server remoto (che fungerà da proxy) sia raggiungibile a mioproxy.it e che su questo proxy sia attivo un server ssh con utente pincopallino:
C'è un server SSH su RIG. Questo server è visibile a mioproxy.it che ha a sua volta un server SSH -visibile dall'esterno-. Io entro da mioproxy e da li arrivo a RIG. E' questo il senso? Te lo chiedo perché c'è qualcosa che non mi torna. Nell'attuale situazione il server remoto (RIG) non è visibile da mioproxy.it Suppongo di aver capito male la tua soluzione |
|
|
|
Spero di essere stato abbastanza chiaro.. Abbiamo visto come....
Non ho capito assolutamente nulla  Cmq questa storia mi interessa, stavo giusto leggendo l'IPV6 di gdassori, perché teamviewer è una soluzione poco "pulita", per tutta una serie di ragioni. Ti va di provare a spiegarmela in modo più semplice? Tieni conto, io conoscenze zero Tipo, chi è il RIG e chi è il PcHome e se c'è una terza entità (tipo mioproxy.it, chi è? un servizio tipo no-ip o un servizio esterno di proxy? o altro?). Se è il metodo più semplice in assoluto, bramo dalla voglia di capirlo! Ti direi una magica parola che apre un modo di possibilità: IPv6, ma non voglio complicarti la vita... anche se mi pare tu sia assai intraprendente, quindi .. ti lancio il sasso: http://tunnelbroker.net/AGGIORNAMENTO: benché abbia risolto con teamviewer, visto che sto aspettando il corriere con la nuova scheda, ho deciso di provare a guarda IPv6. Sembra interessante ma: tunnelbroker.net richiede i pacchetti ICMP. Il nat di H3G (sim con superinternet) blocca i pacchetti ICMP. Sto guardando altri tunnel che non richiedano l'ICMP e che abbiano l'autoupdate con autodetect per gli ip dinamici. (tunnelbroker.net lo fa tramite link, quindi basterebbe far partire il browser all'avvio) |
|
|
|
|
Show Posts
