Latenzzeiten in Bits von Switches ?
Manuel Weber
in Bits die folgende Switches haben ?
[Cut-through Switch] = 14 Byte = 112 Bit
= Präambel ( 8 Byte ) + Destination-MAC ( 6 Byte )
Dieser Switch liest nur bis zur Zieladresse und entscheidet
anhand dieser, ob das Paket zu senden oder zu verwerfen ist.
[FragmentFree Switch] = 64 Byte = 512 Bit
= Ethernet-Header ( 26 Byte ) + min. Ethernet-Daten ( 38 Byte )
... liest einen komplettes Collision-Window (64 Byte) ein.
[Store-and-Forward Switch] = Latenzzeit ist von Paketgröße abhängig,
da erst das komplette Paket gespeichert wird, bevor es weitergeleitet wird
Andre Beck
>
> Stimmen meine Antworten zur Frage, welche Latenzzeiten
> in Bits die folgende Switches haben ?
Argh, sieht nach Cisco-Fragen aus. Steht das nicht im Kursmaterial? Obwohl,
da steht auch was von Class A, B und C...
> [Cut-through Switch] = 14 Byte = 112 Bit
> = Präambel ( 8 Byte ) + Destination-MAC ( 6 Byte )
Kann man so sehen.
> Dieser Switch liest nur bis zur Zieladresse und entscheidet
> anhand dieser, ob das Paket zu senden oder zu verwerfen ist.
Wobei er dann *mindestens* 14 Byte Latenz hat, nicht *genau*. Der Zielport
muss nicht frei sein. Und die IPG muss man dort auch beachten. Und die
Geschwindigkeit muss auch stimmen. Kurz, man sollte zwischen einem cut-
through-, einem runt/fragment-free- und einem store-and-forward-Switching-
vorgang (per frame) unterscheiden, denn es gibt keine reinen cut-through-
bzw. frag-free-Switche, nur welche, die eine Teilmenge ihrer forwards so
ausführen können.
> [FragmentFree Switch] = 64 Byte = 512 Bit
> = Ethernet-Header ( 26 Byte ) + min. Ethernet-Daten ( 38 Byte )
> ... liest einen komplettes Collision-Window (64 Byte) ein.
Wenn ich jetzt grade noch wüsste, ob man die Präambel mit zu den 512 Bittimes
zählt, die ein minimales Ethernetpaket ergeben...
> [Store-and-Forward Switch] = Latenzzeit ist von Paketgröße abhängig,
> da erst das komplette Paket gespeichert wird, bevor es weitergeleitet wird
Yep.
BTW, de.comp.hardware.netzwerke wäre sicher eher OnTopic.
--
(this funny line intentionally left blank)
-----
-> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
Manuel Weber
Internetprotokolle.
> > [FragmentFree Switch] = 64 Byte = 512 Bit
> Wenn ich jetzt grade noch wüsste, ob man die Präambel mit zu den 512
Bittimes
> zählt, die ein minimales Ethernetpaket ergeben...
Hab' von Prof. nun die richtige Lösung:
FragmentFree Switch
Präambel ( 8 Bytes )
+ Destination-MAC ( 6 Bytes )
+ Source-MAC ( 6 Bytes )
+ Type/length ( 2 Bytes )
+ min Pak. ( 46 Bytes)
--------------------------------
= 68 Byte = 544 Bit
Andre Beck
>
> Nee, hat nix mit CISCO Seminar zu tun, ist eine Vorlesung über
> Internetprotokolle.
Naja, die Frage (insbesondere das Rumreiten auf frag free switching) roch
irgendwie schon nach Cisco-Prüfung.
> > > [FragmentFree Switch] = 64 Byte = 512 Bit
>
> > Wenn ich jetzt grade noch wüsste, ob man die Präambel mit zu den 512
> Bittimes
> > zählt, die ein minimales Ethernetpaket ergeben...
>
> Hab' von Prof. nun die richtige Lösung:
>
> FragmentFree Switch
>
>
> Präambel ( 8 Bytes )
>
> + Destination-MAC ( 6 Bytes )
>
> + Source-MAC ( 6 Bytes )
>
> + Type/length ( 2 Bytes )
>
> + min Pak. ( 46 Bytes)
>
> --------------------------------
>
> = 68 Byte = 544 Bit
Gibt's dazu auch eine Begründung? Am besten in der Ethernet-Literatur
nachzulesen? Ich hab mein schlaues Buch nicht zur Hand. Wie man ausge-
rechnet auf 68 Byte kommt, ist mir nämlich schleierhaft.
Manuel Weber
news:87sn9lw...@coredump.ibh.net...
> Naja, die Frage (insbesondere das Rumreiten auf frag free switching) roch
> irgendwie schon nach Cisco-Prüfung.
:-) Cisco CNA Netacademy gibts bei uns zwar auch, aber sowas wurde
bisher nicht behandelt.
> Gibt's dazu auch eine Begründung?
Tja, leider keine.
In [INTERNET WORKING] steht es werden nur die ersten 64 Bytes
(Collision Window) gepuffert, ausgewertet und überprüft.
Leider zählt im Zweifelsfall was der Prof. sagt.
Lutz Donnerhacke
>
>Tja, leider keine.
>
>In [INTERNET WORKING] steht es werden nur die ersten 64 Bytes
>(Collision Window) gepuffert, ausgewertet und überprüft.
Wie lang muß ein Frame mindestens sein? Wie groß darf ein Netz maximal sein?
Wie lange braucht ein Bit durch das Netz? Wieviele Bits kann man in der Zeit
senden? => 64 Byte (IIRC 60).
Manuel Weber
news:slrna3e7j...@belenus.iks-jena.de...
> Wie lang muß ein Frame mindestens sein? Wie groß darf ein Netz maximal
sein?
> Wie lange braucht ein Bit durch das Netz? Wieviele Bits kann man in der
Zeit
> senden? => 64 Byte (IIRC 60).
Mit anderen Worten, der Prof. erzählt da Blödsinn ?
Gib es da noch eine verbindliche URL, die ich ihm unter die Nase halten
kann,
da diese Aufgabe auch in seinen Klausuren drankommt ?
Manuel Weber
news:slrna3e7j...@belenus.iks-jena.de...
> Wieviele Bits kann man in der Zeit> senden? => 64 Byte (IIRC 60).
[...]
In the Fragment-Free switching mode, the switch waits for the collision
window
(64 bytes) to pass before forwarding. If a packet has an error or better
explained,
a collision, it almost always occurs within the first 64 bytes.
Fragment-Free mode
provides better error checking than the Cut through mode with practically no
increase in latency.
[professor]:
"Wie gesagt 64 Bytes sind etwas schlampig gerechnet
korrekt kann nur 68 Bytes sein".
Redet der Prof. nun Blödsinn, oder haben wir was vergessen ?
(Nein, er beharrt trotz Hinweis auf der Rechnung mit 68 Bytes]
Siegbert Marschall
> Redet der Prof. nun Blödsinn, oder haben wir was vergessen ?
> (Nein, er beharrt trotz Hinweis auf der Rechnung mit 68 Bytes]
der Prof. redet "Blödsinn".
Die Rechnung ist richtig, behandelt aber die falschen parameter.
10Base5 -> maximal 2500m
Um eine Kollision sicher erkennen zu können muss das signal 4mal
da durch. = 10000m / c = 64byte(512bit) * 10 mbit/s = 51,2µsec
Signallaufzeit.
Die minimale Paketlänge wird hier nicht über den Inhalt / Typ
sondern über die Laufzeit bestimmt.
Ausserdem gibt es noch zb. IEEE802.3 .
Ethernet Frame:
7byte präambel
1byte frame delimiter
6byte dest.
6byte source.
2byte type
daten
4byte fcs
IEEE802.3 Frame:
7byte präambel
1byte frame delimiter
6byte dest.
6byte source.
2byte length
1byte dsap
1byte ssap
1byte control
3byte protocol id
2byte type field
daten
4byte fcs
also : paketlänge ungleich framelänge
minimale paketlänge(für collision entscheidend) ist die minimal notwendige
länge eines datenpaketes um eine kollision zu erkennen.
minimale framelänge ist in dem jeweiligen standard definiert und sagt
wielange ein frame mindestens sein muss damit es eine korrektes frame
nach standard x ist.
bye, siggi.
ps. minimale framelänge fehlt da mein schlaues buch in der firma liegt und
ich jetzt keinen bock hab deswegen rüberzufahren. aber ihr habt da sicher
welche zum nachlesen in der bibliothek.
pps. da switches idr. protokolltransparent arbeiten, ist wohl in der regel
nur das collisionwindow entscheidend.
Oliver Bartels
<si...@marschall.org> wrote:
>Um eine Kollision sicher erkennen zu können muss das signal 4mal
>da durch. = 10000m / c = 64byte(512bit) * 10 mbit/s = 51,2µsec
>Signallaufzeit.
gewöhnlichen Kabeln die Signallaufzeit deutlich kleiner c ist.
Genauer c_Signal = c_0 / sqrt( epsilon_r mu_r )
wobei man das mu_r getrost auf 1 setzen darf, das epsilon_r
aber typisch in der Region 2..4 liegt. c_0 ist die allseits
bekannte Vakuum-Lichtgeschwindigkeit.
Gruß Oliver
--
Oliver Bartels + Erding, Germany + obar...@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Siegbert Marschall
> >Um eine Kollision sicher erkennen zu können muss das signal 4mal
> >da durch. = 10000m / c = 64byte(512bit) * 10 mbit/s = 51,2µsec
> >Signallaufzeit.
> Hinweis: Die Rechnung ist mit Vorsicht zu genießen, weil auf
> gewöhnlichen Kabeln die Signallaufzeit deutlich kleiner c ist.
> Genauer c_Signal = c_0 / sqrt( epsilon_r mu_r )
> wobei man das mu_r getrost auf 1 setzen darf, das epsilon_r
> aber typisch in der Region 2..4 liegt. c_0 ist die allseits
> bekannte Vakuum-Lichtgeschwindigkeit.
mea culpa, ergebniss ist richtig, formel nur als erläuterung und
nicht zur berechnung zu verwenden...
c ist in diesem fall c_signal dh. c_0 * 0.66 = 197862 km/sec.
die reine signallaufzeit sind also ca. 50,6µsec , kommen aber noch die
verzögerungen in den repeatern dazu. hat man sich wohl damals auf
512bit geeinigt, weil das eine hübsche runde zahl ist die passt.
bye, siggi.
Andre Beck
>
> [professor]:
> "Wie gesagt 64 Bytes sind etwas schlampig gerechnet
> korrekt kann nur 68 Bytes sein".
Wenn er das jetzt *begründen* würde, statt es einfach zu postulieren, hätte
ich wesentlich weniger Bauchschmerzen damit.
> Redet der Prof. nun Blödsinn, oder haben wir was vergessen ?
> (Nein, er beharrt trotz Hinweis auf der Rechnung mit 68 Bytes]
Kann es sein, dass er in seine Betrachtungen eine minimale Framegröße ein-
fließen ließ, die natürlich auch die 4Byte FCS beinhaltet, was hier aber
irrelevant ist? Die FCS steckt im Trailer, ist also für frag free switching
nicht von Bedeutung.
Ich muss wirklich mal ins Buch gucken. Mir ist nach wie vor nicht ganz
geheuer mit den 64Bit Präambel (ob die jetzt in die 512 Bittimes reinzu-
zählen sind oder nicht).
Siegbert Marschall
> Ich muss wirklich mal ins Buch gucken. Mir ist nach wie vor nicht ganz
> geheuer mit den 64Bit Präambel (ob die jetzt in die 512 Bittimes reinzu-
> zählen sind oder nicht).
hatte ich schon getan, 56 bit präambel, 8 bit frame-delimiter.
ob man den jetzt zur präambel zuzählt oder nicht, ist streitbar, meiner
meinung nach nicht.
bye, siggi.
Andre Beck
>
> > Ich muss wirklich mal ins Buch gucken. Mir ist nach wie vor nicht ganz
> > geheuer mit den 64Bit Präambel (ob die jetzt in die 512 Bittimes reinzu-
> > zählen sind oder nicht).
> hatte ich schon getan, 56 bit präambel, 8 bit frame-delimiter.
Wobei letzterer ja eigentlich nur in zwei Bit besonders ist (Sync), IIRC.
> ob man den jetzt zur präambel zuzählt oder nicht, ist streitbar, meiner
> meinung nach nicht.
Ich hab mir das angewöhnt, weil es L1/Coding-Gewusel ist und mich eigentlich
zeitigstens das L2-Frame interessiert (also von SrcMAC bis FCS), dass man
auf L1 noch ein paar Tricks draufhat, um Frameanfang und -ende zu signali-
sieren ist schon klar, aber für die meisten Betrachtungen ziemlich irrele-
vant - es sei denn, man designed grad konforme Hardware oder quält sich mit
Übungsaufgaben ;)
Manuel Weber
> Kann es sein, dass er in seine Betrachtungen eine minimale Framegröße ein-
> fließen ließ, die natürlich auch die 4Byte FCS beinhaltet, was hier aber
> irrelevant ist?
[Seine Anwort]
Das Problem ist vermutlich die Preambel, obwohl 8 Byte lang wird sie jedoch
nicht zum minimalen Ethernet Frame gezählt. Sie muß aber übertragen werden,
und
somit zählt diese Zeit auch!
Siehe auch O'Reilly Ethernet Definition Guide z. B. Seite 51.
Dort wird auch die Netzwerkausdehnung mit 9186 feet ( 2800 meter )
angegeben,
während die Cisco Dokumentation
2500 Meter angibt.
Andre Beck
> "Andre Beck" <be...@ibh.de> schrieb im Newsbeitrag
> news:87hepzv...@coredump.ibh.net...
>
> > Kann es sein, dass er in seine Betrachtungen eine minimale Framegröße ein-
> > fließen ließ, die natürlich auch die 4Byte FCS beinhaltet, was hier aber
> > irrelevant ist?
>
> [Seine Anwort]
>
> Das Problem ist vermutlich die Preambel, obwohl 8 Byte lang wird sie jedoch
> nicht zum minimalen Ethernet Frame gezählt. Sie muß aber übertragen werden,
> und somit zählt diese Zeit auch!
Sag ich ja die ganze Zeit, ich wusste nicht mehr genau, ob die Präambel in
die Slot Time (512 Bit Times) reinzählt oder nicht. Zählt sie nicht, da hat
er recht, 802.3 sagt:
The minimum and maximum frame size limits in 4.4 refer to that portion
of the frame from the destination address Field through the frame check
sequence Field,inclusive.
und schreibt dann in 4.4
minFrameSize 512 Bits (64 Octets)
wie ich auch erwartet hatte. Für mich ergibt das 72 Octets delay. Ich bin
immer noch der Meinung, dass er mit 46 Octets minimum data size gerechnet
hat, was aber die FCS missachtet. 46 ergibt sich, wenn man von 64 (minFrame-
Size) den Header (14 Byte) *und* die FCS (4 Byte) abzieht. Soweit klar, aber
diese Annahme gilt eben nur für ein komplettes Frame mit FCS. Es ist daher
besser, einfach die Slot Time anzusetzen, plus Einschwing-Header (also
Präambel plus Frame Start Delimiter, die man als 7 Byte + 1 Byte auffassen
kann, aber auch als 62 Bit binär 10 gefolgt von einmal binär 11) sind das
dann besagte 72 Byte aka 576 Bit. Ich kann seine 68 Byte nicht nachvoll-
ziehen, wie gesagt, IMO um die 4 Byte FCS daneben.
> Siehe auch O'Reilly Ethernet Definition Guide z. B. Seite 51.
Kenn das Buch nicht, aber O'Reilly taugt normalerweise. Ich schwöre auf
Kalkunte et al. in "Gigabit Ethernet - Migrating to high speed LANs" oder
so ähnlich, reißerischer Titel, aber absolutes Profibuch (es ist einfach
802.3 in lesbar). Nur steht das @Work und ich vergess immer reinzugucken.
Daher jetzt direkt aus 802.3 zitiert, das PDF ist bloß bescheiden zu navi-
gieren...
> Dort wird auch die Netzwerkausdehnung mit 9186 feet ( 2800 meter )
> angegeben, während die Cisco Dokumentation 2500 Meter angibt.
Cisco hat sowieso diverse Ansichten. In unseren Folien und Materialien
steht auch 2800m ;)