Belang linkspeed bij hoeveelheden data kleiner dan capaciteit?

[Cakkie]

Wat is het belang van de link speed bij het verzenden van kleine hoeveelheden gegevens?

Als ik heel kort door de bocht ga (even overhead van packets, frames en apparatuur buiten beschouwing), dan zou ik denken dat 1Mbit data over 10MBit ongeveer 100ms duurt, 10ms over 100MBit en 1ms over 1GBit. Gaat dat echter wel op? Moet ik 10Mbit vs 100Mbit vergelijken met een snelweg waar 10 keer zo snel gereden kan worden, of een snelweg die 10 keer zo breed is? Die 1Mbit wordt in dit geval trouwens verdeeld over die second, dus niet gewoon 1 blok van 128KB die op de lijn gezet wordt, maar eerder 128 blokjes van 1K.

[bebbet]

MBit is een omschrijving van snelheid/capaciteit, niet van grootte. Hierdoor is 100MBit tegenover 10MBit 10 keer zo breed, en niet per definitie 10keer zo snel (dit heeft meer te maken met latency). Maar om een x aantal KB door een lijn te duwen, is het pluspunt van grotere capaciteit dat de data sneller van punt A naar punt B kan.

[visser]

Wat is het belang van de link speed bij het verzenden van kleine hoeveelheden gegevens?

Als ik heel kort door de bocht ga (even overhead van packets, frames en apparatuur buiten beschouwing), dan zou ik denken dat 1Mbit data over 10MBit ongeveer 100ms duurt, 10ms over 100MBit en 1ms over 1GBit. Gaat dat echter wel op? Moet ik 10Mbit vs 100Mbit vergelijken met een snelweg waar 10 keer zo snel gereden kan worden, of een snelweg die 10 keer zo breed is? Die 1Mbit wordt in dit geval trouwens verdeeld over die second, dus niet gewoon 1 blok van 128KB die op de lijn gezet wordt, maar eerder 128 blokjes van 1K.

Voor het elektrische/optische deel is het inderdaad zo dat er tien keer zo hard gereden wordt.
Ethernet is puur seriëel, en hogere snelheid is dus een kortere tijd per bit, niet meer bits parallel.
(heel klein nitpickje dat GigE een complexe modulatie gebruikt over alle acht aders).
Sterker, bijna alle data circuits zijn seriëel.

Wel doe je bij sub-rate snelheden er goed aan om inderdaad de data in de tijd te spreiden.
Dat wel zeggen dat je tussen verschillende packets langer wacht.
Als je een snelle burst op lijnsnelheid stuurt en de rest van de tijd niks, heb je kans dat (kleine) buffers overlopen en daarbij packetloss geven, terwijl er *gemiddeld* capaciteit genoeg is. Dat heet een microburst.
Een individueel frame/packet gaat wel (per definitie) op lijnsnelheid.

[Cakkie]

Ok, bedankt voor de uitleg.
Dus bij streaming of voice zou dat op zich niet zo'n groot verschil mogen geven tussen 10Mbit en 100Mbit, gezien dit ruim onder de limiet blijft? Enkel de tijd die de frame nodig heeft om van de server naar de switch is 10 maal langer, wat voor een frame van 1K (en zo groot zijn ze volgens mij nog niet eens) zou dit theoretisch 0.63ms verschil mogen maken, right?

[visser]

Ok, bedankt voor de uitleg.
Dus bij streaming of voice zou dat op zich niet zo'n groot verschil mogen geven tussen 10Mbit en 100Mbit, gezien dit ruim onder de limiet blijft? Enkel de tijd die de frame nodig heeft om van de server naar de switch is 10 maal langer, wat voor een frame van 1K (en zo groot zijn ze volgens mij nog niet eens) zou dit theoretisch 0.63ms verschil mogen maken, right?

Ik weet niet op welke "limiet" je doelt, maar het verschil in serialisatie tijd (zo heet dat, de tijd die het kost om een frame op de lijn te zetten) is bij dit soort snelheden verwaarloosbaar inderdaad.
Het verschil is een stuk belangrijker als je bijvoorbeeld een Frame relay link met 64Kb/sec lijnsnelheid vergelijkt met ééntje van 2Mbit/sec lijnsnelheid en een CIR +shaper van 64K.

[QBell]

Een side vraag die hier iets dieper op in gaat en iemand van jullie mogelijk wel weet:

Is de kans op collision groter of kleiner op hogere snelheden?
a) Er worden meer bits per seconden verstuurd dus de kans op collision word groter.
b) De timing (in ik neem aan Mhz) van punt A naar punt B word ook hoger bij hogere snelheden dus neemt de relatieve kans op ccollision weer af.

Beide zijn dus mogelijk...
Maar welke van de 2 is (meer) correct?

[visser]

Een side vraag die hier iets dieper op in gaat en iemand van jullie mogelijk wel weet:

Is de kans op collision groter of kleiner op hogere snelheden?
a) Er worden meer bits per seconden verstuurd dus de kans op collision word groter.
b) De timing (in ik neem aan Mhz) van punt A naar punt B word ook hoger bij hogere snelheden dus neemt de relatieve kans op ccollision weer af.

Beide zijn dus mogelijk...
Maar welke van de 2 is (meer) correct?

Collisions bestaan niet op switched (utp/stp/glas) ethernet, want het kanaal tussen host en switch is full duplex, met een apart receive en transmit verbinding.

Collisions had je alleen op coax ethernet, wat half duplex is (maar alleen in een 10Mbit smaak bestond), en met hubs, waarbij de hub 'backplane' het shared medium is.
Hubs bestonden wel in 100 Mbit versie.

Bij hetzelfde aangeboden data volume is de kans op collisions veel kleiner wanneer het medium een hogere snelheid heeft, omdat de "kabel-bezet" tijd veel korter is.
Als je 10Mbit/sec over een 10Mbit half-duplex ethernet probeert te sturen, zit je bomvol en heb je (dus) veel collisions; 10 Mbit/sec over een 100Mbit/sec half-duplex sturen netwerk heb je in dat geval veel minder collisions.

Stelling A van je is niet juist, er worden *gedurende* een seconde alleen meer bits gestuurd als je ook meer data verstuurt; Stelling B is me niet duidelijk wat je bedoelt.

Maar het zijn voornamelijk nostalgische vragen, want collisions heb je niet meer in switched ethernet.
(Wel eventueel packetloss, als je vanuit een paar poorten verkeer stuurt naar één enkele poort, of vanuit een G/10G poort een 100M poort volblaast).

[QBell]

Collisions bestaan niet op switched (utp/stp/glas) ethernet, want het kanaal tussen host en switch is full duplex, met een apart receive en transmit verbinding.

Ja was laat hé.
Sesamstraat was afgelopen...

Bedoelde congestion ipv collision (maar dat kon jij ook niet weten).
Maar, jou uitleg geeft ook antwoord op die vraag

Bedankt, weer wat geleerd.