RadioWiki - Benutzerbeiträge [de]

Hauptseite

2010-02-10T09:46:11Z

Penner:

Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im [http://meta.wikimedia.org/wiki/Hilfe:Handbuch Benutzerhandbuch].

== Vorhandene Seiten ==
[[Datei:Para10 06.jpg|thumb||Karlsruhe Relais]]
* [[Hardware]]
* [http://wiki.astroclub-radebeul.de/index.php?title=Zugang_von_Aussen Zugang von Aussen]] (ACR-Wiki, Freischaltung bei [http://wiki.astroclub-radebeul.de/index.php?title=Benutzer:Markus Markus F.])
* [[Mechanik|Mechanik und elektromagnetische Einkoppelung]]
* [[Daten Auslesen]]
* [[Daten Auswerten]]
* [[Theorie|Ein wenig Mathematik]]
* [[Astropysik|Astrophysik]]
* [[Resourcen/Links]]
* [[Arbeitshilfen]]
* [[Präsentationen/Öffentlichkeitsarbeit]]
* [[Meetings]]
* [[Fotogalerie]]
* [[ToDO-Liste]]

== Starthilfen ==

* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]

----
Seite zum freien herumprobieren:
* [[Sandbox]]

Hauptseite

2010-02-10T09:45:58Z

Penner:

Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im [http://meta.wikimedia.org/wiki/Hilfe:Handbuch Benutzerhandbuch].

== Vorhandene Seiten ==
[[Datei:Para10 06.jpg|thumb||Karlsruhe Relais]]
* [[Hardware]]
* [http://wiki.astroclub-radebeul.de/index.php?title=Zugang_von_Aussen Zugang von Aussen]]
(ACR-Wiki, Freischaltung bei [http://wiki.astroclub-radebeul.de/index.php?title=Benutzer:Markus Markus F.])
* [[Mechanik|Mechanik und elektromagnetische Einkoppelung]]
* [[Daten Auslesen]]
* [[Daten Auswerten]]
* [[Theorie|Ein wenig Mathematik]]
* [[Astropysik|Astrophysik]]
* [[Resourcen/Links]]
* [[Arbeitshilfen]]
* [[Präsentationen/Öffentlichkeitsarbeit]]
* [[Meetings]]
* [[Fotogalerie]]
* [[ToDO-Liste]]

== Starthilfen ==

* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]

----
Seite zum freien herumprobieren:
* [[Sandbox]]

Datei:Ziegerm.jpg

2010-02-06T19:32:30Z

Penner: Die Seite wurde geleert.

Testsperrung

2010-02-06T19:32:02Z

Penner:

<accesscontrol>Administratoren,internal</accesscontrol>
Diese Seite ist durch die (nur im Seitenquelltext zu sehende) Zeile

<pre> <accesscontrol>Administratoren,internal</accesscontrol> </pre>

*für Administratoren und zur Benutzergruppe "internal" gehörende Menschen lese/schreibbar
* für Nutzer, die nicht zur Gruppe "internal" gehören oder nicht angemeldet sind, nicht zugreifbar

Ein Beispiele für eine Seite, die für "interne" lesbar aber nur für Administratoren schreibbar ist, ist [[Testsperrung_ro]].

Wie kann ich so ein Bild schützen???

[[Datei:ziegerm.jpg]]

Testsperrung

2010-02-06T19:31:49Z

Penner:

Sandbox

2010-02-06T19:30:55Z

Penner:

= Hauptüberschrift =

* einsund
* zweiund
* dreiund

== [[Media:29m.raw]] ==
=== [[Media:32m.raw]] ===

Zusammenfassung aus meiner Sicht:

Da der Spiegel vom Ringerreger nicht optimal ausgeleuchtet wird (nur ca. 50 %), soll das
vorhandene Feedhorn für den Einsatz konditioniert werden. Norbert (DL4DTU) und Hartmut
(DG2DWL) plädieren für einen genauen Frequenzabgleich des Einkoppelstiftes auf
return loss > 20 dB bei der Arbeitsfrequenz, Abgleich durch Norbert. Dazu sollte unmittelbar am
Stift eine SMA-Buchse zum Anschluss des Messgerätes und später des Kabels zum LNA
angebracht werden. Zum Klimaschutz kann der Steckverbinder z.B. mit selbstvulkanisierendem
ISO-Band umwickelt werden. Der Stift sollte so beschaffen sein, dass ein schneller Abgleich
möglich ist. Die von mir veranschlagte Dämpfung von ca. 0,25 dB pro Steckverbinder wird
von Norbert und Hartmut als zu hoch angesetzt angesehen.

Das Bild sollte für unangemeldete Nutzer nicht zugreifbar sein, ist es aber doch...:

[[Datei:Ziegerm.jpg]]

Sandbox

2010-02-06T19:29:53Z

Penner: /* Media:32m.raw */

Sandbox

2010-02-06T19:29:42Z

Penner: /* Media:32m.raw */

Sandbox

2010-02-06T19:29:27Z

Penner: /* Media:32m.raw */

Sandbox

2010-02-06T19:29:10Z

Penner:

Testsperrung

2010-02-06T19:24:27Z

Penner:

<accesscontrol>Administratoren,internal</accesscontrol>
Diese Seite ist durch die (nur im Seitenquelltext zu sehende) Zeile

<pre> <accesscontrol>Administratoren,internal</accesscontrol> </pre>

*für Administratoren und zur Benutzergruppe "internal" gehörende Menschen lese/schreibbar
* für Nutzer, die nicht zur Gruppe "internal" gehören oder nicht angemeldet sind, nicht zugreifbar

Ein Beispiele für eine Seite, die für "interne" lesbar aber nur für Administratoren schreibbar ist, ist [[Testsperrung_ro]].

Die Bild der Ziege ist ein geschütztes Bild. Die Sperr-Zeile muss in der [http://rm-radeberg.dyndns.org/radiowiki/index.php/Datei:Ziegerm.jpg Datei-Seite für das Bild] eingetragen werden.
[[Datei:ziegerm.jpg]]

Datei:Ziegerm.jpg

2010-02-06T19:23:14Z

Penner:

<accesscontrol>Administratoren,internal</accesscontrol>

Datei:Ziegerm.jpg

2010-02-06T19:22:33Z

Penner: hat eine neue Version von „Datei:Ziegerm.jpg“ hochgeladen

Datei:Ziegerm.jpg

2010-02-06T19:21:57Z

Penner: hat eine neue Version von „Datei:Ziegerm.jpg“ hochgeladen

Datei:Ziegerm.jpg

2010-02-06T19:20:11Z

Penner:

Testsperrung

2010-02-06T19:19:52Z

Penner:

<accesscontrol>Administratoren,internal</accesscontrol>
Diese Seite ist durch die (nur im Seitenquelltext zu sehende) Zeile

<pre> <accesscontrol>Administratoren,internal</accesscontrol> </pre>

*für Administratoren und zur Benutzergruppe "internal" gehörende Menschen lese/schreibbar
* für Nutzer, die nicht zur Gruppe "internal" gehören oder nicht angemeldet sind, nicht zugreifbar

Ein Beispiele für eine Seite, die für "interne" lesbar aber nur für Administratoren schreibbar ist, ist [[Testsperrung_ro]].

Die Bild der Ziege ist ein geschütztes Bild. Die Sperr-Zeile muss in der Datei-Seite für das Bild eingetragen werden.
[[Datei:ziegerm.jpg]]

Testsperrung

2010-02-06T18:59:08Z

Penner:

Testsperrung

2010-02-06T16:56:00Z

Penner:

<accesscontrol>Administrators,ACCESSCONTROL:Internal</accesscontrol>

Diese Seite ist durch die (nur im Seitenquelltext zu sehende) Zeile nur Administratoren und auf der Seite [[ACCESSCONTROL:Internal]] aufgeführte Personen sichtbar und bearbeitbar.

Die Seite [[ACCESSCONTROL:Internal]] selbst ist ein Beispiel, das für Gruppenmitglieder lesbar aber nur von Administratoren zu bearbeiten ist.

RadioWiki:No Access

2010-02-06T16:05:22Z

Penner: Die Seite wurde neu angelegt: „You have no permission to access this protected page.“

You have no permission to access this protected page.

RadioWiki:No anonymous

2010-02-06T16:04:44Z

Penner:

You have no permissions to access this protected page.

RadioWiki:No anonymous

2010-02-06T16:04:23Z

Penner: Die Seite wurde neu angelegt: „You tried to access a protected page.“

You tried to access a protected page.

Benutzer:Penner

2010-02-02T15:00:31Z

Penner:

Robert Müller
* E-Mail:
** mail@penner2001.de
** robert.mueller@tu-dresden.de

* Tel.:
** 0172/9099580 [für nächsten Tage nur über Mailbox]
* ICQ: 203612885

Benutzer:Penner

2010-02-02T15:00:21Z

Penner: Die Seite wurde neu angelegt: „Robert Müller * E-Mail: ** mail@penner2001.de ** robert.mueller@tu-dresden.de * Tel.: ** 0172/9099580 [fir nächsten Tage nur über Mailbox] * ICQ: 203612885“

Robert Müller
* E-Mail:
** mail@penner2001.de
** robert.mueller@tu-dresden.de

* Tel.:
** 0172/9099580 [fir nächsten Tage nur über Mailbox]
* ICQ: 203612885

Sandbox

2009-11-16T17:40:27Z

Penner: /* TimeLine */

= Hauptüberschrift =

* einsund
* zweiund
* dreiund

== [[Media:29m.raw]] ==
=== [[Media:32m.raw]] ===

=== TimeLine ===
<timeline>
ImageSize = width:160 height:550
PlotArea = width:50 height:530 left:50 bottom:10

DateFormat = yyyy
Period = from:1919 till:1991
TimeAxis = orientation:vertical
ScaleMajor = unit:year increment:5 start:1920

# there is no automatic collision detection ,
# so shift texts up or down manually to avoid overlap

Define $dx = 25 # shift text to right side of bar

PlotData=
bar:Leaders color:red width:25 mark:(line,white) align:left fontsize:S

from:start till:1922 shift:($dx,15) text:Vladimir~Ilyich~[[Lenin]]
from:1922 till:1953 shift:($dx,5) text:[[Stalin|Josef Stalin]]
from:1953 till:1964 shift:($dx,5) text:Nikita~[[Khrushchev]]
from:1964 till:1982 shift:($dx,5) text:Leonid~[[Brezhnev]]
from:1982 till:1984 shift:($dx,-12) text:Yuri~[[Andropov]]
from:1984 till:1985 shift:($dx,4) text:Konstantin~[[Chernenko]] fontsize:XS
from:1985 till:end shift:($dx,10) text:Mikhail~[[Gorbachev]]
</timeline>

<timeline>
ImageSize = width:800 height:100
PlotArea = width:720 height:75 left:65 bottom:20
AlignBars = justify

Colors =
id:epoch value:rgb(0.7,0.7,1) # light yellow
id:period value:rgb(1,0.7,0.7) # light red
id:age value:rgb(0.7,1,0.7) # light green
id:era value:rgb(1,1,0.7) # light blue
id:eon value:rgb(1,0.7,1) # light purple
id:black value:black

Period = from:-4500 till:0
TimeAxis = orientation:horizontal
ScaleMajor = unit:year increment:500 start:-4500
ScaleMinor = unit:year increment:100 start:-4500

Define $markred = text:"*" textcolor:red shift:(0,3) fontsize:10

PlotData=
align:center textcolor:black fontsize:8 mark:(line,black) width:25 shift:(0,-5)

bar:eon color:eon

at: 0 align:right $markred
at: -545 align:left $markred
from: -545 till: 0 text:[[Phanerozoic]]
from:-4500 till: 0 text:[[Precambrian]]

bar:era color:era

from: -64.3 till: 0 text:C~z shift:(0,1.5)
from: -251.1 till: -64.3 text:[[Mesozoic|Meso~zoic]] shift:(0,1.5)
from: -545 till: -251.1 text:[[Paleozoic|Paleo~zoic]] shift:(0,1.5)
from:-4500 till: -545 text:[[Proterozoic]]

bar:period color:period

fontsize:6
from: -1.6 till: 0
from: -64.3 till: -1.6
from: -146 till: -64.3
from: -208 till: -146
from: -251.1 till: -208
from: -286 till: -251.1
from: -360 till: -286
from: -408.5 till: -360
from: -443.5 till: -408.5
from: -490 till: -443.5
from: -545 till: -490

fontsize:8
from: -900 till: -545 text:[[Neoproterozoic|Neoprote-~rozoic]] shift:(0,1.8)
from:-1600 till: -900 text:[[Mesoproterozoic]]
from:-2500 till: -1600 text:[[Paleoproterozoic]]
from:-3800 till: -2500 text:[[Archaean]]
from: start till: -3800 text:[[Hadean]]
</timeline>
cd .

Sandbox

2009-11-16T17:39:17Z

Penner: /* TimeLine */

Sandbox

2009-11-16T17:39:09Z

Penner: /* TimeLine */

Sandbox

2009-11-16T17:38:44Z

Penner: /* TimeLine */

Sandbox

2009-11-16T17:38:28Z

Penner: /* TimeLine */

= Hauptüberschrift =

* einsund
* zweiund
* dreiund

== [[Media:29m.raw]] ==
=== [[Media:32m.raw]] ===

=== TimeLine ===
<timeline>
ImageSize = width:160 height:550
PlotArea = width:50 height:530 left:50 bottom:10

DateFormat = yyyy
Period = from:1919 till:1991
TimeAxis = orientation:vertical
ScaleMajor = unit:year increment:5 start:1920

# there is no automatic collision detection ,
# so shift texts up or down manually to avoid overlap

Define $dx = 25 # shift text to right side of bar

PlotData=
bar:Leaders color:red width:25 mark:(line,white) align:left fontsize:S

from:start till:1922 shift:($dx,15) text:Vladimir~Ilyich~[[Lenin]]
from:1922 till:1953 shift:($dx,5) text:[[Stalin|Josef Stalin]]
from:1953 till:1964 shift:($dx,5) text:Nikita~[[Khrushchev]]
from:1964 till:1982 shift:($dx,5) text:Leonid~[[Brezhnev]]
from:1982 till:1984 shift:($dx,-12) text:Yuri~[[Andropov]]
from:1984 till:1985 shift:($dx,4) text:Konstantin~[[Chernenko]] fontsize:XS
from:1985 till:end shift:($dx,10) text:Mikhail~[[Gorbachev]]
</timeline>

<timeline>
ImageSize = width:800 height:100
PlotArea = width:720 height:75 left:65 bottom:20
AlignBars = justify

Colors =
id:epoch value:rgb(0.7,0.7,1) # light yellow
id:period value:rgb(1,0.7,0.7) # light red
id:age value:rgb(0.7,1,0.7) # light green
id:era value:rgb(1,1,0.7) # light blue
id:eon value:rgb(1,0.7,1) # light purple
id:black value:black

Period = from:-4500 till:0
TimeAxis = orientation:horizontal
ScaleMajor = unit:year increment:500 start:-4500
ScaleMinor = unit:year increment:100 start:-4500

Define $markred = text:"*" textcolor:red shift:(0,3) fontsize:10

PlotData=
align:center textcolor:black fontsize:8 mark:(line,black) width:25 shift:(0,-5)

bar:eon color:eon

at: 0 align:right $markred
at: -545 align:left $markred
from: -545 till: 0 text:[[Phanerozoic]]
from:-4500 till: 0 text:[[Precambrian]]

bar:era color:era

from: -64.3 till: 0 text:C~z shift:(0,1.5)
from: -251.1 till: -64.3 text:[[Mesozoic|Meso~zoic]] shift:(0,1.5)
from: -545 till: -251.1 text:[[Paleozoic|Paleo~zoic]] shift:(0,1.5)
from:-4500 till: -545 text:[[Proterozoic]]

bar:period color:period

fontsize:6
from: -1.6 till: 0
from: -64.3 till: -1.6
from: -146 till: -64.3
from: -208 till: -146
from: -251.1 till: -208
from: -286 till: -251.1
from: -360 till: -286
from: -408.5 till: -360
from: -443.5 till: -408.5
from: -490 till: -443.5
from: -545 till: -490

fontsize:8
from: -900 till: -545 text:[[Neoproterozoic| Neoprote-~rozoic]] shift:(0,1.8)
from:-1600 till: -900 text:[[Mesoproterozoic]]
from:-2500 till: -1600 text:[[Paleoproterozoic]]
from:-3800 till: -2500 text:[[Archaean]]
from: start till: -3800 text:[[Hadean]]
</timeline>

Sandbox

2009-11-16T17:38:15Z

Penner: /* TimeLine */

Sandbox

2009-11-16T17:36:06Z

Penner: /* TimeLine */

= Hauptüberschrift =

* einsund
* zweiund
* dreiund

== [[Media:29m.raw]] ==
=== [[Media:32m.raw]] ===

=== TimeLine ===
<timeline>
ImageSize = width:160 height:550
PlotArea = width:50 height:530 left:50 bottom:10

DateFormat = yyyy
Period = from:1919 till:1991
TimeAxis = orientation:vertical
ScaleMajor = unit:year increment:5 start:1920

# there is no automatic collision detection,
# so shift texts up or down manually to avoid overlap

Define $dx = 25 # shift text to right side of bar

PlotData=
bar:Leaders color:red width:25 mark:(line,white) align:left fontsize:S

from:start till:1922 shift:($dx,15) text:Vladimir~Ilyich~[[Lenin]]
from:1922 till:1953 shift:($dx,5) text:[[Stalin|Josef Stalin]]
from:1953 till:1964 shift:($dx,5) text:Nikita~[[Khrushchev]]
from:1964 till:1982 shift:($dx,5) text:Leonid~[[Brezhnev]]
from:1982 till:1984 shift:($dx,-12) text:Yuri~[[Andropov]]
from:1984 till:1985 shift:($dx,4) text:Konstantin~[[Chernenko]] fontsize:XS
from:1985 till:end shift:($dx,10) text:Mikhail~[[Gorbachev]]
</timeline>

<timeline>
ImageSize = width:800 height:100
PlotArea = width:720 height:75 left:65 bottom:20
AlignBars = justify

Colors =
id:epoch value:rgb(0.7,0.7,1) # light yellow
id:period value:rgb(1,0.7,0.7) # light red
id:age value:rgb(0.7,1,0.7) # light green
id:era value:rgb(1,1,0.7) # light blue
id:eon value:rgb(1,0.7,1) # light purple
id:black value:black

Period = from:-4500 till:0
TimeAxis = orientation:horizontal
ScaleMajor = unit:year increment:500 start:-4500
ScaleMinor = unit:year increment:100 start:-4500

Define $markred = text:"*" textcolor:red shift:(0,3) fontsize:10

PlotData=
align:center textcolor:black fontsize:8 mark:(line,black) width:25 shift:(0,-5)

bar:eon color:eon

at: 0 align:right $markred
at: -545 align:left $markred
from: -545 till: 0 text:[[Phanerozoic]]
from:-4500 till: 0 text:[[Precambrian]]

bar:era color:era

from: -64.3 till: 0 text:C~z shift:(0,1.5)
from: -251.1 till: -64.3 text:[[Mesozoic|Meso~zoic]] shift:(0,1.5)
from: -545 till: -251.1 text:[[Paleozoic|Paleo~zoic]] shift:(0,1.5)
from:-4500 till: -545 text:[[Proterozoic]]

bar:period color:period

fontsize:6
from: -1.6 till: 0
from: -64.3 till: -1.6
from: -146 till: -64.3
from: -208 till: -146
from: -251.1 till: -208
from: -286 till: -251.1
from: -360 till: -286
from: -408.5 till: -360
from: -443.5 till: -408.5
from: -490 till: -443.5
from: -545 till: -490

fontsize:8
from: -900 till: -545 text:[[Neoproterozoic|Neoprote-~rozoic]] shift:(0,1.8)
from:-1600 till: -900 text:[[Mesoproterozoic]]
from:-2500 till: -1600 text:[[Paleoproterozoic]]
from:-3800 till: -2500 text:[[Archaean]]
from: start till: -3800 text:[[Hadean]]
</timeline>

Sandbox

2009-11-16T17:35:34Z

Penner: /* Media:32m.raw */

Daten Auslesen

2009-10-02T14:51:27Z

Penner: /* Datenaufnahme */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_{n,0},ad_{n,0},c_{n,0});\, (t_1,ad_1);\, (t_2,ad_2);\, ... (t_{n,i},ad_{n,i},c_{n,i});\, (t_{n+1},ad_{n+1});\, ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

----

----

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T14:42:06Z

Penner: /* Rohdatenspeicherung */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_{n,0},ad_{n,0},c_{n,0});\, (t_1,ad_1);\, (t_2,ad_2);\, ... (t_{n,i},ad_{n,i},c_{n,i});\, (t_{n+1},ad_{n+1});\, ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T14:41:38Z

Penner: /* Rohdatenspeicherung */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2);\, ... (t_{n,i},ad_{n,i},c_{n,i});\, (t_{n+1},ad_{n+1});\, ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T14:41:02Z

Penner: /* Rohdatenspeicherung */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2), ... (t_{n,i},ad_{n,i},c_{n,i}), (t_{n+1},ad_{n+1}), ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T14:27:05Z

Penner: /* Datenausfnahme */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2), ... (t_{n,i},ad_{n,i},c_{n,i}), (t_{n+1},ad_{n+1}), ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also z.B. nur immer aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung sofort eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören.

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T13:31:41Z

Penner: /* Datenausfnahme */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2), ... (t_{n,i},ad_{n,i},c_{n,i}), (t_{n+1},ad_{n+1}), ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also z.B. nur immer aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung sofort eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören.

== Datenausfnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T13:31:04Z

Penner: /* Datenausfnahme */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2), ... (t_{n,i},ad_{n,i},c_{n,i}), (t_{n+1},ad_{n+1}), ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also z.B. nur immer aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung sofort eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören.

== Datenausfnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T13:25:02Z

Penner: /* Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2), ... (t_{n,i},ad_{n,i},c_{n,i}), (t_{n+1},ad_{n+1}), ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also z.B. nur immer aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung sofort eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören.

== Datenausfnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern. Dabei benötigt man eine gemeinsame Datenbasis.

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Daten Auslesen

2009-10-02T13:13:16Z

Penner: /* Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_1,ad_1);\, (t_2,ad_2), ... (t_{n,i},ad_{n,i},c_{n,i}), (t_{n+1},ad_{n+1}), ... </math>
mit

<math>n=k*i</math>

Die Koordinaten werden also z.B. nur immer aller 100 Werte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung sofort eine Liste mit kompletten n-Tupen erstellt werden.

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Sandbox

2009-08-14T11:51:33Z

Penner:

[[Media:27m.raw]]
[[Media:29m.raw]]
[[Media:32m.raw]]

Sandbox

2009-08-14T11:33:11Z

Penner: Die Seite wurde neu angelegt: „Media:27m.raw Media:29m.raw“

[[Media:27m.raw]]
[[Media:29m.raw]]

Hardware

2009-08-12T21:11:13Z

Penner: /* technische Dokumentation */

== technische Dokumentation ==

technische Dokumentation des Radioteleskops als pdf-file:
[[Media:doku.pdf|technische Dokumentation des Radioteleskops]]

== Links ==

== Datenblätter ==

* [http://www.atmel.com/atmel/acrobat/doc2467.pdf ATMega128 (ATMEL)]
* [http://cds.linear.com/docs/Datasheet/485fh.pdf LTC485 (LT)]
* [http://focus.ti.com/lit/ds/symlink/max232.pdf MAX232 (TI)]
* [http://www.analog.com/static/imported-files/data_sheets/AD9851.pdf AD9851 DDS (AD)]
* [http://www.analog.com/static/imported-files/Data_Sheets/AD9858.pdf AD9858 DDS (AD)]
* [http://www.analog.com/static/imported-files/data_sheets/AD8307.pdf AD8307 log. Detektor]

--[[Benutzer:Hgz|Hgz]] 19:39, 12. Aug. 2009 (UTC)

Hauptseite

2009-08-12T19:24:29Z

Penner: /* Vorhandene Seiten */

<big>'''MediaWiki wurde erfolgreich installiert.'''</big>

Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im [http://meta.wikimedia.org/wiki/Help:Contents Benutzerhandbuch].

== Vorhandene Seiten ==
* [[Daten Auslesen]]
* [[Zugang von Aussen]]

== Starthilfen ==

* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]

Daten Auslesen

2009-08-12T19:23:06Z

Penner: /* VirtualBox, PPTP */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor:

Hauptseite

2009-08-12T19:20:57Z

Penner:

<big>'''MediaWiki wurde erfolgreich installiert.'''</big>

Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im [http://meta.wikimedia.org/wiki/Help:Contents Benutzerhandbuch].

== Vorhandene Seiten ==
* [[Daten_Auslesen]]
* [[Zugang von Aussen]]

== Starthilfen ==

* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]

Hauptseite

2009-08-12T19:18:37Z

Penner:

<big>'''MediaWiki wurde erfolgreich installiert.'''</big>

Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im [http://meta.wikimedia.org/wiki/Help:Contents Benutzerhandbuch].

* [[Daten_Auslesen]]

== Starthilfen ==

* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]

Daten Auslesen

2009-08-12T19:17:36Z

Penner: Die Seite wurde neu angelegt: „= VirtualBox, PPTP = Der Zugang zum Sternwartenetzwerk soll in Zukunft standardmäßig über die offizielle VPN-Adresse erfolgen. Dazu wird ein PPTP-Tunnel zu Mon…“

= VirtualBox, PPTP =
Der Zugang zum Sternwartenetzwerk soll in Zukunft standardmäßig über die offizielle VPN-Adresse erfolgen. Dazu wird ein PPTP-Tunnel zu Mond aufgebaut und dabei erhält man eine offizielle Adresse. Die kann wechseln, daher muss DynDns eingesetzt werden.

Die offizielle Adresse kann man gleich noch für 100 andere Sachen verbraten. Grundsätzlich sollen alle Dienste aber über SSH abgesichert sein. So können wir alles Mögliche basteln und trotzdem in Ruhe schlafen. Denkbare Dienste:

* OpenVPN
* Webserver (u.a. Wiki]
* SSH zum Perseiden

== Gatewayrechner ==
Im Prinzip könnte der Perseid gleich selbst den Tunnel aufrechterhalten. Dabei gibt es zwei Probleme:

* Der Perseid hat dann eine völlig offene IP-Adresse ohne die Möglichkeit, eine Firewall davorzustellen und auf ihm laufen prinzipiell alle möglichen und unmöglichen Netzwerkdienste. Er müsste sich also selbst mittels Iptables vor Spaßvögeln aus dem Internet schützen.
* Wie sollte der Perseid Antwortpakete schicken, die seine Kommunikation über die offizielle Adresse betreffen? Sein Standardgateway geht über das NAT-des FBN und das soll asu diversen Gründen auch so bleiben. Im Prinzip könnte man wahrscheinlich nur die passenden Pakete über den Mond routen. Ich weiß erstens nicht wie das geht und zweitens erscheint mir das ganz furchtbar unsauber.

Die Lösung ist ein separater Gatewayrechner. Der kann im Perseid als virtuelle Maschine leben und braucht ''nur'' 64 MB RAM, wenn ich ein ein ganz normales Ubuntu in der Serverinstallation verwende. Der wird über die host-only-Variante von Virtualbox angeschlossen und damit kann der Perseid recht gut kontrollieren, was der Gatewayrechner darf und was nicht. In diesem [http://www.giannistsakiris.com/index.php/2007/11/01/host-only-networking-for-virtualbox Artikel] ist beschrieben, wie man das mittel ''Host-Interfaces'' und tunectl machen kann.

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads Schlafen legen.
Das stelle ich mir so vor: