höhere tRAS bringt mehr Performance?

[GloomY]

Wie u.a. hier (http://www.forum-3dcenter.net/vbulletin/showthread.php?postid=934624#post934624) schon mal diskutiert, scheint speziell beim nForce2 eine höhere tRAS Einstellung zu mehr Performance zu führen. Werte von 7 oder 11 scheinen besser als 5 oder 3 zu sein. Wie kommt das? Sind bei Speichertimings nicht immer niedrigere Werte besser? Kann man sich nicht mehr auf die Eselsbrücke "kleiner = schneller" verlassen?

Ich habe mir ein paar Gedanken dazu gemacht und probiere obiges Phänomen zu erklären.

Dazu guckt man sich erstmal an, wie tRAS überhaupt festgelegt ist. Das ist die Zeit (in Takten), die eine geöffnete Page mindestens offen bleiben muss, bis sie wieder geschlossen werden kann. Wie wirkt sich dies auf die Performance aus? Betrachten wir Fall 1:

Wenn eine Page geöffnet wurde und ein Page Miss stattfindet, muss die aktuell geöffnete Page erst wieder geschlossen werden. Danach kann die neue Page geöffnet und darauf zugegriffen werden. In diesem Fall hilft also eine niedrigere Einstellung für tRAS, weil das Schliessen hier nun schneller geht bzw. gehen kann. Es muss nicht umbedingt schneller gehen, wenn z.B. die Page schon länger als die mit tRAS spezifizierte Zeit geöffnet ist. Dann kann die Page sofort geschlossen werden, andernfalls muss erst gewartet werden, bis die Page tRAS lang offen war und kann erst dann geschlossen werden.

Wie kommt es aber dann dazu, dass höhere Werte zu besserer Performance führen? Höhere tRAS Werte führen dazu, dass die geöffnete Page länger offen bleibt. Das kann nämlich auch Vorteile haben (Fall 2):

Wenn ein Zugriff wieder in die gleiche Page fällt, ist dies natürlich vorteilhaft, da nun die Zeit für das Schliessen und erneute Öffnen der anderen Page entfällt (tRP plus tRCD). Man kann direkt die CAS anlegen und nach der tCAS spezifizierten Zeit die Daten ausgeben.
Was hat das ganze nun mit tRAS zu tun? Hier meine mögliche Erklärung: Der nForce2 Speichercontroller verwendet (zumindest bei einigen Biosversionen) eine closed-Page Policy, d.h. er schliesst die Page wenn er nichts zu tun hat. Eine höhere tRAS Einstellung zwingt ihn nun, die Page länger offen zu halten, was in einigen Situationen zu einer größeren Anzahl an nachfolgenden Page Hits führt. Das muss hier zwar nicht zwangsläufig der Fall sein, ist aber recht wahrscheinlich (natürlich vom jeweiligen Programm abhängig). Natürlich bringt das bei einem Page Miss einen Latenz-Nachteil (wie in Fall 1 beschrieben), jedoch scheint eine länger offen gehaltene Page insgesamt eher Performancevorteile zu bringen. Hier ist eine längere tRAS Zeit also von Vorteil.

Die Performance hängt also von der verwendeten Politik des Speichercontrollers und vom Zugriffsmuster der einzelnen Programme ab. Falls diese eine gute Datenlokalität (spacial locality) besitzen, wird eine höhere tRAS bei einer closed Page Policy also Vorteile bringen, da hier die Pages länger offen sind.
Programmen mit einer schlechten Datenlokalität bringt niedrigere tRAS Einstellung Vorteile, da diese bei Page Misses nun schneller sind.
Eine optimale Einstellung wäre übrigends eine Open Page Policy und eine niedrige tRAS Einstellung. Beim nForce2 (bzw. gewissen Bios Versionen) muss man diese Open Page Policy quasie über hohe tRAS Werte erzwingen.

Insgesamt scheint der erste Fall tendenziell eher nicht viel zu bringen (zur Latenz durch tRAS kommt schliesslich noch tRP, tRCD und tCL dazu). Eine bessere Page Hit Rate des zweiten Falls wirkt sich aber schon deutlich besser auf die Performance aus. Bei Streaming Anwendungen (Audio-/ Video-(de)coding) mit extrem hoher Lokalität der Daten führt dies sicher zu besserer Performance.
Der Vorteil einer closed Page Policy liegt imho nur in der besseren Zugriffszeit bei random Zugriffen und einem geringeren Stromverbrauch.

Ich würde daher gerne (speziell von nForce2 Usern und ganz speziell von Usern, bei denen eine höhere tRAS zu mehr Performance führt) ein paar Benchmarks zum Testen meiner Hypothese haben:
Hier würde mich vor allem Cachemem (http://www.simtel.net/pub/pd/57936.html) unter DOS (!) interessieren. Wer kein DOS mehr hat, der soll bitte unter www.bootdisk.de sich eine exe runterladen und damit eine Bootdisk erzeugen (z.B. Win98SE Bootdisk (http://www.bootdisk.info/modules.php?name=Downloads&d_op=getit&lid=22)). Dann unter DOS die cachemem.exe auf die Ramdisk kopieren und mit cachemem.exe > ergebnis.txt die Ausgabe in die Datei ergebnis.txt umleiten. Diese Datei dann zurück auf die Diskette kopieren und dann hier posten.
Alternativ geht auch Sciencemark2 von der oder alternativ auch der [url=http://www.angelfire.com/jazz/ikon/sciencemark2.zip]Mirror von Ikon (]Sciencemark2 Homepage[/URL).
Für die Streaming Benches ist im Prinzip jedes Video-Encoding geeignet. Bitte aber darauf achten, dass die Einstellungen, Hintergrundaktivitäten usw. alle gleich sind, damit man die Ergebnisse auch wirklich auf die unterschiedlichen tRAS Einstellungen zurückführen kann.

edit: Über 50 Views und keine Antwort? Kann nicht wenigstens mal jemand mit diesem Phänomen Cachemem mit unterschiedlichen tRAS Einstellungen testen und hier reinposten?

[Kurgan]

so, hab mal ein bisschen gecachememt ;)

jeweils drei durchläufe mit tras 5,7 und 11
l1 read : 18274,3
l1 write : 15117,2
l2 read : 6259,8
l2 write : 6373,1
hier hat der tras-wert keinerlei einfluss, die diefferenzen bewegen sich durch alle tests bei +/-0.1 abweichung .. auch bekannt als messtoleranz ;)

jetzt kommts, jeweils durchschnittswert aller 3 läufe, allerdings auch wieder maximalabweichung 0,3 :

main memory speed:
tras 5 : read 2037,2 - write 1331
tras 7 : read 2050,1 - write 1337,1
tras 11: read 2095,9 - write 1336,3

ja. also das kann ich dann nicht mehr interpretieren .. das das ganze mit höherem tras schneller wird hat sich ja schon abgezeichnet, auffallend ist alledings. das von 7 nach 11 der read-wert nochmal über 2% zulegen kann während der write wert schlechter wird ..

die kompletten ergebisse (falls gewünscht) gibt es nach zusendung einen 100Euranten-scheines oder einfach angabe der email-addi ;)

[Pinhead]

werd heut abend mal testen, ob sich da was verändert

[GloomY]

Original geschrieben von Kurgan
so, hab mal ein bisschen gecachememt ;)

jeweils drei durchläufe mit tras 5,7 und 11
l1 read : 18274,3
l1 write : 15117,2
l2 read : 6259,8
l2 write : 6373,1
hier hat der tras-wert keinerlei einfluss, die diefferenzen bewegen sich durch alle tests bei +/-0.1 abweichung .. auch bekannt als messtoleranz ;)Naja, die Cache Werte sind für die Speicherperformance erwartungsgenmäß uninteressant.
Original geschrieben von Kurgan
jetzt kommts, jeweils durchschnittswert aller 3 läufe, allerdings auch wieder maximalabweichung 0,3 :

main memory speed:
tras 5 : read 2037,2 - write 1331
tras 7 : read 2050,1 - write 1337,1
tras 11: read 2095,9 - write 1336,3Das ist schon eher interessant und unterstützt meine These.
Original geschrieben von Kurgan
ja. also das kann ich dann nicht mehr interpretieren .. das das ganze mit höherem tras schneller wird hat sich ja schon abgezeichnet, auffallend ist alledings. das von 7 nach 11 der read-wert nochmal über 2% zulegen kann während der write wert schlechter wird ..

die kompletten ergebisse (falls gewünscht) gibt es nach zusendung einen 100Euranten-scheines oder einfach angabe der email-addi ;) Interessant wären vor allem die Pointer-chasing Werte (die Tabelle am Ende) und dort der Wert ganz unten rechts (maximale Block size, maximale Step length). Hier müsste eigentlich eine niedrigere tRAS Einstellung bessere (=niedrigere) Ergebnisse liefern.

Vielen Dank trotdem erst einmal für deine Mühe. :)

[Kurgan]

tras 11:
Block of 32768KB: 8 14 27 53 99 154 155 157 162 172 190 cycles
tras 7:
Block of 32768KB: 8 16 27 53 98 154 155 157 162 171 190 cycles
tras 5:
Block of 32768KB: 8 17 27 55 104 154 155 157 162 171 190 cycles

durch die bank weg identische ergebnisse, höchstens mal ein punkt mehr oder weniger ...

und nu ? ;)

[GloomY]

Original geschrieben von Kurgan
tras 11:
Block of 32768KB: 8 14 27 53 99 154 155 157 162 172 190 cycles
tras 7:
Block of 32768KB: 8 16 27 53 98 154 155 157 162 171 190 cycles
tras 5:
Block of 32768KB: 8 17 27 55 104 154 155 157 162 171 190 cycles

durch die bank weg identische ergebnisse, höchstens mal ein punkt mehr oder weniger ...

und nu ? ;) Danke für die Ergebnissem, welche aber eher gegen meine These sprechen. Eine niedrigere tRAS sollte hier niedrigere Latenzzeiten mit sich bringen. Dass diese aber fast überall die gleichen sind, spricht wie erwähnt gegen meine Vermutung.
Kann jemand diese Zahlen bestätigen?

[GloomY]

*push*

Keiner, der das ausser Kurgan noch testen kann? *hoff*

[Kurgan]

ich glaub das ist einfach das falsche forum .. ins speku guckt doch keine sau, ich wär auch nicht hier wenn du den thread die tage nicht mal erwähnt hättest ..
schieb das mal ins amd-forum und schwups kommen die ergebnisse ;)

[GloomY]

Original geschrieben von Kurgan
ich glaub das ist einfach das falsche forum .. ins speku guckt doch keine sau,Ach so... :|
Original geschrieben von Kurgan
ich wär auch nicht hier wenn du den thread die tage nicht mal erwähnt hättest ..
schieb das mal ins amd-forum und schwups kommen die ergebnisse ;) Ok, ich hoffe das hilft :)

[Evil Ash]

ihr könnt ja auch mal mit memtest 3.0 testen.
da bringt die erhöhung des wertes auch mehr speicherdurchsatz, glaub fast 100 mb/s sind durchaus drin.

hab nen asus a7n8x del. 2.00

[MOB]

l1 read : 13304,5
l1 write: 11006,0
l2 read : 4486,0
l2 write: 4663,1

Werte jeweils bei tras=5,7,11


Main Memory Speed: 5 / 7 / 11

read: 1250,3 / 1300,4 / 1309,6
write: 800,8 / 800,9 / 800,2

Block of 32768KB:

(tras 5)10 19 30 61 114 168 176 184 184 184 207
(tras 7)10 19 29 66 110 168 176 184 184 184 207
(tras11)10 18 29 63 117 168 176 184 184 184 207


Asus a7n8x del.
2 x 256MB PC2100
Xp 1800+


Gruß

[Kurgan]

na, gloomy, hab ichs nicht gesagt ? ;)

[MOB]

Original geschrieben von Kurgan
na, gloomy, hab ichs nicht gesagt ? ;)

He he, hast recht gehabt. Ins Spekuforum guck ich so gut wie nie rein.
Hab de Thread erst vorhin "entdeckt".
Lieber spät als nie :D

Gruß

[Kurgan]

dieser beitrag war mein erster im speku-teil (glaub ich ..) ..und reingeguckt hab ich vorher auch noch nie (soweit mich meine erinnerung nicht trügt .. )

[GloomY]

;(

Die Ergebnisse sprechen auch hier gegen meine These... :kratz2:

Hm, ich verstehe einfach nicht warum das so ist. Mit dem Pointer Chasing bei Cachemem und grosser Block Size wird praktisch die ganze Zeit Page Misses provoziert, bei denen eine niedrige tRAS Zeit eigentlich besser sein sollte. Aber die Ergebnisse sind fast exakt gleich, bis auf ein paar Ausrutscher. Ich versteh's einfach nicht... ??? :bawling:

[Mellops]

Noch ein paar Zahlen:

Main Memory Speed: 5 / 7 / 11

read: 1603.3 / 1603.4 / 1595.3
write: 996.3 / 996.8 / 995.3


Block of 32768KB:

(tras 5)11 18 31 61 131 185 189 193 193 193 216
(tras 7)11 19 31 61 131 185 189 193 193 193 216
(tras11)11 18 30 61 132 185 188 193 193 193 216


avi -> mpeg2: 5 / 7 / 11

10m 50s / 10m 49s / 10m 48s


mpeg2 -> avi: 5 / 7 / 11

7m 51s / 7m 44s / 7m 46s



MSI K7N2 Delta-L
FSB 167MHz
1x 512MB 167MHz


MfG
Mellops


Edit: mpg -> avi eingefügt

[Madkiller]

Original geschrieben von GloomY
;(

Die Ergebnisse sprechen auch hier gegen meine These... :kratz2:

Hm, ich verstehe einfach nicht warum das so ist. Mit dem Pointer Chasing bei Cachemem und grosser Block Size wird praktisch die ganze Zeit Page Misses provoziert, bei denen eine niedrige tRAS Zeit eigentlich besser sein sollte. Aber die Ergebnisse sind fast exakt gleich, bis auf ein paar Ausrutscher. Ich versteh's einfach nicht... ??? :bawling:

Nicht weinen *tröst*

btw
Wird zwar nicht sooo interessieren, aber bei UT2003, hat mir das Umstellen von 2-2-2-3 auf 2-2-2-11 1.05% mehr fps beim Pyramide Demo gebracht.

[GloomY]

Original geschrieben von Madkiller
Nicht weinen *tröst*

btw
Wird zwar nicht sooo interessieren, aber bei UT2003, hat mir das Umstellen von 2-2-2-3 auf 2-2-2-11 1.05% mehr fps beim Pyramide Demo gebracht. Aha... 1 Prozent ist zwar nicht viel, aber immerhin. :)

Hat jemand eigentlich Seti Ergebnisse? Ich denke, dass Seti auf Recht zufällig auf den Speicher zugreift, und daher eine niedrigere tRAS besser sein sollte. Wenn das aber selbst hier nicht der Fall sein sollte, dann muss ich meine Vermutung eben zurückziehen... ;(

[Sephiroth]

Und das ist auschließlich bei'm NForce2 Chipsatz so und bei anderen(KT400 oder KT333) nicht?

[Madkiller]

Original geschrieben von Sephirot
Und das ist auschließlich bei'm NForce2 Chipsatz so und bei anderen(KT400 oder KT333) nicht?

Gute Frage...
Willst du das nicht testen? =)

[Sephiroth]

Original geschrieben von Madkiller
Gute Frage...
Willst du das nicht testen? =)
hmm..das könnt ich wohl ;) mal schauen ob ich heut dazu komme.

[Mellops]

Noch ein paar Benches, bei denen auch die anderen Timings verändert wurden.

[Sephiroth]

so dann will ich mal.
Folgende Werte stammen von meinem A7V8X mit VIA KT400

2.0 2-2-6

Cache size/Memory speed info tool 2.65MMX - (c) 1999-2001, LRMS - DJGPP compiled
CPUID support detected... 'AuthenticAMD' with FPU TSC MMX
Family=6 Model=10 Step=0 Type=0 Chipset (Vendor/Device ID(Rev)): VIA/3189(00)
CPU clock: 2187.5 MHz
Using 32MB physical memory block (alignment = 32)
Bandwidth - MMX linear access test... Read/Write/Copy (MB/s)
Block of 1KB: 19073.5 / 16661.7 / 22368.8
Block of 2KB: 18019.7 / 15881.8 / 23282.7
Block of 4KB: 18534.5 / 15852.4 / 23768.8
Block of 8KB: 18792.1 / 15773.0 / 24019.4
Block of 16KB: 18935.1 / 15742.9 / 24146.7
Block of 32KB: 19008.8 / 15718.4 / 23299.1
Block of 64KB: 18945.7 / 15593.8 / 5917.0
Block of 128KB: 6506.8 / 6623.2 / 5896.9
Block of 256KB: 6511.3 / 6629.0 / 5898.7
Block of 512KB: 6510.5 / 6628.6 / 820.4
Block of 1024KB: 1525.6 / 714.3 / 814.2
Block of 2048KB: 1504.5 / 733.0 / 811.6
Block of 4096KB: 1499.2 / 738.0 / 810.5
Block of 8192KB: 1495.7 / 740.6 / 810.1
Block of 16384KB: 1494.9 / 741.5 / 810.0
Block of 32768KB: 1494.3 / 742.2
Latency - Memory walk tests... ("pointer chasing")
Null size: 4 cycles 1 cycles (overhead 66 cycles)
steps: 4 8 16 32 64 128 256 512 1k 2k 4k (bytes)
Block of 1KB: 4 4 4 4 4 4 4 4 - - - cycles
Block of 2KB: 4 4 4 4 4 4 4 4 4 - - cycles
Block of 4KB: 4 4 4 4 4 4 4 4 4 4 - cycles
Block of 8KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 16KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 32KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 64KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 128KB: 4 5 9 18 20 20 20 20 20 20 20 cycles
Block of 256KB: 4 5 9 18 20 20 20 20 20 20 20 cycles
Block of 512KB: 4 5 9 18 20 20 20 20 20 20 20 cycles
Block of 1024KB: 13 22 42 83 170 227 227 230 233 240 250 cycles
Block of 2048KB: 14 22 42 83 170 228 229 232 237 246 266 cycles
Block of 4096KB: 14 22 42 83 170 228 229 232 238 248 272 cycles
Block of 8192KB: 13 22 42 83 170 228 230 233 238 249 273 cycles
Block of 16384KB: 14 22 42 83 170 228 230 233 239 250 274 cycles
Block of 32768KB: 13 22 42 83 170 228 230 233 239 250 275 cycles
This system appears to have 2 cache levels (enabled).
L1 cache (64KB) speed (MB/s): Read=19008.8, Write=15718.4
L2 cache (512KB) speed (MB/s): Read=6511.3, Write=6629.0
Main memory speed (MB/s): Read=1494.9, Write=741.5


und nun
2.0 2-2-7

Cache size/Memory speed info tool 2.65MMX - (c) 1999-2001, LRMS - DJGPP compiled
CPUID support detected... 'AuthenticAMD' with FPU TSC MMX
Family=6 Model=10 Step=0 Type=0 Chipset (Vendor/Device ID(Rev)): VIA/3189(00)
CPU clock: 2187.5 MHz
Using 32MB physical memory block (alignment = 32)
Bandwidth - MMX linear access test... Read/Write/Copy (MB/s)
Block of 1KB: 19072.3 / 16688.0 / 22362.6
Block of 2KB: 18026.3 / 15881.9 / 23283.3
Block of 4KB: 18527.0 / 15846.1 / 23769.4
Block of 8KB: 18799.7 / 15779.3 / 24019.4
Block of 16KB: 18927.5 / 15736.5 / 24146.7
Block of 32KB: 19008.7 / 15724.8 / 23330.8
Block of 64KB: 18953.5 / 15593.8 / 5916.2
Block of 128KB: 6506.8 / 6623.2 / 5896.9
Block of 256KB: 6508.7 / 6626.3 / 5898.2
Block of 512KB: 6513.1 / 6631.3 / 819.8
Block of 1024KB: 1525.4 / 710.3 / 813.5
Block of 2048KB: 1502.5 / 730.8 / 810.7
Block of 4096KB: 1494.9 / 736.9 / 809.8
Block of 8192KB: 1492.3 / 740.3 / 809.3
Block of 16384KB: 1490.7 / 741.3 / 809.0
Block of 32768KB: 1489.3 / 741.8
Latency - Memory walk tests... ("pointer chasing")
Null size: 4 cycles 1 cycles (overhead 66 cycles)
steps: 4 8 16 32 64 128 256 512 1k 2k 4k (bytes)
Block of 1KB: 4 4 4 4 4 4 4 4 - - - cycles
Block of 2KB: 4 4 4 4 4 4 4 4 4 - - cycles
Block of 4KB: 4 4 4 4 4 4 4 4 4 4 - cycles
Block of 8KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 16KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 32KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 64KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 128KB: 4 5 9 18 20 20 20 20 20 20 20 cycles
Block of 256KB: 4 5 9 18 20 20 20 20 20 20 20 cycles
Block of 512KB: 4 5 9 18 20 20 20 20 20 20 20 cycles
Block of 1024KB: 14 22 42 83 171 227 228 230 233 240 250 cycles
Block of 2048KB: 13 22 42 83 171 229 229 232 237 248 266 cycles
Block of 4096KB: 13 22 42 83 171 230 229 233 238 249 271 cycles
Block of 8192KB: 13 22 42 83 171 229 230 233 239 249 274 cycles
Block of 16384KB: 14 22 42 83 171 230 230 233 239 250 274 cycles
Block of 32768KB: 13 22 42 83 171 229 230 233 239 250 274 cycles
This system appears to have 2 cache levels (enabled).
L1 cache (64KB) speed (MB/s): Read=19008.7, Write=15724.8
L2 cache (512KB) speed (MB/s): Read=6508.7, Write=6626.3
Main memory speed (MB/s): Read=1490.7, Write=741.3

[Performer]

Wird zwar nicht sooo interessieren, aber bei UT2003, hat mir das Umstellen von 2-2-2-3 auf 2-2-2-11 1.05% mehr fps beim Pyramide Demo gebracht.

Wie testest du das ? Bei mir steigen die Frames bis zum fünften Durchlauf an ! Normal ?

[GloomY]

Vielen Dank für eure Mühe für die vielen Tests, aber ich kann aus den Zahlen keine Bestätigung meiner These herauslesen. Vergesst es also und nehmt es so hin, wie es nun ist.

[Sephiroth]

@GloomY
ich weis nich so recht mit den Zahlen von mir etwas anzufangen :(
Ich vermute mal, daß 2.0 2-2-7 schlechter ist als 2.0 2-2-6 im Bezug auf die gebenchten Werte - oder?

[GloomY]

Original geschrieben von Sephirot
@GloomY
ich weis nich so recht mit den Zahlen von mir etwas anzufangen :(
Ich vermute mal, daß 2.0 2-2-7 schlechter ist als 2.0 2-2-6 im Bezug auf die gebenchten Werte - oder? Ja, aber nur ganz gering. Die Latenz ist praktisch gleich, die Durchsatzwerte geringfügig höher als bei einer tRAS von 7.

[robko]

wie wärs wenn du in deine betrachtungen mal die schon erwähnten bios versionen mit einbeziehst, da soll sich ja in verschiedenen versionen schon einiges getan haben. auch wenn es von hersteller zu hersteller keine größeren unterschiede geben sollte ??? weil das bios ja von nvidia kommt.

[Madkiller]

Original geschrieben von Performer
Wie testest du das ? Bei mir steigen die Frames bis zum fünften Durchlauf an ! Normal ?

Also wenn ich das Demo das 1. Mal durchlaufen lasse, habe ich etwa 2% fps zu wenig..
Beim 2. Mal, passt der Wert dann, und IIRC hält sich dieser Wert dann auch die darauf folgenden Male.

Nur man darf anscheinend, zwischen dem 1. und 2. Mal nicht aus UT2003 rausgehen, sonst fängt das Spiel wieder von vorne an :|

[GloomY]

update: http://www.hardtecs4u.com/reviews/2003/ddr400_roundup/index4.php

Das ist eine mögliche Erklärung, ich muss mir die Sache aber nochmal genau durchlesen...

[Kurgan]

Original geschrieben von GloomY
update: http://www.hardtecs4u.com/reviews/2003/ddr400_roundup/index4.php

Das ist eine mögliche Erklärung, ich muss mir die Sache aber nochmal genau durchlesen...

habs grade gelesen .. leider reicht mein basiswissen eigentlich nicht aus, aber dich drauf hinweisen hätte ich schon als pflicht empfunden ... ;)