Planet 3DNow! Distributed Computing Wiki - Benutzerbeiträge [de]

Update.bat

2025-11-01T17:15:20Z

Enigmation: Typo

Bei manchen Projekten kommt man nicht umhin, bei der Workunit-Anforderung nachzuhelfen.

Dies erfolgt am einfachsten mit einer ausführbaren Datei, oder im Falle von Linux, mit einer Komandozeile.

=== Windows ===

Den Texteditor öffnen und folgenden Inhalt, hier beispielhaft für das Projekt TN-Grid, einfügen: 
<nowiki>
cls
:START
echo off
time /t
timeout 122
"C:\Programme\Boinc\boinccmd.exe" --project http://gene.disi.unitn.it/test/ update
GOTO START </nowiki>
Danach die Datei mit dem Namen "Update.bat" im Verzeichnis: C:\ProgramData\BOINC\ abspeichern. 

Darauf achten, dass die Datei nicht "Update.bat.'''txt'''" heißt. 

Datei mit Doppelklick starten, beenden mit Strg+C und mit j bestätigen. 

Mit Rechtsklick läßt sich natürlich auch eine Verknüpfung anlegen. 

Die Zahl hinter "timeout" ist in Sekunden, wie lange pausiert werden soll, bis die nächste Anfrage ans Projekt erfolgt.

Diese Zeitspanne ist von Projekt zu Projekt unterschiedlich.

Sollte der Upload hängen, kann mit dieser weiteren Zeile der Upload erneut angestoßen werden:
<nowiki>"C:\Programme\Boinc\boinccmd.exe" --network_available </nowiki>

Wer mit Instanzen arbeitet, nimmt folgendes, und paßt es an:
<nowiki>
@echo off
cls
:START
"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9001 --passwd p3d --network_available
"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9001 --passwd p3d --project http://gene.disi.unitn.it/test/ update

"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9002 --passwd p3d --network_available
"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9002 --passwd p3d --project http://gene.disi.unitn.it/test/ update

time /t
timeout 15
GOTO START
</nowiki>

Wenn mehrere Rechner und Instanzen verwendet werden, reicht es aus, dass eine einzige update.bat für alle Rechner und Instanzen arbeitet.

== Powershell-Skript ==
Als Datei ''update.ps1'' abgespeichert und dann Rechtsklick auf die Datei und ''Mit Powershell ausführen'':
<nowiki>
$DLY=190 #project delay
$PEN=30 #penetration interval
$KYW='downloading' #keyword in tasklist
$PRJ='http://www.worldcommunitygrid.org/' #project url
$PBC='C:\Program Files\BOINC\boinccmd.exe' #path to boinc+command
Do{$D = (Get-Date).ToString("dd.MM.yyyy HH:mm:ss :") #timestamp
.$PBC --network_available
.$PBC --project $PRJ update time /t
$M = .$PBC --get_tasks | Select-String -Pattern $KYW
if ($M.Count -gt 0) {
Write-Host "$D Naechster Versuch in $PEN Sekunden fuer $PRJ"
timeout $PEN
}
else { Write-Host "$D Auf Arbeit warten! Verzoegerung: $DLY Sekunden in Projekt $PRJ"
timeout $DLY
}
}
Until (0)
</nowiki>

=== Linux ===

Konsole im Verzeichnis: /var/lib/boinc-client/ mit Strg+Alt+T öffnen und folgenden Inhalt, hier beispielhaft für das Projekt TN-Grid, einfügen: 

<nowiki>while true; do boinccmd --project http://gene.disi.unitn.it/test/ update; sleep 122; done</nowiki>

Wer mit Instanzen arbeitet, braucht nur --host 127.0.0.1:xxxx einsetzen. Die xxxx stehen für den Namen der Instanz.
Im folgendem Beispiel hat die Instanz die laufende Nummer 31417. Das Passwort anpassen nach Inhalt der [[Instanzen anlegen + verwalten|gui_rpc_auth.cfg]]

<nowiki>while true; do boinccmd --host 127.0.0.1:31417 --passwd p3d --project http://gene.disi.unitn.it/test/ update; sleep 122; done</nowiki>

In nicht nachvollziehbaren Fällen, kann die Fehlermeldung 'Authorization failure: -155' erscheinen, wenn in der Datei gui_rpc_auth.cfg kein Passwort hinterlegt ist. Der Fehler läßt sich mit zwei Anführungszeichen wie folgt beheben:

<nowiki>while true; do boinccmd --host 127.0.0.1:31417 --passwd '' --project http://gene.disi.unitn.it/test/ update; sleep 122; done</nowiki>

Mit Enter ausführen, und mit Strg+C beenden. 

Der Eintrag hinter "sleep" ist analog zu "timeout".

Gridcoin

2024-10-12T10:52:23Z

Enigmation: Die Seite wurde neu angelegt: „<big>Gridcoin</big> <big>Umzug der GridCoin-Wallet auf einen anderen Rechner</big> Umzug Wallet auf anderen Rechner # GridCoin(GC) Wallet auf dem anderen…“

<big>Gridcoin</big>

<big>Umzug der GridCoin-Wallet auf einen anderen Rechner</big>

Umzug Wallet auf anderen Rechner
# GridCoin(GC) Wallet auf dem anderen Rechner frisch installiert, die blockchain syncen lassen und dann GC beenden.
# Backup der Wallet- und der Konfigurationsdatei auf dem alten Rechner. GC beenden!
# Gesicherte Wallet + Konfig Datei des alten Rechners auf dem neuen Rechner einspielen. Email Adresse, die in den BOINC Accounts verwendet wird, in der Konfig Datei zufügen. Zeile: email=m.mustermann@mm.de
# GC auf dem neuen Rechner starten. Es sollte jetzt alles laufen.
# Den alten Rechner ausschalten und am besten auch GC deinstallieren oder nur GC deinstallieren.

Sollte der GC auf zwei oder mehr Rechnern laufen wird man irgendwann gebannt!

Update.bat

2022-09-24T21:59:09Z

Enigmation: Powershell-Skript von Emploi eingefügt

Bei manchen Projekten kommt man nicht umhin, bei der Workunit-Anforderung nachzuhelfen.

Dies erfolgt am einfachsten mit einer ausführbaren Datei, oder im Falle von Linux, mit einer Komandozeile.

=== Windows ===

Den Texteditor öffnen und folgenden Inhalt, hier beispielhaft für das Projekt TN-Gird, einfügen: 
<nowiki>
cls
:START
echo off
time /t
timeout 122
"C:\Programme\Boinc\boinccmd.exe" --project http://gene.disi.unitn.it/test/ update
GOTO START </nowiki>
Danach die Datei mit dem Namen "Update.bat" im Verzeichnis: C:\ProgramData\BOINC\ abspeichern. 

Darauf achten, dass die Datei nicht "Update.bat.'''txt'''" heißt. 

Datei mit Doppelklick starten, beenden mit Strg+C und mit j bestätigen. 

Mit Rechtsklick läßt sich natürlich auch eine Verknüpfung anlegen. 

Die Zahl hinter "timeout" ist in Sekunden, wie lange pausiert werden soll, bis die nächste Anfrage ans Projekt erfolgt.

Diese Zeitspanne ist von Projekt zu Projekt unterschiedlich.

Sollte der Upload hängen, kann mit dieser weiteren Zeile der Upload erneut angestoßen werden:
<nowiki>"C:\Programme\Boinc\boinccmd.exe" --network_available </nowiki>

Wer mit Instanzen arbeitet, nimmt folgendes, und paßt es an:
<nowiki>
@echo off
cls
:START
"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9001 --passwd p3d --network_available
"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9001 --passwd p3d --project http://gene.disi.unitn.it/test/ update

"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9002 --passwd p3d --network_available
"%ProgramFiles%\BOINC\boinccmd.exe" --host 127.0.0.1:9002 --passwd p3d --project http://gene.disi.unitn.it/test/ update

time /t
timeout 15
GOTO START
</nowiki>

Wenn mehrere Rechner und Instanzen verwendet werden, reicht es aus, dass eine einzige update.bat für alle Rechner und Instanzen arbeitet.

== Powershell-Skript ==
Als Datei ''update.ps1'' abgespeichert und dann Rechtsklick auf die Datei und ''Mit Powershell ausführen'':
<nowiki>
$DLY=190 #project delay
$PEN=30 #penetration interval
$KYW='downloading' #keyword in tasklist
$PRJ='http://www.worldcommunitygrid.org/' #project url
$PBC='C:\Program Files\BOINC\boinccmd.exe' #path to boinc+command
Do{$D = (Get-Date).ToString("dd.MM.yyyy HH:mm:ss :") #timestamp
.$PBC --network_available
.$PBC --project $PRJ update time /t
$M = .$PBC --get_tasks | Select-String -Pattern $KYW
if ($M.Count -gt 0) {
Write-Host "$D Naechster Versuch in $PEN Sekunden fuer $PRJ"
timeout $PEN
}
else { Write-Host "$D Auf Arbeit warten! Verzoegerung: $DLY Sekunden in Projekt $PRJ"
timeout $DLY
}
}
Until (0)
</nowiki>

=== Linux ===

Konsole im Verzeichnis: /var/lib/boinc-client/ mit Strg+Alt+T öffnen und folgenden Inhalt, hier beispielhaft für das Projekt TN-Grid, einfügen: 

<nowiki>while true; do boinccmd --project http://gene.disi.unitn.it/test/ update; sleep 122; done</nowiki>

Wer mit Instanzen arbeitet, braucht nur --host 127.0.0.1:xxxx einsetzen. Die xxxx stehen für den Namen der Instanz.
Im folgendem Beispiel hat die Instanz die laufende Nummer 31417. Das Passwort anpassen nach Inhalt der [[Instanzen anlegen + verwalten|gui_rpc_auth.cfg]]

<nowiki>while true; do boinccmd --host 127.0.0.1:31417 --passwd p3d --project http://gene.disi.unitn.it/test/ update; sleep 122; done</nowiki>

Mit Enter ausführen, und mit Strg+C beenden. 

Der Eintrag hinter "sleep" ist analog zu "timeout".

Update.bat

2022-05-18T08:40:23Z

Enigmation:

Update.bat

2022-05-18T08:35:40Z

Enigmation:

ClimatePrediction.net

2022-01-15T14:31:38Z

Enigmation: /* Teilnahme */

{| {{Steckbrief}}
|-
| {{Steckbrief Kategorie|Meteorologie}}
|-
| {{Steckbrief Betreiber|University of Oxford}}
|-
| {{Steckbrief Nationalität|Großbritannien|uk}}
|-
| {{Steckbrief Start|September 2003 (BOINC: August 2004)}}
|-
| {{Steckbrief Status|Stabil}}
|-
| {{Steckbrief Webseite|URL=http://climateapps2.oucs.ox.ac.uk/cpdnboinc/|Name=climateapps2.oucs.ox.ac.uk/cpdnboinc/}}
|-
| {{Steckbrief Webseite|URL=http://cpdnbeta.oerc.ox.ac.uk/|Name=cpdnbeta.oerc.ox.ac.uk|Typ=Beta}}
|-
| {{Steckbrief Anmeldung|URL=http://climateprediction.net/}}
|-
| {{Steckbrief Anmeldung|URL=http://cpdnbeta.oerc.ox.ac.uk/|Typ=Beta}}
|-
| {{Steckbrief Clients Systeme}}
|-
| {{Steckbrief Clients Architektur|x86|x|x|x|?|-}}
|-
| {{Steckbrief Clients Architektur|x86-64|-|-|x|-|-}}
|-
| {{Steckbrief P3D-Statistik|URL=http://climateapps2.oucs.ox.ac.uk/cpdnboinc/team_display.php?teamid=91}}
|-
| {{Steckbrief P3D-Statistik|URL=http://cpdnbeta.oerc.ox.ac.uk/team_display.php?teamid=37|Typ=Beta}}
|-
| {{Steckbrief P3D-Statistik Live|Name=Climate Prediction}}
|}

'''ClimatePrediction.net''' ist ein Projekt der University of Oxford. Es simuliert mit verschiedenen Klimamodellen das Wetter von 1950 bis in die Neuzeit um "gute" Modelle zu finden. In einer weiteren Phase wird mit diesen Modellen das Klima bis 2050 simuliert.

== Projektbeschreibung ==

TODO

== Erfolge des Projekts ==

TODO: Hier sollte auf bisher erzielte Erfolge und veröffentlichte Arbeiten des Projekts eingegangen werden.

== Planet 3DNow! ==

Planet 3DNow! nimmt seit dem 05.11.2003 mit einem eigenen Team an ClimatePrediction.net teil. Seit dem 30.07.2007 ist Planet 3DNow! auch beim ClimatePrediction.net Betatest vertreten.

TODO: Hier sollte auf unser Team bei diesem Projekt eingegangen werden.

== Teilnahme ==
'''Hinweise zu Installation und Konfiguration:''' 

Es gibt nur selten Workunits für Windows, dagegen gibt es fortlaufend für Linux neue Arbeit. Allerdings ist zu beachten, dass die Anwendungen noch 32bit-kompiliert sind und daher die 32-Bit Unterstützung in den aktuellen 64bit-Linuxen häufig erst noch nachgerüstet werden muss. Siehe dazu im climateprediction-Forum 

https://www.cpdn.org/forum_thread.php?id=7828 

https://www.cpdn.org/forum_thread.php?id=8916

== Banner ==

[[Bild:Banner CP.png]]

[[Bild:Banner CP2.png]]

[[Bild:Banner_CP_BETA.png]]

== Weblinks ==

* [http://climateapps2.oucs.ox.ac.uk/cpdnboinc/ climateapps2.oucs.ox.ac.uk/cpdnboinc/] - Internetpräsenz des Projekts
* [http://cpdnbeta.oerc.ox.ac.uk/ cpdnbeta.oerc.ox.ac.uk] - Internetpräsenz des Betatests
* [http://climateapps2.oucs.ox.ac.uk/cpdnboinc/team_display.php?teamid=91 Planet 3DNow! Teamstatistik]
* [http://cpdnbeta.oerc.ox.ac.uk/team_display.php?teamid=37 Planet 3DNow! Teamstatistik] (ClimatePrediction.net Beta)

{{NaviBlock
|Vorlage:Navigationsleiste BOINC
|Navigationsleiste Nicht-BOINC
}}

[[Kategorie:Meteorologie]]
[[Kategorie:BOINC-Projekt]]
[[Kategorie:Planet 3DNow! Team]]

Client state.xml

2021-06-30T10:45:41Z

Enigmation:

Im Abschnitt [[Boinc Scheduler|Boinc Scheduler]] wird u.a. auf die grundsätzliche Funktion der client_state.xml-Datei eingegangen.

An dieser Stelle greifen wir einige Zeilen dieser Datei auf, um deren Bedeutung zu erklären, und durch gezieltes Ändern der Einträge, Nutzen daraus zu ziehen.

Abgelegt ist die Datei unter Windows im Verzeichnis C:\ProgramData\BOINC\client_state.xml

Unter Linux liegt sie im Verzeichnis /var/lib/boinc-client/client_state.xml

Abhängig bei wievielen Projekten der Boinc-Manager angemeldet ist, ist auch der Umfang des Inhaltes.
Das ist Wichtig zu beachten, damit auch im richtigen Abschnitt die gewünschte Änderung vorgenommen wird.

Änderungen an der Datei lassen sich nur bei beendetem Boinc-Manager vornehmen. Änderungen im laufenden Betrieb, lassen sich endweder nicht abspeichern, oder werden vom System wieder überschrieben.

Anfangen wollen wir mit zwei Einträgen, die gleich mal grundsätzlich immer geändert werden können.

===<on_frac> und <active_frac>===

Über die Einträge <on_frac> und <active_frac> weiß das Projekt, wie lange der Boinc-Client mit ihm bereits verbunden ist.
Um so höher dieser Wert ist, um so schneller werden dem Client WUs zugewiesen. Der maximale Wert muß < 1 sein.
Die beiden Zeilen befinden sich im Abschnitt <time_stats>. Als Beispiel:

<time_stats>
<on_frac>0.99</on_frac>
<active_frac>0.99</active_frac>
</time_stats>

===<duration_correction_factor>===

Beim nächsten Eintrag den wir verändern wollen, geht es um die vermutete Berechnungsdauer pro Workunit (WU).
In Abhängigkeit der Berechnungsdauer pro WU, und dem eingestellten Wert im Boinc-Manger bezüglich der Arbeitszeit, für die wir WUs haben wollen, errechnet der Projektserver die Menge an WUs, die runtergeladen werden können.
Auf dem Projektserver ist diese Berechnungszeit abgelegt, und bezieht sich in der Regel auf die Zeit, die der Projektserver benötigt hat. Dieser Wert unterscheidet sich natürlich vom eingenen System.
Mit jeder gerechneten und zurück gesendeten WU, wird der Wert angeglichen, und es können bezogen auf die eingestellte Arbeitszeit, mehr WUs auf den eigenen Rechner runtergeladen werden.
Um diesen Vorgang abzukürzen, gehen wir in der client_state.xml in den Projektabschnitt, deren Wert wir ändern wollen.

Im Beispielfall soll das der Projektabschnitt von Einstein@home sein:

<project>
<master_url>http://einstein.phys.uwm.edu/</master_url>
<project_name>Einstein@Home</project_name>
....
<duration_correction_factor>'''0.282786'''</duration_correction_factor>
....
</project>

Hier ist bereits der tatsächliche Wert vorhanden. Bei der Neuanmeldung beim Projekt, steht hier eine Zahl < 0.999999.
Der Wert oben steht für die Berechnungszeit einer CPU-WU. Der Wert für eine GPU-WU ist in der Regel < 0,010000.

===Hochladen ohne Fertigmeldung===
Anstatt sperren der IP bzw. des DNS-Namens via [[hosts-Einträge]] kann auch nur die Scheduler-URL gesperrt werden. Dies ist auch die einzige Lösung, das hochladen vom melden zu trennen, wenn das Projekt nur einen einzigen Server besitzt, der Scheduler also den gleichen DNS-Namen bzw. IP wie die Webseite des Projekts hat.

So kann das Hochladen ohne Fertigmeldung in der client state.xml eingerichtet werden:

In dieser Reihenfolge zum bunkern und hochladen ohne melden:

# mit WUs je Instanz vollladen
# BM bzw. Instanz beenden
# client_state.xml editieren und Wert von <scheduler_url> ändern auf eine nicht existente URL
# BM bzw. Instanz starten und rechnen lassen
[[Datei:1621414547470.png|mini]]
[[Datei:1621414594879.png|mini]]

Und in dieser Reihenfolge zum melden:

# BM bzw. Instanz beenden
# client_state.xml editieren und Wert von <scheduler_url> auf den Originalwert zurückändern
# BM bzw. Instanz starten und Projekt aktualisieren
[[Datei:1621427921183.png|mini]]

Radioactive@Home

2021-06-17T06:17:08Z

Enigmation: /* Teilnahme */

{| {{Steckbrief}}
|-
| {{Steckbrief Kategorie|Physik}}
|-
| {{Steckbrief Betreiber|BOINC@Poland Team}}
|-
| {{Steckbrief Nationalität|Polen|pl}}
|-
| {{Steckbrief Start|April 2011}}
|-
| {{Steckbrief Status|Alpha}}
|-
| {{Steckbrief Checkpoints|?}}
|-
| {{Steckbrief Webseite|URL=http://radioactiveathome.org/en/|Name=radioactiveathome.org/en/}}
|-
| {{Steckbrief Anmeldung|URL=http://radioactiveathome.org/boinc/}}
|-
| {{Steckbrief Clients Systeme}}
|-
| {{Steckbrief Clients Architektur|x86|x|x|-|-|-}}
|-
| {{Steckbrief P3D-Statistik|URL=http://radioactiveathome.org/boinc/team_display.php?teamid=225}}
|-
| {{Steckbrief P3D-Statistik Live|Name=Radioactive@Home}}
|}

{{Stub Artikel|Einleitung, Beschreibung, Erfolge, Teilnahme}}

'''Radioactive@Home''' ist ein polnisches Projekt unter '''BOINC'''. Das Hauptziel des Projektes ist es, durch Sammeln von Informationen über Gamma-Strahlung mit Hilfe von Sensoren freie und ständig aktualisierte Karten von Strahlung zu schaffen. Das Project ist nicht-kommerziell, die Software wird unter der GNU General Public License (GPL) lizenziert werden.

== Projektbeschreibung ==

== Erfolge des Projekts ==

== Planet 3DNow! ==

Planet 3DNow! nimmt seit dem 16.06.2011 mit einem eigenen Team an Radioactive@Home teil.

==Teilnahme==
Die Teilnahme ist nur mit einem Sensormodul (30-33€, Stand 2019) möglich.

== Banner ==

== Weblinks ==

* [http://radioactiveathome.org/boinc/ Internetpräsenz des Projekts]
* [http://radioactiveathome.org/boinc/team_display.php?teamid=225 Planet 3DNow! Teamstatistik]

{{NaviBlock
|Vorlage:Navigationsleiste BOINC
|Navigationsleiste Nicht-BOINC
}}

[[Kategorie:Physik]]
[[Kategorie:BOINC-Projekt]]
[[Kategorie:Planet 3DNow! Team]]

Client state.xml

2021-05-21T06:36:25Z

Enigmation: /* Hochladen ohne Fertigmeldung */

Im Abschnitt [[Boinc Scheduler|Boinc Scheduler]] wird u.a. auf die grundsätzliche Funktion der client_state.xml-Datei eingegangen.

An dieser Stelle greifen wir einige Zeilen dieser Datei auf, um deren Bedeutung zu erklären, und durch gezieltes Ändern der Einträge, Nutzen daraus zu ziehen.

Abgelegt ist die Datei unter Windows im Verzeichnis C:\ProgrammData\BOINC\client_state.xml

Unter Linux liegt sie im Verzeichnis /var/lib/boinc-client/client_state.xml

Abhängig bei wievielen Projekten der Boinc-Manager angemeldet ist, ist auch der Umfang des Inhaltes.
Das ist Wichtig zu beachten, damit auch im richtigen Abschnitt die gewünschte Änderung vorgenommen wird.

Änderungen an der Datei lassen sich nur bei beendetem Boinc-Manager vornehmen. Änderungen im laufenden Betrieb, lassen sich endweder nicht abspeichern, oder werden vom System wieder überschrieben.

Anfangen wollen wir mit zwei Einträgen, die gleich mal grundsätzlich immer geändert werden können.

===<on_frac> und <active_frac>===

Über die Einträge <on_frac> und <active_frac> weiß das Projekt, wie lange der Boinc-Client mit ihm bereits verbunden ist.
Um so höher dieser Wert ist, um so schneller werden dem Client WUs zugewiesen. Der maximale Wert muß < 1 sein.
Die beiden Zeilen befinden sich im Abschnitt <time_stats>. Als Beispiel:

<time_stats>
<on_frac>0.99</on_frac>
<active_frac>0.99</active_frac>
</time_stats>

===<duration_correction_factor>===

Beim nächsten Eintrag den wir verändern wollen, geht es um die vermutete Berechnungsdauer pro Workunit (WU).
In Abhängigkeit der Berechnungsdauer pro WU, und dem eingestellten Wert im Boinc-Manger bezüglich der Arbeitszeit, für die wir WUs haben wollen, errechnet der Projektserver die Menge an WUs, die runtergeladen werden können.
Auf dem Projektserver ist diese Berechnungszeit abgelegt, und bezieht sich in der Regel auf die Zeit, die der Projektserver benötigt hat. Dieser Wert unterscheidet sich natürlich vom eingenen System.
Mit jeder gerechneten und zurück gesendeten WU, wird der Wert angeglichen, und es können bezogen auf die eingestellte Arbeitszeit, mehr WUs auf den eigenen Rechner runtergeladen werden.
Um diesen Vorgang abzukürzen, gehen wir in der client_state.xml in den Projektabschnitt, deren Wert wir ändern wollen.

Im Beispielfall soll das der Projektabschnitt von Einstein@home sein:

<project>
<master_url>http://einstein.phys.uwm.edu/</master_url>
<project_name>Einstein@Home</project_name>
....
<duration_correction_factor>'''0.282786'''</duration_correction_factor>
....
</project>

Hier ist bereits der tatsächliche Wert vorhanden. Bei der Neuanmeldung beim Projekt, steht hier eine Zahl < 0.999999.
Der Wert oben steht für die Berechnungszeit einer CPU-WU. Der Wert für eine GPU-WU ist in der Regel < 0,010000.

===Hochladen ohne Fertigmeldung===
Anstatt sperren der IP bzw. des DNS-Namens via [[hosts-Einträge]] kann auch nur die Scheduler-URL gesperrt werden. Dies ist auch die einzige Lösung, das hochladen vom melden zu trennen, wenn das Projekt nur einen einzigen Server besitzt, der Scheduler also den gleichen DNS-Namen bzw. IP wie die Webseite des Projekts hat.

So kann das Hochladen ohne Fertigmeldung in der client state.xml eingerichtet werden:

In dieser Reihenfolge zum bunkern und hochladen ohne melden:

# mit WUs je Instanz vollladen
# BM bzw. Instanz beenden
# client_state.xml editieren und Wert von <scheduler_url> ändern auf eine nicht existente URL
# BM bzw. Instanz starten und rechnen lassen
[[Datei:1621414547470.png|mini]]
[[Datei:1621414594879.png|mini]]

Und in dieser Reihenfolge zum melden:

# BM bzw. Instanz beenden
# client_state.xml editieren und Wert von <scheduler_url> auf den Originalwert zurückändern
# BM bzw. Instanz starten und Projekt aktualisieren
[[Datei:1621427921183.png|mini]]

Datei:1621427921183.png

2021-05-21T06:35:56Z

Enigmation:

BM mit NFS: Hochgeladen und gemeldet

Datei:1621414594879.png

2021-05-21T06:35:07Z

Enigmation:

BM mit NFS: Hochgeladen, meldebereit

Datei:1621414547470.png

2021-05-21T06:34:18Z

Enigmation:

BM mit NFS: Hochgeladen, Scheduler Request failed

Client state.xml

2021-05-21T06:28:13Z

Enigmation: /* Hochladen ohne Fertigmeldung */

Im Abschnitt [[Boinc Scheduler|Boinc Scheduler]] wird u.a. auf die grundsätzliche Funktion der client_state.xml-Datei eingegangen.

An dieser Stelle greifen wir einige Zeilen dieser Datei auf, um deren Bedeutung zu erklären, und durch gezieltes Ändern der Einträge, Nutzen daraus zu ziehen.

Abgelegt ist die Datei unter Windows im Verzeichnis C:\ProgrammData\BOINC\client_state.xml

Unter Linux liegt sie im Verzeichnis /var/lib/boinc-client/client_state.xml

Abhängig bei wievielen Projekten der Boinc-Manager angemeldet ist, ist auch der Umfang des Inhaltes.
Das ist Wichtig zu beachten, damit auch im richtigen Abschnitt die gewünschte Änderung vorgenommen wird.

Änderungen an der Datei lassen sich nur bei beendetem Boinc-Manager vornehmen. Änderungen im laufenden Betrieb, lassen sich endweder nicht abspeichern, oder werden vom System wieder überschrieben.

Anfangen wollen wir mit zwei Einträgen, die gleich mal grundsätzlich immer geändert werden können.

===<on_frac> und <active_frac>===

Über die Einträge <on_frac> und <active_frac> weiß das Projekt, wie lange der Boinc-Client mit ihm bereits verbunden ist.
Um so höher dieser Wert ist, um so schneller werden dem Client WUs zugewiesen. Der maximale Wert muß < 1 sein.
Die beiden Zeilen befinden sich im Abschnitt <time_stats>. Als Beispiel:

<time_stats>
<on_frac>0.99</on_frac>
<active_frac>0.99</active_frac>
</time_stats>

===<duration_correction_factor>===

Beim nächsten Eintrag den wir verändern wollen, geht es um die vermutete Berechnungsdauer pro Workunit (WU).
In Abhängigkeit der Berechnungsdauer pro WU, und dem eingestellten Wert im Boinc-Manger bezüglich der Arbeitszeit, für die wir WUs haben wollen, errechnet der Projektserver die Menge an WUs, die runtergeladen werden können.
Auf dem Projektserver ist diese Berechnungszeit abgelegt, und bezieht sich in der Regel auf die Zeit, die der Projektserver benötigt hat. Dieser Wert unterscheidet sich natürlich vom eingenen System.
Mit jeder gerechneten und zurück gesendeten WU, wird der Wert angeglichen, und es können bezogen auf die eingestellte Arbeitszeit, mehr WUs auf den eigenen Rechner runtergeladen werden.
Um diesen Vorgang abzukürzen, gehen wir in der client_state.xml in den Projektabschnitt, deren Wert wir ändern wollen.

Im Beispielfall soll das der Projektabschnitt von Einstein@home sein:

<project>
<master_url>http://einstein.phys.uwm.edu/</master_url>
<project_name>Einstein@Home</project_name>
....
<duration_correction_factor>'''0.282786'''</duration_correction_factor>
....
</project>

Hier ist bereits der tatsächliche Wert vorhanden. Bei der Neuanmeldung beim Projekt, steht hier eine Zahl < 0.999999.
Der Wert oben steht für die Berechnungszeit einer CPU-WU. Der Wert für eine GPU-WU ist in der Regel < 0,010000.

===Hochladen ohne Fertigmeldung===
Anstatt sperren der IP bzw. des DNS-Namens via [[hosts-Einträge]] kann auch nur die Scheduler-URL gesperrt werden. Dies ist auch die einzige Lösung, das hochladen vom melden zu trennen, wenn das Projekt nur einen einzigen Server besitzt, der Scheduler also den gleichen DNS-Namen bzw. IP wie die Webseite des Projekts hat.

So kann das Hochladen ohne Fertigmeldung in der client state.xml eingerichtet werden:

In dieser Reihenfolge zum bunkern und hochladen ohne melden:

# mit WUs je Instanz vollladen
# BM bzw. Instanz beenden
# client_state.xml editieren und Wert von <scheduler_url> ändern auf eine nicht existente URL
# BM bzw. Instanz starten und rechnen lassen

Und in dieser Reihenfolge zum melden:

# BM bzw. Instanz beenden
# client_state.xml editieren und Wert von <scheduler_url> auf den Originalwert zurückändern
# BM bzw. Instanz starten und Projekt aktualisieren

Update.bat

2021-05-19T07:53:06Z

Enigmation: Uploadhilfe hinzugefügt

Boinc Scheduler

2021-05-19T07:46:07Z

Enigmation: /* direkte Manipulation client_state.xml */

Der Boinc Scheduler ist zuständig zum Abarbeiten der Projekte gemäß der eingestellten Ressourcen Anteile.

== Ressourcenanteil ==
Diese können von 1% bis 1000% eingestellt werden, stellen jedoch keine echten % Anteile dar. Die Summe der eingestellten Ressourcen aller Projekte entspricht dann dem Nenner, die Ressource des Projekts dem Zähler.
Beispiel:

Projekt A ist auf 100% gesetzt; Projekt B ist auf 50% gesetzt; Projekt C ist auf 250% gesetzt -> A+B+C = 400

Projekt A bekommt 100/400 = 25%; Projekt B bekommt 50/400 = 12,5%; Projekt C bekommt 250/400 = 62,5%

Ohne die zusätzlichen Faktoren bedeutet diese, das Projekt C 2,5x mehr gerechnet wird als Projekt A, welches jedoch 2x mehr als Projekt B gerechnet wird.

== Boinc Zeit Statistik ==
Boinc speichert in der client_state.xml unter dem abschnitt <time_stats> den Anteil in denen Boinc gestartet und aktiv ist.
<time_stats>
<on_frac>0.XXX</on_frac>
<active_frac>0.XXX</active_frac>
</time_stats>

Der Wert <on_frac> ist der Zeitanteil seit dem Boinc installiert wurde im Verhältnis zur Laufzeit des Boinc Clients, unabhängig davon ob er Berechnungen durchführt oder angehalten ist, sprich pausiert.

Beispiel: Boinc wurde vor genau 14 Tagen (14x24h) installiert, in dieser Zeit wurde der PC mit Boinc als Service Installation (Boinc startet automatisch mit dem OS) immer 8h lang eingeschaltet (10x8h). Dies ergibt 80 / 336 = <on_frac>0.238095238</on_frac> = ~24% Laufzeit des Boinc Clients

Der Wert <active_frac> ist der Zeitanteil seit dem Boinc installiert wurde im Verhältnis zur aktiven Laufzeit des Boinc Clients, also die Zeit in der WUs abgearbeitet/berechnet werden.

Beispiel: Boinc wurde vor genau 14 Tagen (14x24h) installiert, in dieser Zeit wurde der PC mit Boinc als Service Installation (Boinc startet automatisch mit dem OS) immer 8h lang eingeschaltet und davon durfte 4h am Tag der Boinc Client seine Berechnungen durch führen. Dies ergibt 40 / 336 = <active_frac>0.119047619</active_frac> = ~12% aktive Laufzeit des Boinc Clients, in der Berechnungen durchgeführt wurden.

== STD und LTD Wert ==
Boinc speichert in der client_state.xml unter dem abschnitt <project> den jeweiligen Anteil in denen Boinc die Projekte rechnen lässt / aktiv ist.
<project>
<short_term_debt>XXX</short_term_debt>
<long_term_debt>XXX</long_term_debt>
</project>

Der Wert <short_term_debt>, übersetzbar mit "Kurzzeit Schuld" liegt im Bereich von 0-86400 (Sekunden/Tag). Dieser Werte soll die Abarbeitung der WUs im Zeitraum <24h gewährleisten. Beim nächsten Umschalten gemäß der Ressourcenaufteilung wird das Projekt mit dem höchsten <short_term_debt> Wert bevorzugt. Es zeigt sozusagen die Schuld des Clients bei den jeweiligen Projekt/24h an. Ist der Wert 0 hat Boinc seine Arbeit, gemäß der Ressorcen einstellung geleistet.

Der Wert <long_term_debt>, übersetzbar mit "Langzeit Schuld" liegt im Bereich von +-1000000 Sekunden. Dieser ist einer der Faktoren zur WU Anforderung durch Boinc bei dem entsprechenden Projekt. Bei einem negativen Wert wird keine Arbeit angefordert. Boinc hat "zuviel" an diesen Projekt gemäß Ressourcen einstellung gerechnet. Bei einem positiven Wert, wird je nach Höhe und Ressourcenanteil Arbeit angefordert unter Berücksichtigung des <active_frac> Wertes. Stehen die Werte alle im negativen Bereich, so erscheint unter Meldungen overcomitted und no new work fetch allowed. Boinc ist dann überarbeitet (overcomitted) und fordert keine neuen WUs (no new work fetch allowed). Dieser Modus wird dann auch earliest-deadline-first (EDF) genannt.

== EDF (Panik) Modus ==

Neben den genannten Werten, beachtet Boinc auch die Deadline der WUs. Wenn es merkt das es "zuviel" Arbeit angefordert hat oder der
<active_frac> Wert sinkt (Urlaub -> PC ist mehr aus, es wird mehr gearbeitet -> Boinc darf weniger rechnen) werden die WUs mit der nächsten Deadline bevorzugt gerechnet um ein "brauchbares" Ergebnis zu gewährleisten. In dieser Zeit fordert Boinc keine Arbeit mehr an. Mittlerweile prüfen auch die Projekt Server die Zeitstatistiken und verweigern die Zuteilung von WUs, wenn gemäß der Werte, in der geforderten Zeit nicht berechnet werden können.
Beispiel:
Message from server: No work sent
(won't finish in time) Computer on 50% of time, BOINC on 25% of that, this project gets 20% of that
No work from project
Der Server sagt damit, das der PC 50% der Zeit an ist, 25% davon Boinc rechnen darf und das Projekt von dieser Zeit 20% nur bekommt.

== Problem "No work sent" Lösungen ==
Nachfolgend verschieden Möglichkeiten um an Wus zu kommen, obwohl Boinc keine "will" bzw. bekommt.

==== Verhaltensänderung ====
Es ist einfacher als man denkt und auch logisch: Mehr Rechenleistung gibt mehr Arbeit :-)
Sofern der PC leistungsfähig genug ist, kann man den Client einstellen, das er immer arbeitet, auch wenn der PC in Nutzung ist. Wenn Boinc dabei die normale Arbeit am PC stört, kann man z.B. über die Werte:
On multiprocessors, use at most (< Version 5.10) X processors
On multiprocessors, use at most (> Version 6.1) X % of the processors
Use at most (> Version 5.6) X percent of CPU time
Boinc "begrenzen". Genauer Erklärung dazu siehe [[http://dc.planet3dnow.de/wiki/index.php?title=Portal:BOINC/Konfiguration|BOINC Konfiguration]]
Der weitergehende Weg währe den PC "durchlaufen" zulassen, ist der PC mehr an steigen die Werte <on_frac> und <active_frac> von alleine. Je nach dem wie stark die Nutzungsänderung über den Zeitraum ist, kann das dauern. Zu Beachten ist dabei die stärker Belastung des PCs durch Boinc siehe dazu [[http://dc.planet3dnow.de/wiki/index.php?title=DC Nachteile|DC Nachteile]]

Der letzte Möglichkeit ist eine entsprechende Aufrüstung oder Übertaktung der Hardware, bitte auf eigene Gefahr und/oder Kosten achten.

==== manuelle Steuerung der Projekt ====
Boinc macht einen Unterschied zwischen Projekt "Anhalten" und "Keine neuen Aufgabe". Bei Anhalten wird das Projekt Pausiert und die "Kurzzeit Schuld" wird weiter aufsummiert. Wenn das Projekt keine neuen Aufgaben rechnen darf, werden keine neuen Angefordert und der Wert der "Langzeit Schuld" wird nicht weiter geändert, nach Beendigung der verbleibenden WUs. Dementsprechend sollten alle Projekte die nicht berechnet werden sollen, auf "Keine neue Arbeit" gestellt werden und um den Vorgang zu beschleunigen alle nicht angefangenen WUs abgebrochen werden. Bereits angefangene WUs abzubrechen bedeutet die damit bisher geleistete Arbeit wegzuschmeißen und ist nicht empfohlen.
Es gibt einige Projekte (welche?) die abgebrochene WUs wieder zurücksenden, statt sie an andere Clients zu verteilen. In diesen Fall sollte man nach Senden der fertiggestellten WUs die Funktion "Zurücksetzen" verwenden. Alternativ kann man sich auch von den "unerwünschten" Projekten abmelden. Bei wieder Anmeldung wird der STD/LTD Wert auf 0 gesetzt.
Zu beachten ist bei Projekten mit kurzer Deadline, das der Arbeitspuffer (zusätzlicher + verbinde all X Tage) nicht grösser als die Deadline sein darf. Beispiel:
Projekt Deadline 7 Tage / Verbinden alle 1T / Zusätzlich 5T = 7>1+5 -> Server sendet WUs
Projekt Deadline 5 Tage / Verbinden alle 1T / Zusätzlich 5T = 5<1+5 -> Server sendet keine WUs
Man fordert sonst mehr Arbeit an als in der Zeit berechnet werden kann und damit automatisch über die Deadline überschreitet

==== direkte Manipulation client_state.xml ====
Durch direkte Änderung der entsprechenden Werte in der client_state.xml kann Boinc davon überzeugt werden WUs anzufordern. Dazu muss Boinc komplett beendet werden. Bei Installation als Service geht das ab Windows XP über den Befehl "net stop boinc" ("net start boinc" aktiviert den Service wieder).
Bei PCs die eher selten an sind, bzw. die aktive Zeit entsprechend gering war, ist als erstes empfehlenswert, die Werte <on_frac> und <active_frac> hochzusetzen. Beispiel:
<time_stats>
<on_frac>0.99</on_frac>
<active_frac>0.99</active_frac>
</time_stats>
Dabei ist zu beachten, dass nun Boinc denkt, 0.99 = 99% der Zeit laufen zu dürfen und in dieser Zeit auch 99% rechnen darf. Um ein Verfallen der WUs durch die Deadline zu vermeiden sollte, dann der PC auch die notwendige Zeit laufen, bzw. rechnen dürfen!

Um ein Projekt durch Manipulation der client_state.xml einen höherer Priorität zu geben sucht man in den entsprechenden <projekt> Abschnitt nach den Werten <short_term_debt> und <long_term_debt>und ändert sie entsprechend Beispiel:
<project>
<short_term_debt>85999</short_term_debt>
<long_term_debt>999999</long_term_debt>
</project>
Es ist zu empfehlen, an dieser Stelle nicht zu übertreiben und auch die Werte der anderen "unerwünschten" Projekte zu beachten. Am besten setzt man alle Werte auf 0 und lässt Boinc gemäß der Ressourcen bzw. Keine neuen Aufgaben entscheiden welches Projekt genommen werden soll. Einfacher sind diese Werte mit BoincDV zu manipulieren

==== BoincDV ====

== Weblinks ==

* [http://www.skipsjunk.net/info/boincdv.html Programmseite von BoincDV]
* [http://boinc.ssl.berkeley.edu/trac/wiki/ClientSched Detaillierte Erklärung auf Englisch, Clients vor 6.4.X]

[[Kategorie:BOINC]]

Boinc Scheduler

2021-05-19T07:42:30Z

Enigmation: /* direkte Manipulation client_state.xml */

Der Boinc Scheduler ist zuständig zum Abarbeiten der Projekte gemäß der eingestellten Ressourcen Anteile.

== Ressourcenanteil ==
Diese können von 1% bis 1000% eingestellt werden, stellen jedoch keine echten % Anteile dar. Die Summe der eingestellten Ressourcen aller Projekte entspricht dann dem Nenner, die Ressource des Projekts dem Zähler.
Beispiel:

Projekt A ist auf 100% gesetzt; Projekt B ist auf 50% gesetzt; Projekt C ist auf 250% gesetzt -> A+B+C = 400

Projekt A bekommt 100/400 = 25%; Projekt B bekommt 50/400 = 12,5%; Projekt C bekommt 250/400 = 62,5%

Ohne die zusätzlichen Faktoren bedeutet diese, das Projekt C 2,5x mehr gerechnet wird als Projekt A, welches jedoch 2x mehr als Projekt B gerechnet wird.

== Boinc Zeit Statistik ==
Boinc speichert in der client_state.xml unter dem abschnitt <time_stats> den Anteil in denen Boinc gestartet und aktiv ist.
<time_stats>
<on_frac>0.XXX</on_frac>
<active_frac>0.XXX</active_frac>
</time_stats>

Der Wert <on_frac> ist der Zeitanteil seit dem Boinc installiert wurde im Verhältnis zur Laufzeit des Boinc Clients, unabhängig davon ob er Berechnungen durchführt oder angehalten ist, sprich pausiert.

Beispiel: Boinc wurde vor genau 14 Tagen (14x24h) installiert, in dieser Zeit wurde der PC mit Boinc als Service Installation (Boinc startet automatisch mit dem OS) immer 8h lang eingeschaltet (10x8h). Dies ergibt 80 / 336 = <on_frac>0.238095238</on_frac> = ~24% Laufzeit des Boinc Clients

Der Wert <active_frac> ist der Zeitanteil seit dem Boinc installiert wurde im Verhältnis zur aktiven Laufzeit des Boinc Clients, also die Zeit in der WUs abgearbeitet/berechnet werden.

Beispiel: Boinc wurde vor genau 14 Tagen (14x24h) installiert, in dieser Zeit wurde der PC mit Boinc als Service Installation (Boinc startet automatisch mit dem OS) immer 8h lang eingeschaltet und davon durfte 4h am Tag der Boinc Client seine Berechnungen durch führen. Dies ergibt 40 / 336 = <active_frac>0.119047619</active_frac> = ~12% aktive Laufzeit des Boinc Clients, in der Berechnungen durchgeführt wurden.

== STD und LTD Wert ==
Boinc speichert in der client_state.xml unter dem abschnitt <project> den jeweiligen Anteil in denen Boinc die Projekte rechnen lässt / aktiv ist.
<project>
<short_term_debt>XXX</short_term_debt>
<long_term_debt>XXX</long_term_debt>
</project>

Der Wert <short_term_debt>, übersetzbar mit "Kurzzeit Schuld" liegt im Bereich von 0-86400 (Sekunden/Tag). Dieser Werte soll die Abarbeitung der WUs im Zeitraum <24h gewährleisten. Beim nächsten Umschalten gemäß der Ressourcenaufteilung wird das Projekt mit dem höchsten <short_term_debt> Wert bevorzugt. Es zeigt sozusagen die Schuld des Clients bei den jeweiligen Projekt/24h an. Ist der Wert 0 hat Boinc seine Arbeit, gemäß der Ressorcen einstellung geleistet.

Der Wert <long_term_debt>, übersetzbar mit "Langzeit Schuld" liegt im Bereich von +-1000000 Sekunden. Dieser ist einer der Faktoren zur WU Anforderung durch Boinc bei dem entsprechenden Projekt. Bei einem negativen Wert wird keine Arbeit angefordert. Boinc hat "zuviel" an diesen Projekt gemäß Ressourcen einstellung gerechnet. Bei einem positiven Wert, wird je nach Höhe und Ressourcenanteil Arbeit angefordert unter Berücksichtigung des <active_frac> Wertes. Stehen die Werte alle im negativen Bereich, so erscheint unter Meldungen overcomitted und no new work fetch allowed. Boinc ist dann überarbeitet (overcomitted) und fordert keine neuen WUs (no new work fetch allowed). Dieser Modus wird dann auch earliest-deadline-first (EDF) genannt.

== EDF (Panik) Modus ==

Neben den genannten Werten, beachtet Boinc auch die Deadline der WUs. Wenn es merkt das es "zuviel" Arbeit angefordert hat oder der
<active_frac> Wert sinkt (Urlaub -> PC ist mehr aus, es wird mehr gearbeitet -> Boinc darf weniger rechnen) werden die WUs mit der nächsten Deadline bevorzugt gerechnet um ein "brauchbares" Ergebnis zu gewährleisten. In dieser Zeit fordert Boinc keine Arbeit mehr an. Mittlerweile prüfen auch die Projekt Server die Zeitstatistiken und verweigern die Zuteilung von WUs, wenn gemäß der Werte, in der geforderten Zeit nicht berechnet werden können.
Beispiel:
Message from server: No work sent
(won't finish in time) Computer on 50% of time, BOINC on 25% of that, this project gets 20% of that
No work from project
Der Server sagt damit, das der PC 50% der Zeit an ist, 25% davon Boinc rechnen darf und das Projekt von dieser Zeit 20% nur bekommt.

== Problem "No work sent" Lösungen ==
Nachfolgend verschieden Möglichkeiten um an Wus zu kommen, obwohl Boinc keine "will" bzw. bekommt.

==== Verhaltensänderung ====
Es ist einfacher als man denkt und auch logisch: Mehr Rechenleistung gibt mehr Arbeit :-)
Sofern der PC leistungsfähig genug ist, kann man den Client einstellen, das er immer arbeitet, auch wenn der PC in Nutzung ist. Wenn Boinc dabei die normale Arbeit am PC stört, kann man z.B. über die Werte:
On multiprocessors, use at most (< Version 5.10) X processors
On multiprocessors, use at most (> Version 6.1) X % of the processors
Use at most (> Version 5.6) X percent of CPU time
Boinc "begrenzen". Genauer Erklärung dazu siehe [[http://dc.planet3dnow.de/wiki/index.php?title=Portal:BOINC/Konfiguration|BOINC Konfiguration]]
Der weitergehende Weg währe den PC "durchlaufen" zulassen, ist der PC mehr an steigen die Werte <on_frac> und <active_frac> von alleine. Je nach dem wie stark die Nutzungsänderung über den Zeitraum ist, kann das dauern. Zu Beachten ist dabei die stärker Belastung des PCs durch Boinc siehe dazu [[http://dc.planet3dnow.de/wiki/index.php?title=DC Nachteile|DC Nachteile]]

Der letzte Möglichkeit ist eine entsprechende Aufrüstung oder Übertaktung der Hardware, bitte auf eigene Gefahr und/oder Kosten achten.

==== manuelle Steuerung der Projekt ====
Boinc macht einen Unterschied zwischen Projekt "Anhalten" und "Keine neuen Aufgabe". Bei Anhalten wird das Projekt Pausiert und die "Kurzzeit Schuld" wird weiter aufsummiert. Wenn das Projekt keine neuen Aufgaben rechnen darf, werden keine neuen Angefordert und der Wert der "Langzeit Schuld" wird nicht weiter geändert, nach Beendigung der verbleibenden WUs. Dementsprechend sollten alle Projekte die nicht berechnet werden sollen, auf "Keine neue Arbeit" gestellt werden und um den Vorgang zu beschleunigen alle nicht angefangenen WUs abgebrochen werden. Bereits angefangene WUs abzubrechen bedeutet die damit bisher geleistete Arbeit wegzuschmeißen und ist nicht empfohlen.
Es gibt einige Projekte (welche?) die abgebrochene WUs wieder zurücksenden, statt sie an andere Clients zu verteilen. In diesen Fall sollte man nach Senden der fertiggestellten WUs die Funktion "Zurücksetzen" verwenden. Alternativ kann man sich auch von den "unerwünschten" Projekten abmelden. Bei wieder Anmeldung wird der STD/LTD Wert auf 0 gesetzt.
Zu beachten ist bei Projekten mit kurzer Deadline, das der Arbeitspuffer (zusätzlicher + verbinde all X Tage) nicht grösser als die Deadline sein darf. Beispiel:
Projekt Deadline 7 Tage / Verbinden alle 1T / Zusätzlich 5T = 7>1+5 -> Server sendet WUs
Projekt Deadline 5 Tage / Verbinden alle 1T / Zusätzlich 5T = 5<1+5 -> Server sendet keine WUs
Man fordert sonst mehr Arbeit an als in der Zeit berechnet werden kann und damit automatisch über die Deadline überschreitet

==== direkte Manipulation client_state.xml ====
Durch direkte Änderung der entsprechenden Werte in der client_state.xml kann Boinc davon überzeugt werden WUs anzufordern. Dazu muss Boinc komplett beendet werden. Bei Installation als Service geht das z.B. bei Windows XP über den Befehl "net stop boinc" ("net start boinc" aktiviert den Service wieder).
Bei PCs die eher selten an sind, bzw. die aktive Zeit entsprechend gering war, ist als erstes empfehlenswert, die Werte <on_frac> und <active_frac> hochzusetzen. Beispiel:
<time_stats>
<on_frac>0.99</on_frac>
<active_frac>0.99</active_frac>
</time_stats>
Dabei ist zu beachten das nun Boinc denkt 99% der Zeit laufen zu dürfen und in dieser Zeit auch 99% rechnen darf. Um ein Verfallen der WUs durch die Deadline zu vermeiden sollte, dann der PC auch die notwendige Zeit laufen, bzw. rechnen dürfen!

Um ein Projekt durch Manipulation der client_state.xml einen höherer Priorität zu geben sucht man in den entsprechenden <projekt> Abschnitt nach den Werten <short_term_debt> und <long_term_debt>und ändert sie entsprechend Beispiel:
<project>
<short_term_debt>85999</short_term_debt>
<long_term_debt>999999</long_term_debt>
</project>
Es ist zu empfehle an dieser Stelle nicht zu übertreiben und auch die Werte der andren "unerwünschten" Projekte zu beachten. Am besten setzt man alle Werte auf 0 und lässt Boinc gemäß der Ressourcen bzw. Keine neuen Aufgaben entscheiden welches Projekt genommen werden soll. Einfacher sind diese Werte mit BoincDV zu manipulieren

==== BoincDV ====

== Weblinks ==

* [http://www.skipsjunk.net/info/boincdv.html Programmseite von BoincDV]
* [http://boinc.ssl.berkeley.edu/trac/wiki/ClientSched Detaillierte Erklärung auf Englisch, Clients vor 6.4.X]

[[Kategorie:BOINC]]

Hosts-Einträge

2021-05-01T10:10:08Z

Enigmation: Hinweis ergänzt

Über die Datei "hosts" lassen sich Einträge vornehmen, die das hochladen fertig gerechneter Workunits, für ein bestimmtes Projekt, verhindert. Projekte die nicht dort hinterlegt sind, können weiter Datenaustausch mit dem Projekt betreiben.
Das ließe sich mit dem Punkt "Steuerung" -> "Netzwerk pausieren" nicht bewerkstelligen.

Manche Projekte haben für die Uploads eigene Server. Das hat den Vorteil, dass es möglich ist, die fertigen WUs hochzuladen, aber sie noch nicht als Fertiggestellt zu melden. Das heißt, zum Startzeitpunkt eines Rennens braucht nicht erst mühsam Alles hochgeladen werden, sondern nur die Fertigstellung muß noch raus. Dies erfolgt über die Deaktivierung des hosts-Eintrag.
Entweder die Zeilen löschen, oder an jeden Zeilenanfang ein # setzen.

'''Windows''' Die hosts-Datei befindet sich in dem Verzeichnis: C:\Windows\System32\drivers\etc\
Einfach mit einem Editor Datei öffnen, und den Eintrag reinkopieren. Speichern, fertig. Wie immer ist dabei zu beachten, dass der Editor keine .txt-Datei draus macht. Die hosts-Datei hat keine Dateinamenserweiterung.

'''Linux''' Die hosts-Datei befindet sich in dem Verzeichnis: /etc/
Mit einem Editor die Datei in einer Konsole aufrufen. Root-Rechte sind nicht erforderlich.

===Einstein@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Einstein@home
127.0.0.1 scheduler.einsteinathome.org
::1 scheduler.einsteinathome.org

===LHC@home===

Achtung: Die Webseite ist mit diesem Eintrag nicht mehr erreichbar!
Nach Fertigstellung hochladen, aber noch nicht melden:
#LHC@home
127.0.0.1 lhcathome.cern.ch
::1 lhcathome.cern.ch

===MilkyWay@home===

Achtung: Die Webseite ist mit diesem Eintrag nicht mehr erreichbar! Nach Fertigstellung hochladen, aber noch nicht melden:
#MilkyWay@home
127.0.0.1 milkyway.cs.rpi.edu
127.0.0.1 milkyway2.phys.rpi.edu
::1 milkyway.cs.rpi.edu
::1 milkyway2.phys.rpi.edu

===Rosetta@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Rosetta@home
127.0.0.1 bwsrv1.bakerlab.org
::1 bwsrv1.bakerlab.org

===Universe@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#universe@home
127.0.0.1 debian1.universeathome.pl
::1 debian1.universeathome.pl

===World Community Grid===

Nach Fertigstellung hochladen, aber noch nicht melden:
#World Community Grid
127.0.0.1 scheduler.worldcommunitygrid.org
::1 scheduler.worldcommunitygrid.org

App-config.xml

2021-04-18T11:57:19Z

Enigmation: Verweis auf die richtige Seite app_config.xml eingefügt

Siehe auch: [[App config.xml|DC-WIKI: App_config.xml]]

---

Am 11.03.2013 hatte orpheus2k, oder auch sam_spade, diesen [https://forum.planet3dnow.de/index.php?threads/app_config-xml.411493/ Thread] angelegt. 
 
Da nur der Threadersteller den Start-Post ändern kann, erscheint ein Übertrag in die DC-Wike sinnvoll, da spätestens zum nächsten BOINC-Wettbewerb diese Informationen gebraucht werden. 
Werden diese Informationen im Race-Thread oder Plauderchat bekannt gegeben, gehen sie nach ein paar Seiten wieder unter. 
 
Die app_config.xml Datei z. B. mit dem Notepad erstellen und in den jeweiligen Projektordner im BOINC data directory "C:\ProgramData\BOINC\projects\...") abspeichern. 
Darauf achten, dass die Datei nicht "app_config.xml.'''txt'''" heißt. 
 
 
 
'''[[Einstein@Home]]'''

Hosts-Einträge

2021-04-18T10:45:10Z

Enigmation: LHC ergänzt

Über die Datei "hosts" lassen sich Einträge vornehmen, die das hochladen fertig gerechneter Workunits, für ein bestimmtes Projekt, verhindert. Projekte die nicht dort hinterlegt sind, können weiter Datenaustausch mit dem Projekt betreiben.
Das ließe sich mit dem Punkt "Steuerung" -> "Netzwerk pausieren" nicht bewerkstelligen.

Manche Projekte haben für die Uploads eigene Server. Das hat den Vorteil, dass es möglich ist, die fertigen WUs hochzuladen, aber sie noch nicht als Fertiggestellt zu melden. Das heißt, zum Startzeitpunkt eines Rennens braucht nicht erst mühsam Alles hochgeladen werden, sondern nur die Fertigstellung muß noch raus. Dies erfolgt über die Deaktivierung des hosts-Eintrag.
Entweder die Zeilen löschen, oder an jeden Zeilenanfang ein # setzen.

'''Windows''' Die hosts-Datei befindet sich in dem Verzeichnis: C:\Windows\System32\drivers\etc\
Einfach mit einem Editor Datei öffnen, und den Eintrag reinkopieren. Speichern, fertig. Wie immer ist dabei zu beachten, dass der Editor keine .txt-Datei draus macht. Die hosts-Datei hat keine Dateinamenserweiterung.

'''Linux''' Die hosts-Datei befindet sich in dem Verzeichnis: /etc/
Mit einem Editor die Datei in einer Konsole aufrufen. Root-Rechte sind nicht erforderlich.

===Einstein@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Einstein@home
127.0.0.1 scheduler.einsteinathome.org
::1 scheduler.einsteinathome.org

===LHC@home===

Achtung: Die Webseite ist mit diesem Eintrag nicht mehr erreichbar!
Nach Fertigstellung hochladen, aber noch nicht melden:
#LHC@home
127.0.0.1 lhcathome.cern.ch
::1 lhcathome.cern.ch

===MilkyWay@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#MilkyWay@home
127.0.0.1 milkyway.cs.rpi.edu
127.0.0.1 milkyway2.phys.rpi.edu
::1 milkyway.cs.rpi.edu
::1 milkyway2.phys.rpi.edu

===Rosetta@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Rosetta@home
127.0.0.1 bwsrv1.bakerlab.org
::1 bwsrv1.bakerlab.org

===Universe@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#universe@home
127.0.0.1 debian1.universeathome.pl
::1 debian1.universeathome.pl

===World Community Grid===

Nach Fertigstellung hochladen, aber noch nicht melden:
#World Community Grid
127.0.0.1 scheduler.worldcommunitygrid.org
::1 scheduler.worldcommunitygrid.org

Hosts-Einträge

2021-04-17T22:06:02Z

Enigmation: Milkyway ergänzt

Über die Datei "hosts" lassen sich Einträge vornehmen, die das hochladen fertig gerechneter Workunits, für ein bestimmtes Projekt, verhindert. Projekte die nicht dort hinterlegt sind, können weiter Datenaustausch mit dem Projekt betreiben.
Das ließe sich mit dem Punkt "Steuerung" -> "Netzwerk pausieren" nicht bewerkstelligen.

Manche Projekte haben für die Uploads eigene Server. Das hat den Vorteil, dass es möglich ist, die fertigen WUs hochzuladen, aber sie noch nicht als Fertiggestellt zu melden. Das heißt, zum Startzeitpunkt eines Rennens braucht nicht erst mühsam Alles hochgeladen werden, sondern nur die Fertigstellung muß noch raus. Dies erfolgt über die Deaktivierung des hosts-Eintrag.
Entweder die Zeilen löschen, oder an jeden Zeilenanfang ein # setzen.

'''Windows''' Die hosts-Datei befindet sich in dem Verzeichnis: C:\Windows\System32\drivers\etc\
Einfach mit einem Editor Datei öffnen, und den Eintrag reinkopieren. Speichern, fertig. Wie immer ist dabei zu beachten, dass der Editor keine .txt-Datei draus macht. Die hosts-Datei hat keine Dateinamenserweiterung.

'''Linux''' Die hosts-Datei befindet sich in dem Verzeichnis: /etc/
Mit einem Editor die Datei in einer Konsole aufrufen. Root-Rechte sind nicht erforderlich.

===Einstein@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Einstein@home
127.0.0.1 scheduler.einsteinathome.org
::1 scheduler.einsteinathome.org

===MilkyWay@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#MilkyWay@home
127.0.0.1 milkyway.cs.rpi.edu
127.0.0.1 milkyway2.phys.rpi.edu
::1 milkyway.cs.rpi.edu
::1 milkyway2.phys.rpi.edu

===Rosetta@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Rosetta@home
127.0.0.1 bwsrv1.bakerlab.org
::1 bwsrv1.bakerlab.org

===Universe@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#universe@home
127.0.0.1 debian1.universeathome.pl
::1 debian1.universeathome.pl

===World Community Grid===

Nach Fertigstellung hochladen, aber noch nicht melden:
#World Community Grid
127.0.0.1 scheduler.worldcommunitygrid.org
::1 scheduler.worldcommunitygrid.org

Hosts-Einträge

2021-04-17T21:50:16Z

Enigmation: WCG ergänzt

Über die Datei "hosts" lassen sich Einträge vornehmen, die das hochladen fertig gerechneter Workunits, für ein bestimmtes Projekt, verhindert. Projekte die nicht dort hinterlegt sind, können weiter Datenaustausch mit dem Projekt betreiben.
Das ließe sich mit dem Punkt "Steuerung" -> "Netzwerk pausieren" nicht bewerkstelligen.

Manche Projekte haben für die Uploads eigene Server. Das hat den Vorteil, dass es möglich ist, die fertigen WUs hochzuladen, aber sie noch nicht als Fertiggestellt zu melden. Das heißt, zum Startzeitpunkt eines Rennens braucht nicht erst mühsam Alles hochgeladen werden, sondern nur die Fertigstellung muß noch raus. Dies erfolgt über die Deaktivierung des hosts-Eintrag.
Entweder die Zeilen löschen, oder an jeden Zeilenanfang ein # setzen.

'''Windows''' Die hosts-Datei befindet sich in dem Verzeichnis: C:\Windows\System32\drivers\etc\
Einfach mit einem Editor Datei öffnen, und den Eintrag reinkopieren. Speichern, fertig. Wie immer ist dabei zu beachten, dass der Editor keine .txt-Datei draus macht. Die hosts-Datei hat keine Dateinamenserweiterung.

'''Linux''' Die hosts-Datei befindet sich in dem Verzeichnis: /etc/
Mit einem Editor die Datei in einer Konsole aufrufen. Root-Rechte sind nicht erforderlich.

===Einstein@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Einstein@home
127.0.0.1 scheduler.einsteinathome.org
::1 scheduler.einsteinathome.org

===Rosetta@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Rosetta@home
127.0.0.1 bwsrv1.bakerlab.org
::1 bwsrv1.bakerlab.org

===Universe@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#universe@home
127.0.0.1 debian1.universeathome.pl
::1 debian1.universeathome.pl

===World Community Grid===

Nach Fertigstellung hochladen, aber noch nicht melden:
#World Community Grid
127.0.0.1 scheduler.worldcommunitygrid.org
::1 scheduler.worldcommunitygrid.org

Hosts-Einträge

2021-04-17T20:56:06Z

Enigmation: Rosetta ergänzt

Über die Datei "hosts" lassen sich Einträge vornehmen, die das hochladen fertig gerechneter Workunits, für ein bestimmtes Projekt, verhindert. Projekte die nicht dort hinterlegt sind, können weiter Datenaustausch mit dem Projekt betreiben.
Das ließe sich mit dem Punkt "Steuerung" -> "Netzwerk pausieren" nicht bewerkstelligen.

Manche Projekte haben für die Uploads eigene Server. Das hat den Vorteil, dass es möglich ist, die fertigen WUs hochzuladen, aber sie noch nicht als Fertiggestellt zu melden. Das heißt, zum Startzeitpunkt eines Rennens braucht nicht erst mühsam Alles hochgeladen werden, sondern nur die Fertigstellung muß noch raus. Dies erfolgt über die Deaktivierung des hosts-Eintrag.
Entweder die Zeilen löschen, oder an jeden Zeilenanfang ein # setzen.

'''Windows''' Die hosts-Datei befindet sich in dem Verzeichnis: C:\Windows\System32\drivers\etc\
Einfach mit einem Editor Datei öffnen, und den Eintrag reinkopieren. Speichern, fertig. Wie immer ist dabei zu beachten, dass der Editor keine .txt-Datei draus macht. Die hosts-Datei hat keine Dateinamenserweiterung.

'''Linux''' Die hosts-Datei befindet sich in dem Verzeichnis: /etc/
Mit einem Editor die Datei in einer Konsole aufrufen. Root-Rechte sind nicht erforderlich.

===Einstein@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Einstein@home
127.0.0.1 scheduler.einsteinathome.org
::1 scheduler.einsteinathome.org

===Rosetta@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#Rosetta@home
127.0.0.1 bwsrv1.bakerlab.org
::1 bwsrv1.bakerlab.org

===Universe@home===

Nach Fertigstellung hochladen, aber noch nicht melden:
#universe@home
127.0.0.1 debian1.universeathome.pl
::1 debian1.universeathome.pl

Hosts-Einträge

2021-04-17T20:46:06Z

Enigmation:

Hosts-Einträge

2021-04-17T20:45:01Z

Enigmation: Einstein ergänzt

Hosts-Einträge

2021-04-17T20:43:17Z

Enigmation: /* Universe */

App config.xml

2021-04-10T13:42:16Z

Enigmation: Asteroids als Beispiel für max concurrent hinzugefügt

Mit einer app_config.xml können Parameter für die Projektberechnung festgelegt werden, die sich über die Projektseite nicht festlegen lassen. Per Suchmaschine lassen sich alle Parameter finden. Für unsere Zwecke geht es um das Einstellen:
* wieviele GPU-WUs von welchem Projekt gleichzeitig, mit wievielen CPU-Kernen, rechnen sollen
* von CPU-Projekten die Multithreading betreiben
* der maximalen Anzahl von WUs, eines Projektes/Unterprojektes, die gleichzeitig gerechnet werden sollen

Werden diese Informationen im Race-Thread oder Plauderchat bekannt gegeben, gehen sie nach ein paar Seiten wieder unter. 
 
Die app_config.xml Datei z. B. mit dem Notepad erstellen und in den jeweiligen BOINC-Projektordner "C:\ProgramData\BOINC\projects\..." abspeichern. Darauf achten, dass die Datei nicht "app_config.xml.'''txt'''" heißt. 
 
Analog gilt bei Linux dann idR. /var/lib/boinc-client/projects/... oder /var/lib/boinc/projects/...
 
 
== [[Collatz Conjecture]] ==
<app_config>
<app>
<name>collatz_sieve</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
</app_config> 

== [[Asteroids@home]] ==
Anpassung der maximal gleichzeitig gerechneten CPU-Workunits mittels des Tags max_concurrent, da die Workunits die Recheneinheiten und Caches sehr gut auslasten.

<app_config>
<app>
<name>period_search</name>

<max_concurrent>12</max_concurrent>
</app>
</app_config> 

== [[Einstein@Home]] ==
<app_config>
<app>
<name>hsgamma_FGRPB1G</name>
<gpu_versions>
<gpu_usage>0.333</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
<app>
<name>einstein_O2MDF</name>
<gpu_versions>
<gpu_usage>0.2</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
</app_config> 
== [[MilkyWay@home]] ==
<app_config>
<app>
<name>milkyway</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.05</cpu_usage>
</gpu_versions>
</app>
<app>
<name>milkyway_separation__modified_fit</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.05</cpu_usage>
</gpu_versions>
</app>
</app_config> 
== [[PrimeGrid]] ==
<app_config>
<app>
<name>pps_sr2sieve</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
<app>
<name>ap26</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer_wr</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer15</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer16</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer17low</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer17mega</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer18</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer19</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer20</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>genefer_extreme</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
<app>
<name>ww</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.084</cpu_usage>
</gpu_versions>
</app>
</app_config>

LHC native Einrichtung

2021-02-27T01:21:41Z

Enigmation:

= Einrichtung von nativen LHC Anwendungen =

Diese Anleitung beschreibt die Installation von Squid und Cerns CVMFS auf Ubuntu Systemen. Analog funktioniert dies dann natürlich auch auf Debian, Mint und anderen verwandten Distributionen.
Bei SuSE oder RedHat sind die entsprechenden Paketverwaltungstools (zypper/yast & yum/dnf) zu verwenden, auch kann der Squid Nutzer und dessen Gruppe eine andere sein, zB. "squid" anstelle von "proxy".

= Squid =
Squid ist ein cachender Proxyserver, er wird idR. genutzt um Netzinhalte zu cachen und damit den Zugriff auf diese zu beschleunigen. Damit einher geht eine Reduzierung der beanspruchten Netzwerkbandbreite.
Es empfiehlt sich ausdrücklich Squid über die distributionseigene Paketverwaltung zu installieren, da diese den Cache automatisch und unterhalb eines eigenen Benutzers startet. Auch Konfgurationen für die automatische Rotation der Squid Log Dateien sind enthalten, diese wachsen also nicht ins unermessliche an.

== Installation ==

Cacheverzeichnis anlegen:
mkdir -p /var/cache/squid

Squid installieren:
apt install squid

Squid stoppen:
service squid stop

Cacheverzeichnis dem Squid Benutzer "proxy" übergeben:
chown -R proxy:proxy /var/cache/squid

Cache Basisstruktur im Cacheverzeichnis anlegen:
squid -z

Hier '''zwei mal Enter''' drücken, dieser Schritt geht schnell, gibt aber keine newline zurück, scheint daher zu hängen.

== Konfiguration ==

Die eigentliche Konfiguration der Squidcaches erfolg anhand der im [https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5473 LHC Forum abgelegten Konfiguration].
Es lohnt sich diesen Thread nochmals zu überfliegen, da Änderungen an der Beispielkonfiguration nicht mehr im Startbeitrag eingepflegt werden können. Stand 26.02.2020 sieht die squid.conf folgendermaßen aus:

<nowiki>
# Squid configuration for BOINC
# Based on squid version 3.5
# See also: http://www.squid-cache.org/

# Every line starting with "#" represents a comment.

# Define your local hosts/networks here.
# If neither "crunchers" nor "localnet" is set none of your devices will be permitted to use the proxy.
# The examples show the principle.
# For advanced options read the Squid documentation.
#
# Examples:
#
# Either enter a list of IPs representing your computers that are permitted to use the proxy.
# Each IP on a separate line.
# acl crunchers src 198.51.100.20
# acl crunchers src 198.51.100.31
# acl crunchers src 198.51.100.37
# acl crunchers src 198.51.100.42
#
# Or enter complete network ranges.
# Be aware that this may permit devices like printers or TVs that you may not want to use the proxy.
# acl localnet src 192.0.2.0/24
# acl localnet src 198.51.100.0/24
acl localnet src 192.168.178.0/24

acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl Safe_ports port 1025-65535 # unregistered ports

acl CONNECT method CONNECT

follow_x_forwarded_for allow localhost
follow_x_forwarded_for deny all

#
# Start of extra section 1
# Requests that need special handling

# worldcommunitygrid doesn't like it if data is taken from the local cache
acl wcg_nocache dstdomain .worldcommunitygrid.org
cache deny wcg_nocache

# if CVMFS uses geoapi, ensure it's checked directly
acl cvmfs_geoapi urlpath_regex -i ^/+cvmfs/+[0-9a-z._~-]+/+api/+[0-9a-z._~-]+/+geo/+[0-9a-z._~-]+/+[0-9a-z.,_~-]+
cache deny cvmfs_geoapi

# avoids polluting the disk cache with typical onetimers, e.g. ATLAS job data
acl boinc_nocache urlpath_regex -i /download[0-9a-z._~-]*/+[0-9a-z._~-]+/+.+
cache deny boinc_nocache

# seriously: do NOT cache that!
# Based on a frontier cache suggestion
acl PragmaNoCache req_header Pragma no-cache
cache deny PragmaNoCache

# End of extra section 1
#

acl Purge method PURGE

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Depending on the definition of "crunchers" or "localnet" above at least 1 of the following lines must be uncommented.
# Examples:
# http_access allow crunchers
# http_access allow localnet

http_access allow localhost
# Last "http_access" line.
# Order matters, hence all "http_access" lines following this one will be ignored.
http_access deny all

# http_port
# don't bind it to an IP that is accessible from outside unless you know what you do.
# Examples:
# http_port localhost:3128
#
# This assumes 198.51.100.99 is the external IP of the Squid box
# http_port 198.51.100.99:3128
#
# default setting that binds Squid to all IPs of the Squid box
http_port 3128

# A MUST on Windows.
# If unsure try the the LAN IP of your internet router.
# Avoid using external DNS here.
# On Linux this option shouldn't be necessary
# dns_nameservers 198.51.100.1

max_filedescriptors 4096

# Required OFF for intercepted traffic from LHCb VMs
client_dst_passthru off

# You don't believe this is enough?
# For sure, it is!
cache_mem 256 MB
maximum_object_size_in_memory 24 KB
memory_replacement_policy heap GDSF

# Keep it large enough to store vdi files in the cache.
# See extra section 1 how to avoid onetimers eating up your disk storage.
# min-size=xxx keeps very small files away from your disk
# 20000 limits the disk cache to 20 GB
cache_replacement_policy heap LFUDA
maximum_object_size 6144 MB
cache_dir aufs /var/cache/squid 20000 16 64 min-size=7937

# default=10
logfile_rotate 10

# logformat has to be changed according to your needs and the capabilities of your logfile analyser
logformat my_awstats %>A %lp %ui %un [%tl] "%rm %>ru HTTP/%rv" %>Hs %st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
access_log stdio:/var/log/squid/access.log logformat=my_awstats
#access_log none
strip_query_terms off

coredump_dir none
ftp_user anonymous@

# max_stale 1 week #default
# extended to be prepared for a project reset
max_stale 37 days

# 1 line is required to avoid the ancient default settings
# be conservative
# don't violate the HTTP standards
refresh_pattern . 0 0% 0

store_avg_object_size 1800 KB

shutdown_lifetime 0 seconds

# booster 1!
collapsed_forwarding on

# booster 2!
client_persistent_connections on
server_persistent_connections on

log_icp_queries off

dns_defnames on
dns_v4_first on

forwarded_for transparent

##### End of squid.conf</nowiki>

Anzupassen ist hier der Parameter '''acl localnet src 192.168.178.0/24'''. Dieses ist das LAN-seitige Defaultsubnetz der meisten Fritzboxen. Andere Router nutzen aber zB. das Subnetz 192.168.0.0/24.
Alle Rechner dieses Netzwerkes dürfen daraufhin auf den Cache zugreifen.
Will man nur einzelne Rechner erlauben, kann dies über Einträge wie '''acl crunchers src 192.168.178.20''' erfolgen, dann wird der Squid seine Services nur dem Rechner mit der IP 192.168.178.20 ermöglichen.

Den Squid nun mit der neuen Konfiguration starten:
service squid start
Ob der Squid genutzt wird, lässt sich einfach über sein Zugriffslog verfolgen:

tail -f /var/log/squid/access.log

Startet nach abgeschlossener Konfiguration eine neue native WU, kommen hier innerhalb der ersten Minuten jeweils hunderte bis tausende Einträge hinzu.

= CVMFS =
== Installation ==

Cern CVMFS Paketinformationen ziehen, installieren und den Download wieder entfernen:
wget https://ecsft.cern.ch/dist/cvmfs/cvmfs-release/cvmfs-release-latest_all.deb
sudo dpkg -i cvmfs-release-latest_all.deb
rm -f cvmfs-release-latest_all.deb

CVMFS installieren:
sudo apt-get update
sudo apt-get install cvmfs cvmfs-config-default

CVMFS Basissetup:
sudo cvmfs_config setup
sudo wget https://lhcathome.cern.ch/lhcathome/download/default.local -O /etc/cvmfs/default.local
sudo cvmfs_config reload

Die folgenden Schritte sind notwendig um die nativ laufenden WUs pausieren und wieder aufwecken zu können. Hierzu wird eine control group (cgroup) erstellt, die dieses ermöglicht:
sudo sed -i '$ a\kernel.unprivileged_userns_clone = 1' /etc/sysctl.conf
sudo sysctl -p
sudo wget http://lhcathome.cern.ch/lhcathome/download/create-boinc-cgroup -O /sbin/create-boinc-cgroup
sudo wget http://lhcathome.cern.ch/lhcathome/download/boinc-client.service -O /etc/systemd/system/boinc-client.service
sudo systemctl daemon-reload
sudo systemctl restart boinc-client

LHC native läuft hiermit bereits, jedoch muss in der Konfiguration
== Konfiguration ==
In der CVMFS Konfigurationsdatei default.local
sudo nano /etc/cvmfs/default.local

CVMFS_HTTP_PROXY ist auskommentiert und muss noch angepasst werden:
# CVMFS_HTTP_PROXY="auto;DIRECT"
=>
CVMFS_HTTP_PROXY="http://192.168.178.4:3128;DIRECT"

Nach dem Abspeichern einmal die Konfiguration neu einlesen:
cvmfs_config reload
Das Kommando '''cvmfs_config stat''' zeigt jetzt ''s1cern-cvmfs.openhtc.io'' anstatt ''cvmfs-stratum-one.cern.ch'' als nächstes Cache level, zB. für ATLAS sieht das folgendermaßen aus:

# /usr/bin/cvmfs_config stat atlas.cern.ch
VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2.8.0.0 3963658 1 24568 79806 2 1 3942964 4194305 0 130560 0 0 n/a 530 186 http://s1cern-cvmfs.openhtc.io/cvmfs/atlas.cern.ch http://192.168.178.4:3128 1


= BOINC Client =
Die Proxyeinstellungen können sowohl über die GUI als auch direkt in der cc_config.xml gesetzt werden.
Eine der beiden Methoden ist ausreichend.

== BOINC Manager ==

Im BOINC Manager via ''Optionen'' -> ''Sonstige Einstellungen...'' den Tab ''HTTP Proxyserver'' auswählen.

Haken setzen bei "Über HTTP Proxyserver verbinden", dann Adresse und Port befüllen:
Adresse: 192.168.178.4
Port: 3128

== cc_config.xml ==
<cc_config>
<options>
<proxy_info>
<http_server_name>192.168</http_server_name>
<http_server_port>3128</http_server_port>
</proxy_info>
</options>
</cc_config>

Anschließend die cc_config über boinccmd neu einlesen:
boinccmd --read_cc_config