Netzwerke

On Mon, 11 Jul 2005 17:49:10 +0200, "Klaus Selver"
wrote:

>Und selbst wenn es ein nichtzuvermeidendes "Funkloch"
>gibt, dann kann man den grade nicht übertragbaren Frame
>doch in den Puffer zwischenspeichern und ein paar ms später
>senden.

Natürlich, es wird der ganze Block einfach erneut gesendet. Denn
ansonsten....

>Habe grade mal einen großen Download gestartet.
>Wenn ich mir im WindowsTaskmonitor/Netzwerk den Durchsatz
>anschaue, sehe ich alle 10 Sek. eine kurze Lücke, die nicht da ist,
>wenn ich per Kabel verbunden bin.

... würde dein Download ja immer nach 10 sec abgebrochen werden.
Dieses erneute Senden findet übrigens über Kabel ebenfalls statt, da
dort aus verschiedenen Gründen ebenfalls Pakete verloren gehen, zB bei
Collisions (Stichwort: Hub statt Switch), wenn ich mich recht an die
weit zurückliegende ISO-Schichtenmodell-Vorlesung erinnere.

Dies wird jedoch bei den Pings nicht gemacht, denn genau bei einem
Ping will man genau das sehen, was auf der Strecke verloren geht.

Hast du übrigens schon mal getestet, wie es sich verhält, wenn du fix
auf verschiedene Kanäle stellst?

lg jens

"Jens Hoerburger"

schrieb im Newsbeitrag news:kg65d19qcj3v4mpqj1cm4vs80h4pcvc1h9@4ax.com...
> On Mon, 11 Jul 2005 17:49:10 +0200, "Klaus Selver"
> wrote:
>
> >Und selbst wenn es ein nichtzuvermeidendes "Funkloch"
> >gibt, dann kann man den grade nicht übertragbaren Frame
> >doch in den Puffer zwischenspeichern und ein paar ms später
> >senden.
>
> Natürlich, es wird der ganze Block einfach erneut gesendet. Denn
> ansonsten....
>
> >Habe grade mal einen großen Download gestartet.
> >Wenn ich mir im WindowsTaskmonitor/Netzwerk den Durchsatz
> >anschaue, sehe ich alle 10 Sek. eine kurze Lücke, die nicht da ist,
> >wenn ich per Kabel verbunden bin.
>
> ... würde dein Download ja immer nach 10 sec abgebrochen werden.
> Dieses erneute Senden findet übrigens über Kabel ebenfalls statt, da
> dort aus verschiedenen Gründen ebenfalls Pakete verloren gehen, zB bei
> Collisions (Stichwort: Hub statt Switch), wenn ich mich recht an die
> weit zurückliegende ISO-Schichtenmodell-Vorlesung erinnere.

Darum geht es nicht.
Natürlich wiederholt TCP den Frame, aber nur weil die Schicht
darunter den Fehler gemacht hat.
Ich meinte, dass WLAN vor dem Unterbrecher den Frame speichern
sollte, wenn ein Funkloch unvermeidbar sein sollte.

> Dies wird jedoch bei den Pings nicht gemacht, denn genau bei einem
> Ping will man genau das sehen, was auf der Strecke verloren geht.

Narürlich ist das sooo!

> Hast du übrigens schon mal getestet, wie es sich verhält, wenn du fix
> auf verschiedene Kanäle stellst?

Ja, hab ich probiert, bringt aber auch keine Verbesserung.
Umschaltung auf 11MBit/54MB verändert zwar den Durchsatz,
die Fehler bleiben aber.

-Klaus-

Klaus Selver wrote:
> [...]
> Ich meinte, dass WLAN vor dem Unterbrecher den Frame speichern
> sollte, wenn ein Funkloch unvermeidbar sein sollte.

Wird gemacht, nennt sich ARQ. Ist hier ganz gut erklärt:

http://www.broadband.ie.cuhk.edu.hk/htdocs bkmay2004/research/paper/Namicc2002.pdf

Dein Kanal ist also periodisch alle 10 Sekunden für einen längeren Zeitraum
gestört bzw. der Client solange nicht empfangsbereit, so dass ARQ dafür
nicht mehr ausreicht.

Tritt das Problem eigentlich bei Übertragungen in beide Richtungen auf?

Grüße,
Sebastian

"Sebastian Wimmer" schrieb im Newsbeitrag
news:3jfslpFpmv0uU1@individual.net...
> Klaus Selver wrote:
> > [...]
> > Ich meinte, dass WLAN vor dem Unterbrecher den Frame speichern
> > sollte, wenn ein Funkloch unvermeidbar sein sollte.
>
> Wird gemacht, nennt sich ARQ. Ist hier ganz gut erklärt:
>
>
http://www.broadband.ie.cuhk.edu.hk/htdocs bkmay2004/research/paper/Namicc20
02.pdf

So hatte ich mir das eigentlich vorgestellt, aber es schein nicht zu
funktionieren,
zumindest nicht mit meinen Geräten...

> Dein Kanal ist also periodisch alle 10 Sekunden für einen längeren
Zeitraum
> gestört bzw. der Client solange nicht empfangsbereit, so dass ARQ dafür
> nicht mehr ausreicht.

Nein, der Kanal ist alle 10 Sekunden sehr kurz (d.h. für einen Frame) nicht
durchlässig.

> Tritt das Problem eigentlich bei Übertragungen in beide Richtungen auf?

Momentan weiß ich nicht, wie ich das feststellen könnte.

-Klaus-

Klaus Selver wrote:
>> Wird gemacht, nennt sich ARQ. Ist hier ganz gut erklärt:
>>
> http://www.broadband.ie.cuhk.edu.hk/htdocs bkmay2004/research/paper/Namicc20
> 02.pdf
>
> So hatte ich mir das eigentlich vorgestellt, aber es schein nicht zu
> funktionieren,
> zumindest nicht mit meinen Geräten...

Es funktioniert, verlass Dich drauf. Sonst hättest Du nicht nur alle 10
Sekunden ein verlorenes Paket.

>> Dein Kanal ist also periodisch alle 10 Sekunden für einen längeren
>> Zeitraum gestört bzw. der Client solange nicht empfangsbereit, so
>> dass ARQ dafür nicht mehr ausreicht.
>
> Nein, der Kanal ist alle 10 Sekunden sehr kurz (d.h. für einen Frame)
> nicht durchlässig.

Dein verlorenes ICMP-Paket besteht aus 8000 Byte? Angenommen ARQ macht 3
Retransmissions und die Datenrate ist 11 MBit/s , dann müsste der Kanal für
ca. 32 kByte / 11 MBit/s = 3 ms gestört sein. Durchaus möglich.

>> Tritt das Problem eigentlich bei Übertragungen in beide Richtungen
>> auf?
>
> Momentan weiß ich nicht, wie ich das feststellen könnte.

Du hast doch an beiden Enden PCs? Ping in die andere Richtung!

Grüße,
Sebastian

Sebastian Wimmer wrote:
>
> Dein verlorenes ICMP-Paket besteht aus 8000 Byte? Angenommen ARQ
> macht 3 Retransmissions und die Datenrate ist 11 MBit/s , dann müsste
> der Kanal für ca. 32 kByte / 11 MBit/s = 3 ms gestört sein. Durchaus
> möglich.

Die Rechnung ist mehrfacher Quatsch. Bitte vergessen.

Neuer Ansatz:

Angenommen ARQ macht 3 Retransmissions, die Datenrate ist 11 MBit/s und die
Länge eines Frames 1500 Byte. Wenn 1500 Byte * 4 * 8 Bit / 11 MBit/s = ca. 4
ms lang der Frame nicht übertragen werden kann, wird er verworfen. Das
äussert sich bei Dir dann in einem "verlorenen" Ping.

Grüße,
Sebastian

"Sebastian Wimmer" schrieb im Newsbeitrag
news:3jfu5aFpqogkU1@individual.net...
> Klaus Selver wrote:
> >> Wird gemacht, nennt sich ARQ. Ist hier ganz gut erklärt:
> >>
> >
http://www.broadband.ie.cuhk.edu.hk/htdocs bkmay2004/research/paper/Namicc20
> > 02.pdf
> >
> > So hatte ich mir das eigentlich vorgestellt, aber es schein nicht zu
> > funktionieren,
> > zumindest nicht mit meinen Geräten...
>
> Es funktioniert, verlass Dich drauf. Sonst hättest Du nicht nur alle 10
> Sekunden ein verlorenes Paket.

AQR hat, lt. der Beschreibung, eine Fehlerrate von deutlich weniger
als 1 Prozent. Wenn ich einen Fehler sehe, müssten also vorher
über 100 aufgetreten und korrigiert worden sein. Das kann ich mir
nicht vorstellen.

> >> Dein Kanal ist also periodisch alle 10 Sekunden für einen längeren
> >> Zeitraum gestört bzw. der Client solange nicht empfangsbereit, so
> >> dass ARQ dafür nicht mehr ausreicht.
> >
> > Nein, der Kanal ist alle 10 Sekunden sehr kurz (d.h. für einen Frame)
> > nicht durchlässig.
>
> Dein verlorenes ICMP-Paket besteht aus 8000 Byte? Angenommen ARQ macht 3
> Retransmissions und die Datenrate ist 11 MBit/s , dann müsste der Kanal
für
> ca. 32 kByte / 11 MBit/s = 3 ms gestört sein. Durchaus möglich.

Das haut nicht ganz hin - Meine Fehler treten auch mit 1 K-Frames auf!

> >> Tritt das Problem eigentlich bei Übertragungen in beide Richtungen
> >> auf?
> >
> > Momentan weiß ich nicht, wie ich das feststellen könnte.
>
> Du hast doch an beiden Enden PCs? Ping in die andere Richtung!

Wenn du das so meinst.. Ja, andersrum hab ich die selben Fehler!

-Klaus-

Klaus Selver wrote:
>>>>
>>>> Wird gemacht, nennt sich ARQ. Ist hier ganz gut erklärt:
>>>>
>>>
> http://www.broadband.ie.cuhk.edu.hk/htdocs bkmay2004/research/paper/Namicc20
>>> 02.pdf
>>>
>>> So hatte ich mir das eigentlich vorgestellt, aber es schein nicht zu
>>> funktionieren,
>>> zumindest nicht mit meinen Geräten...
>>
>> Es funktioniert, verlass Dich drauf. Sonst hättest Du nicht nur alle
>> 10 Sekunden ein verlorenes Paket.
>
> AQR hat, lt. der Beschreibung, eine Fehlerrate von deutlich weniger
> als 1 Prozent.

Bei einem speziellen Experiment *ohne* periodischem Störer.
Das mag durchschnittlich gesehen eine realistische Annahme sein, trifft aber
in Deinem Fall nicht zu.

>> Dein verlorenes ICMP-Paket besteht aus 8000 Byte? Angenommen ARQ
>> macht 3 Retransmissions und die Datenrate ist 11 MBit/s , dann
>> müsste der Kanal für ca. 32 kByte / 11 MBit/s = 3 ms gestört sein.
>> Durchaus möglich.
>
> Das haut nicht ganz hin - Meine Fehler treten auch mit 1 K-Frames auf!

Natürlich.
Die Vermutung ist ganz einfach: Dein Kanal ist periodisch alle 10 Sekunden
für einen Zeitdauer im Millisekunden-Bereich gestört. Die Störung ist damit
so lange, dass sie durch ARQ nicht kaschiert werden kann. Du verlierst
mindestens einen Frame.

>> Du hast doch an beiden Enden PCs? Ping in die andere Richtung!
>
> Wenn du das so meinst.. Ja, andersrum hab ich die selben Fehler!

Das macht einen gestörten Kanal wahrscheinlicher.

Grüße,
Sebastian