Servercommunity Foren-Übersicht Servercommunity
Das informative Forum für Fragen rund um Server
 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen   RegistrierenRegistrieren 
 ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

"PING-Versteher" gesucht
Gehe zu Seite 1, 2  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Servercommunity Foren-Übersicht -> Alles andere
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
dl7awl



Anmeldedatum: 22.06.2003
Beiträge: 536
Wohnort: Berlin/Nackel

BeitragVerfasst am: Di Jul 26, 2005 16:17    Titel: "PING-Versteher" gesucht Antworten mit Zitat

Moin allerseits,

'tschuldigung, dass ich die Sommerloch-Ruhe störe, aber ich habe doch tatsächlich eine ganz ernsthafte Frage, noch dazu von geradezu "wissenschaftlichen" Dimensionen.

Ausgangspunkt sind sporadische sekundenlange Paket-Hänger auf meiner Sat-Strecke, und im NOC (Network Operation Center) hieß es, um der Sache auf den Grund gehen zu können, bräuchte man statistische Daten (Zeiten, Auftretenshäufigkeiten usw.), - was ja auch irgendwie nachvollziehbar ist.

Also habe ich mein heimisches Sat-Terminal fast 2 Wochen lang regelmäßig alle 10 Sekunden von außen (von meinem Server bei IPX aus) angePINGt und die Reaktionszeiten protokolliert. Also auf dem Server zu einer definierten Zeit "t=0" folgendes eingegeben:
Code:
nohup ping -vi 10 <IP-Nr.>

"nohup" (no hangup) sorgt dafür, dass die Sache über das Ende der SSH-Sitzung hinaus weiterläuft; die Ausgabe wird dann in eine Datei nohup.out geschrieben. Das sieht dann so aus (die ersten der rund 100.000 Zeilen):
Code:
PING <IP-Nr.> (<IP-Nr.>) 56(84) bytes of data.
64 bytes from <IP-Nr.>: icmp_seq=1 ttl=53 time=1663 ms
64 bytes from <IP-Nr.>: icmp_seq=2 ttl=53 time=783 ms
64 bytes from <IP-Nr.>: icmp_seq=3 ttl=53 time=764 ms
64 bytes from <IP-Nr.>: icmp_seq=4 ttl=53 time=845 ms
64 bytes from <IP-Nr.>: icmp_seq=5 ttl=53 time=786 ms
64 bytes from <IP-Nr.>: icmp_seq=6 ttl=53 time=1677 ms
64 bytes from <IP-Nr.>: icmp_seq=7 ttl=53 time=768 ms
64 bytes from <IP-Nr.>: icmp_seq=8 ttl=53 time=1619 ms
64 bytes from <IP-Nr.>: icmp_seq=9 ttl=53 time=1639 ms
64 bytes from <IP-Nr.>: icmp_seq=10 ttl=53 time=780 ms
64 bytes from <IP-Nr.>: icmp_seq=11 ttl=53 time=2521 ms
64 bytes from <IP-Nr.>: icmp_seq=12 ttl=53 time=1642 ms


Beileidsbesuche wegen dieser Ping-Zeiten sind jederzeit willkommen; bitte vorher anrufen und Grillgut sowie geeignete Getränke mitbringen Wink

Spaß beiseite: wenn man kein DSL bekommt, ist so ein Satelliten-Breitbandzugang schon ein wahrer Segen. Wenn man nicht gerade Gamer ist, stören die laufzeitbedingten Verzögerungen in der Praxis weniger als man denkt. Ich kann gut damit leben und möchte den Zugang nicht mehr missen. Andererseits: nur bis rund 7xx ms sind durch Signallaufzeiten bedingt und damit physikalisch unvermeidlich. Alles was nennenswert darüber hinausgeht, ist bereits Teil des zu untersuchenden Problems!

Nun will ich die Datenfülle mit Hilfe eines kleinen Progrämmchens sinnvoll aufbereiten und z.B. in eine Excel-taugliche CSV-Datei schreiben. Aber da fehlt noch die Zeitangabe. PING protokolliert ja leider bei den Einzel-Ereignissen keine Zeit; ich habe auch keine Möglichkeit gefunden, ihm das beizubringen. Also muss mein Progrämmchen für jede Zeile die Zeit nun nachträglich anhand der Startzeit rekonstruieren. Im Prinzip ganz einfach, wenn man sinnvollerweise gleich mit Unix-Epoch-Werten rechnet:
Code:
Zeilen-Zeit = Startzeit + (icmp_seq_Nummer - 1) * 10


Eine exakte sekundengenaue Zuordnung ist bei dieser Vorgehensweise leider sowieso nicht zu erwarten, da u.a. niemand weiß, wie genau PING den 10-Sek-Rhythmus einhält. Selbst minimale Fehler würden sich im Laufe der Zeit summieren. Um ein etwaiges Auseinanderlaufen von tatsächlicher und rekonstruierter Zeit nachträglich feststellen und korrigieren zu können, habe ich während des laufenden Tests gelegentlich icmp_seq-Nummern und deren jeweilige Uhrzeiten notiert, sozusagen "feste Zeitpflöcke eingeschlagen". Um es vorweg zu nehmen: Die damit ermittelten unkorrigierten Roh-Abweichungen blieben mit +- 25 Sekunden zwar noch in einem vertretbaren, aber doch irgendwie erklärungsbedürftigen Bereich.

Hier stellen sich z.B. Fragen nach dem genauen Verhalten des PING-Programms, die ich hiermit an die Linux-Gurus richte:

1. Das Ping-Intervall beträgt wie erwähnt 10 Sekunden. Was aber ist mit den Folge-Pings, wenn das Echo länger als 10 Sekunden auf sich warten lässt? (es kamen Reaktionszeiten bis über 60 Sekunden vor!!!) Wird auch dann stur zur "fälligen" Zeit erneut gepingt, oder geht der nächste Ping immer erst raus, wenn die Reaktion vom vorigen da ist? Und falls ja, folgt er unmittelbar auf das Echo oder bleibt er im 10-Sek-Raster?
Ich könnte auch fragen: wie wirken sich Reaktionszeiten>10 Sek. auf das icmp_seq-Nummerierungsschema aus?

2. Die icmp_seq-Nummer in den protokollierten Zeilen zählt nicht stur und monoton vorwärts. Es wurden zuweilen Nummern scheinbar "übersprungen", ohne dass der Grund erkennbar ist. Es besteht diesbezüglich auch keine klare Korrelation zum vorigen Punkt, etwa dass bei Reaktionszeiten >10 Sek. immer entsprechend viele Pings ausgelassen worden wären. Ich habe nur eins herausgefunden: ich muss offenbar die übersprungenen Nummern mitzählen, ansonsten entfernen sich die rekonstruierten Zeiten zu sehr von den tatsächlichen. Das kann ja eigentlich nur bedeuten, dass im Falle übersprungener Nummern das Echo ganz ausgeblieben ist. Oder wie würdet Ihr das deuten?

3. Einmal kam eine "unmögliche" Reaktionszeit von 0.000 ms vor - auch irgendwie komisch, andererseits aber auch vernachlässigbar, da nur 1x unter >100.000 Pings.

Um das Ganze zu illustrieren, hier mal ein besonders "kritischer" - um nicht zu sagen blamabler - Ausschnitt, bei dem sowohl Zeiten > 10 Sek. als auch übersprungene icmp_seq-Nummern vorkommen:
Code:
64 bytes from <IP-Nr.>: icmp_seq=50732 ttl=54 time=783 ms
64 bytes from <IP-Nr.>: icmp_seq=50733 ttl=54 time=764 ms
64 bytes from <IP-Nr.>: icmp_seq=50734 ttl=54 time=786 ms
64 bytes from <IP-Nr.>: icmp_seq=50735 ttl=54 time=766 ms
64 bytes from <IP-Nr.>: icmp_seq=50738 ttl=54 time=22401 ms
64 bytes from <IP-Nr.>: icmp_seq=50739 ttl=54 time=27982 ms
64 bytes from <IP-Nr.>: icmp_seq=50740 ttl=54 time=33444 ms
64 bytes from <IP-Nr.>: icmp_seq=50750 ttl=54 time=7561 ms
64 bytes from <IP-Nr.>: icmp_seq=50751 ttl=54 time=821 ms
64 bytes from <IP-Nr.>: icmp_seq=50752 ttl=54 time=9323 ms
64 bytes from <IP-Nr.>: icmp_seq=50753 ttl=54 time=18304 ms
64 bytes from <IP-Nr.>: icmp_seq=50754 ttl=54 time=20735 ms
64 bytes from <IP-Nr.>: icmp_seq=50756 ttl=54 time=37737 ms
64 bytes from <IP-Nr.>: icmp_seq=50757 ttl=54 time=32798 ms
64 bytes from <IP-Nr.>: icmp_seq=50758 ttl=54 time=27939 ms
64 bytes from <IP-Nr.>: icmp_seq=50759 ttl=54 time=27009 ms
64 bytes from <IP-Nr.>: icmp_seq=50764 ttl=54 time=41384 ms
64 bytes from <IP-Nr.>: icmp_seq=50765 ttl=54 time=33954 ms
64 bytes from <IP-Nr.>: icmp_seq=50769 ttl=54 time=2385 ms
64 bytes from <IP-Nr.>: icmp_seq=50770 ttl=54 time=10567 ms
64 bytes from <IP-Nr.>: icmp_seq=50771 ttl=54 time=20949 ms
64 bytes from <IP-Nr.>: icmp_seq=50773 ttl=54 time=34812 ms
64 bytes from <IP-Nr.>: icmp_seq=50776 ttl=54 time=46946 ms
64 bytes from <IP-Nr.>: icmp_seq=50777 ttl=54 time=47008 ms
64 bytes from <IP-Nr.>: icmp_seq=50778 ttl=54 time=47288 ms
64 bytes from <IP-Nr.>: icmp_seq=50779 ttl=54 time=48249 ms
64 bytes from <IP-Nr.>: icmp_seq=50781 ttl=54 time=50892 ms
64 bytes from <IP-Nr.>: icmp_seq=50782 ttl=54 time=52411 ms
64 bytes from <IP-Nr.>: icmp_seq=50785 ttl=54 time=54162 ms
64 bytes from <IP-Nr.>: icmp_seq=50786 ttl=54 time=54164 ms
64 bytes from <IP-Nr.>: icmp_seq=50792 ttl=54 time=48947 ms
64 bytes from <IP-Nr.>: icmp_seq=50795 ttl=54 time=45039 ms
64 bytes from <IP-Nr.>: icmp_seq=50797 ttl=54 time=42811 ms
64 bytes from <IP-Nr.>: icmp_seq=50804 ttl=54 time=772 ms
64 bytes from <IP-Nr.>: icmp_seq=50805 ttl=54 time=755 ms
64 bytes from <IP-Nr.>: icmp_seq=50806 ttl=54 time=755 ms

Wer kann das deuten, bzw. das Verhalten des PING-Programms erklären? Oder vielleicht doch lieber ein Beileidsbesuch?? Wink

Gruß, Manfred
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Dennis
Junior-Chef


Anmeldedatum: 21.06.2003
Beiträge: 2344
Wohnort: Schömberg (zw. Stuttgart u . Karlsruhe)

BeitragVerfasst am: Mi Jul 27, 2005 07:44    Titel: Antworten mit Zitat

Beileid Wink
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Boum



Anmeldedatum: 29.07.2003
Beiträge: 1929
Wohnort: Karlsruhe

BeitragVerfasst am: Mi Jul 27, 2005 08:20    Titel: Antworten mit Zitat

Auch Beileid...

Aber jetzt mal was inhaltliches Wink

Ich habe 2 Sachen gemacht. Erstens habe ich meine Netzwerk-Kenntnisse von Zeiten der letzten Prüfung zum Thema ausgegraben (die noch nicht soo urlange zurückliegt, wie man vielleicht denken könnte...) und zweitens mir den Quellcode des Original-Ping-Programms von 1983 angeschaut... Hier:

http://ftp.arl.mil/~mike/ping.html

So. Zwei Arbeitshypothesen müssen wir jetzt schlucken, dann können wir an's Werk. Erstens: dass das Ping, das Du verwendet hast, im Verhalten etwa mit dem oben angegebenen übereinstimmt. Und zweitens, dass meine Kenntnisse noch einigermassen frisch sind und ich nix Wildes übersehen habe (ok, das waren jetzt eigentlich 3 Hypothesen. Egal).

Erstens. Die Pings werden über ein Signal abgeschickt, das mit der angeforderten Frequenz vom OS generiert wird. Insofern ist es "ping" Wumpe, ob davor ein Ping angekommen ist, stecken geblieben oder sonst was Schlimmes passiert ist (wie zum Beispiel ein Nuklearangriff auf das ARPA-Net). Zu diesem erstens passt prima, dass die Ausgabe in einem Handler erfolgt, der einfach (wenn die Antwort von "uns" ist) die ICMP-Daten ausspuckt. Egal, welche Nummer das Paket trägt, und was davor Schlimmes passiert ist (wie zum Beispiel ein Nuklearangriff auf das ARPA-Net).

Zweitens. ICMP ist ein Teil des IP-Protokolls. Oder setzt direkt darauf auf, wie man es betrachten will. Ja, IP. Nicht TCP, nicht UDP, sondern nackiges IP. Und dort ist die Welt ja sowas von gar nicht in Ordnung... Reihenfolge der Pakete? Keine Ahnung. Vielleicht. Pakete sollen ankommen? Schuldigung, da müssen sie schon Kollege TCP fragen. Ich als einfaches IP weiss nur, wo ich das Paket langschicken soll... und zwar egal, was passiert (wie zum Beispiel ein Nuklearangriff auf das ARPA-Net). Anders formuliert: Nummern, die übersprungen werden, sind hier an der Tagesordnung auf "schlechten" Verbindungen. Out-of-order-Pakete (also die 234 vor der 230) können auch passieren, sind aber unwahrscheinlicher. Ganz schlecht wären doppelte ICMP_SEQs... "Ausgefallene" Nummern heissen dann einfach, Paket (hin oder zurück) ist unterwegs verloren gegangen. Dadurch, dass Du "Löcher" in den Sequenznummern hast, würde ich darauf schließen, dass die Verbindung zeitweilig ausfällt (sonst müssten die ja out-of-band ankommen).

Drittens. Der Quellcode gibt unumwunden zu, dass der Timer der üblichen Skew unterworfen ist, insofern wäre ab und zu ein Timestamp hilfreich gewesen (damit man wenigstens die Gesamtdauer hat)...

Viertens. Eine Reaktionszeit von 0? Cool, ein Bug in Ping!! Entweder ein Überlauf (glaube ich nicht), oder eine Hardware-Fehlfunktion... KA.

Hilft das ein bisschen weiter? Ich fürchte, nicht genug. Aber vielleicht ein wenig...
_________________
Planung ist das Ersetzen des Zufalls durch Irrtum.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name
AndyG



Anmeldedatum: 29.06.2003
Beiträge: 603
Wohnort: Ruhrpott

BeitragVerfasst am: Mi Jul 27, 2005 08:52    Titel: Antworten mit Zitat

Hi,
nur mal ne kleine Anmerkung von einem "NichtPingVersteher" Wink

Warum machst du das ganze nicht über ein Shell Script. Du schreibst zuerst den Timestamp und danach die Pingausgabe in eine Datei und rufst das ganze alle 10sec. über Cron auf.

Irgendwas überseh ich da wieder garantiert, so einfach ist das bestimmt nicht Rolling Eyes
_________________
Gruß
Andy

Das Leben ist gefährlich,.....,man kann dabei umkommen....!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Boum



Anmeldedatum: 29.07.2003
Beiträge: 1929
Wohnort: Karlsruhe

BeitragVerfasst am: Mi Jul 27, 2005 08:59    Titel: Antworten mit Zitat

Damit kriegst Du nur Deine "eigenen" Pings. Wenn sich damit 2 Pings "überkreuzen", wird das OS die Prozesse sequentialisieren, da sie beide ihre ausgabe in den gleichen Stream pipen wollen. Möööglicherweise funktioniert es trotzdem, ich weiss aber nicht, an welcher Stelle ein Shellscript dabei angehalten würde... ob erst "date" ausgeführt würde, und dann blockiert, oder der 2. Prozess nicht komplett "auf Eis liegt"...
_________________
Planung ist das Ersetzen des Zufalls durch Irrtum.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name
dl7awl



Anmeldedatum: 22.06.2003
Beiträge: 536
Wohnort: Berlin/Nackel

BeitragVerfasst am: Mi Jul 27, 2005 10:38    Titel: Antworten mit Zitat

Die Sonne geht auf! Vielen Dank für Eure Mühe und Beileidsbekundungen! Very Happy

@Andy: Sowas in der Art hatte ich nachträglich auch überlegt. Aber eben nachträglich - hinterher ist man ja immer schlauer. Die Daten liegen ja leider bereits vor; erfasst während meiner Kurzurlaubs-Abwesenheit, damit keine schwankende Inanspruchnahme der Bandbreite meinerseits das Ergebnis verfälschen konnte. Eine erneute Messperiode unter ähnlich günstigen Bedingungen wäre nicht praktikabel, deshalb muss ich nun aus den vorhandenen Messdaten das beste machen - was ja auch mit hinreichender Aussagekraft möglich sein wird.

@Boum: O doch, es ist sehr hilfreich. Insbesondere sehe ich mich in der Vermutung bestätigt, dass übersprungene Nummern als Verluste zu werten sind. Somit müsste ich diese in der Auswertung ja eigentlich als "unendliche" Reaktionszeit werten, also sagen wir mal der obersten Kategorie ">60 Sek" zuordnen anstatt sie, wie zunächst erwogen, einfach ganz unberücksichtigt zu lassen. Die Gesamtstatistik wird dann freilich noch ungünstiger ausfallen, denn die Verlustquote liegt bei immerhin 5%. (Allerdings einschl. eines bekannten Stromausfalls, den ich noch rausrechnen muss).

Generell sehe ich auf jeden Fall Handlungs- oder zumindest Erklärungsbedarf seitens des Sat-Netzbetreibers. Selbst wenn man verlorene Pakete gar nicht wertet, sind rund 8% aller PINGs länger als 1600 ms unterwegs, also mehr als das Doppelte der physikalisch bedingten Laufzeit! Noch viel größere Zeiten (>5 Sek) liegen hingegen nur bei 0,1% oder darunter und haben vermutlich überwiegend eine temporäre Netzwerkstörung als Ursache, denn sie konzentrieren sich im Wesentlichen auf einen eng begrenzten Zeitraum um den obigen Ausschnitt herum und scheinen ansonsten praktisch nicht vorzukommen. Eine solche temporäre Störung muss ja noch nicht mal beim Sat-Netzbetreiber selbst gelegen haben.

Nun ja, ich werde mich mal an die weitere Aufbereitung der Ergebnisse machen...

Schöne Grüße einstweilen und nochmals Dank für die Mühe,

Manfred

P.S.: Da ich selbst Anbieter für 2-Wege-Sat-Internetzugänge bin, frage ich mich natürlich, ob ich meinem Geschäft nicht schade, wenn ich diese Dinge hier ausbreite. Aber es geschieht ja mit dem Ziel der Abstellung und ist somit eigentlich Handeln im Interesse aller gegenwärtigen und potenziellen Nutzer. Irgendjemand muss es ja mal thematisieren; unter-den-Teppich-kehren ist ja auch keine Lösung. Und ansonsten bin ich von der Technik und deren unerschütterlicher Zuverlässigkeit - auch nach über 1jähriger Nutzungszeit - uneingeschränkt überzeugt.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Boum



Anmeldedatum: 29.07.2003
Beiträge: 1929
Wohnort: Karlsruhe

BeitragVerfasst am: Mi Jul 27, 2005 11:01    Titel: Antworten mit Zitat

Öh... noch ne blöde Frage zum Schluss: wenn man den Ping-Befehl nicht gerade mit einem -9 abschliesst, gibt er einem noch die Statistik zum Schluss aus... Also so was da:
Code:

--- Rechner.Provider.tld ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.293/0.362/0.507/0.085 ms

...hast Du die zufällig noch? Könnten ja dann zum Abgleich der Excel- mit den von Ping ermittelten Daten herhalten (modulo Stromausfall...).
_________________
Planung ist das Ersetzen des Zufalls durch Irrtum.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name
dl7awl



Anmeldedatum: 22.06.2003
Beiträge: 536
Wohnort: Berlin/Nackel

BeitragVerfasst am: Mi Jul 27, 2005 11:54    Titel: Antworten mit Zitat

Leider nicht. Ich weiß momentan nicht genau, welches Signal "kill" abgibt, wenn es, wie ich es getan habe, ohne explizite SIG-Angabe aufgerufen wird. Jedenfalls war es offenbar nicht dasjenige, was Ping gebraucht hätte, um die Statistik auszugeben. Schade.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MaXle



Anmeldedatum: 24.10.2003
Beiträge: 156

BeitragVerfasst am: Mi Jul 27, 2005 13:39    Titel: Antworten mit Zitat

Zitat:
Wenn man nicht gerade Gamer ist, stören die laufzeitbedingten Verzögerungen in der Praxis weniger als man denkt.


Mein Cousa (wohnt 100m neben mir) hat mit ISDN (glaub keine Kabelbündelung) nen Ping der um ca 20ms besser ist als meiner mit normalen DSL... Question Erklärung?!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Henning



Anmeldedatum: 23.06.2003
Beiträge: 1541
Wohnort: Vienna, AT

BeitragVerfasst am: Do Jul 28, 2005 16:17    Titel: Antworten mit Zitat

Deine Stichwörter sind:
- Interleaving
und
- Fastpath
_________________
Hallooooo Spongebob!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Fritz11



Anmeldedatum: 20.07.2003
Beiträge: 605
Wohnort: Lehrte/Hannover

BeitragVerfasst am: Do Jul 28, 2005 20:12    Titel: Antworten mit Zitat

MaXle hat Folgendes geschrieben:
Mein Cousa (wohnt 100m neben mir)...

Hi Maxle,
neben ist nicht gleich neben! Es kommt schon auf die Himmelsrichtung an!
siehe http://www.feng-shui.de/einfuehrung/glossar/ Baghua-Methode und Kompaßschule...

Zitat:
Kompaßschule - Richtung des Feng Shui, derzufolge Richtungen sowie räumliche und zeitliche Orientierung im Raum bestimmte Qualitäten und Einflüsse haben. Diese Qualitäten werden mittels des Luo Pan erforscht.


Gruss Fritz
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Henning



Anmeldedatum: 23.06.2003
Beiträge: 1541
Wohnort: Vienna, AT

BeitragVerfasst am: Do Jul 28, 2005 21:46    Titel: Antworten mit Zitat

Oh Gott, Fritz! Shocked
Daran hab ich gar nicht gedacht...
Unter Umständen ist die Latenzzeit wegen den gefährlichen Wasseradern und der Störung des sog. Ping/Yang so schlecht?!
_________________
Hallooooo Spongebob!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Harry
Crash Kid


Anmeldedatum: 21.06.2003
Beiträge: 1873

BeitragVerfasst am: Do Jul 28, 2005 22:00    Titel: Antworten mit Zitat

Henning hat Folgendes geschrieben:
des sog. Ping/Yang


Hieß das nich "Ping/Pong" ?! Question Rolling Eyes
_________________
Auf der Suche nach einer neuen Signatur...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
nobody



Anmeldedatum: 23.06.2003
Beiträge: 462

BeitragVerfasst am: Fr Jul 29, 2005 10:10    Titel: Antworten mit Zitat

Harry hat Folgendes geschrieben:

Hieß das nich "Ping/Pong" ?! Question Rolling Eyes


nein, Harry Ping/Pong ist ein Spiel, welches auch als Pong bekannt ist, und du willst doch wohl nich das Ping/Yang mit einem so extrem anspruchs vollen Spiel vergleichen.
_________________
Rechtschreibfehler gefunden? Pech, ich darf das. Ärztlich beglaubigter Legastekniker eh legassthenicker ..ehr auch scheiß wort. ich darf dat
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Harry
Crash Kid


Anmeldedatum: 21.06.2003
Beiträge: 1873

BeitragVerfasst am: Fr Jul 29, 2005 10:47    Titel: Antworten mit Zitat

Verzeih, du hast natürlich recht, ich hab mich da in einem schwachen Moment von meiner Einfälltigkeit übermannen lassen Sad
_________________
Auf der Suche nach einer neuen Signatur...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Servercommunity Foren-Übersicht -> Alles andere Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite 1, 2  Weiter
Seite 1 von 2

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.



Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de