SzgHalok Gyakorlati példák és megoldásaik

← Vissza az előző oldalra – Hálók

1. feladat

Két állomás egymás között csúszóablakos (sliding window) forgalomszabályozást használ. A kommunikációs csatorna 1 Mbit/sec átviteli sebességet tesz lehetővé a küldőtől a fogadó felé. Tegyük fel, hogy az adó állomás 1000 bit hosszú csomagokat küld. A link körülfordulási ideje (RTT) 5 msec, a csúszóablak mérete pedig 3 csomagnyi. Mekkora a csatorna kihasználtsága?

• L: adathossz
• R: átviteli sebesség
• U: kihasználtság
• W: hibajavító ablak mérete

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle U=\frac{W\cdot\frac{L}{R}}{RTT+\frac{L}{R}} = \frac{3\cdot\frac{1000}{1\,000\,000}}{0,005+\frac{1\,000}{1\,000\,000}} = 0,5}

2. feladat

• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle C_{win} = 16 kB = 16\cdot10^{3}}
• RTT = 1 ms
• D = ?

Általános képlet: Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle D = \frac{C_{win}}{RTT}\cdot(\frac{3}{4})}

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle D = \frac{16\cdot10^{3}}{10^{-3}} = 16\cdot10^{6} \textrm{B/s} = 16 \textrm{Mb/s} }

• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle C_{win}:} csúszó ablak mérete
• RTT: körülfordulási idő

A ¾ az úgymond korrekciós tényező – ez a linksebesség miatt jött be; fontos megjegyzés ide, hogy azért van zárójelben, mert nem feltétlen kell használni. Ha számolni kell vele, akkor azt jelzik.

3. feladat

• RTT = 100ms
• D = 10Gbit/s
• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle C_{win}} = ?

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle C_{win} = RTT{\cdot}D = 0,1{\cdot}10^{10} = 10^{9}\textrm{bit} = 1,25{\cdot}10^{8}\textrm{byte}= 125 \textrm{Mb}}

4. feladat

Egy 1500 bájtos (IP fejrésszel együtt) IPv4 csomagot küldünk 3 linken keresztül, melynek rendre a hálózati rétegre vonatkoztatott MTU-i 1500, 1300 és 1150 bájt. Számoljuk ki milyen hosszú töredékek érkeznek a címzetthez, és ezekben milyen értékek az alábbi mezők:

• Fragment offset
• More fragment
• Mekkora a fej okozta overhead tördeletlen és tördelt esetben?

Tördelés előtt:

• csomag 1500 bájt (20 bájt fej + 1480 payload)

1. tördelés után

1. töredék :

• MTU: 1300 bájt
• fejrésze: 20 bájt
• payload: 1280 bájt [8-cal oszthatónak kell lennie (1280/8 = 160 - ez lesz a köv. töredék fragment offsetje)]
• méret: 1300 byte
• FO = 0
• MF = 1

2. töredék

• fejrésze: 20 bájt
• payload: 1480 - 1280 = 200
• méret: 220
• FO = 160
• MF = 0

2. tördelés után (1300)

1. töredék

• MTU: 1150 byte
• fejrész: 20 byte
• payload: 1130 nem lehet, mert nem osztható 8-cal -> 1128
• méret: 20 + 1128 = 1148 ( 1128 = 141 * 8 - köv. fragment offsetje)
• FO = 0
• MF = 1

2. töredék

• fejrész: 20
• előzőből maradt payload: 1280 - 1128 = 152
• méret: 20 + 152 = 172
• FO = 141
• MF = 1

3. töredék

• Ami az első tördelés második töredéke volt. Minden marad.

Összesen

• Hasznos adat összesen: 1480 byte
• Overhead tördeletlene esetben: 20 byte
• Az 1. tördelés után: 40 byte
• A 2. tördelés után: 60 byte

5. feladat

Beszédet továbbítunk az ATM hálózat CBR (Constant Bit Rate) QoS szolgáltatásának segítségével. Mekkora legyen a PCR (Peak Cell Rate) forgalomleíró paraméter értékel cella/sec-ben, ha 64 kbit/s-os beszéddigitalizálást alkalmazunk, és egy cellában 40 byte-nyi beszédmintát viszünk át?

64 kbps = 64000 bps = 8000 B/s. Ha 40 bájt adat van cellánként, akkor PCR = 200 cella/s

6. feladat

160 byte-os beszédszegmenseket RTP, UDP és IPv4 protokollok használatával továbbítunk. Hány byte lesz egy IP csomag minimálisan szükséges hossza tömörítés nélküli esetben?

IPv4 fejléc + UDP fejléc + RTP fejléc + 160 bájt: 20 + 8 + 12 + 160 = 200

7. feladat

Az "A" és "B" végpont közötti kommunikáció során "A" végpont TCP adategységében a sorszám (sequence number) 5920, az ACK-szám (acknowledgement number) 9561, a hasznos adatrész 80 byte. Mennyi lesz sikeres vétel esetén "B" válaszként küldött TCP adategységében az ACK-szám?

A sequence number-hez hozzá kell adni a hasznos adatrészt: 5920 + 80 = 6000 Megjegyzés: A visszaküldött sequence number pedig a 9561 lesz.

8. feladat

Deficit round robin ütemezés.

A hitelszámláló mindig 0-ról indul. Jelenleg 100 adagnyi adatot fogunk egyszerre átvinni. Ha ez nem sikerül, akkor a következő körben 100-zal növelt hitelszámlálóból levonjuk az átvitt mennyiséget.

Megoldás a diák alapján, azaz hogy több is lehet egyszerre kiszolgálva( inkább ezt írjátok vizsgán, mert erre lehet hivatkozni, hogy a dián volt )

Sorszám	*A*	*B*	*C*
Átvinni kívánt mennyiség	150	80	120
1. kör	+100	+100 - 80 = 20	+100
2. kör	+200-150=50	0	+200 - 120 = 80
3. kör	0	0	0

1. kör : B

2. kör : A,C

alternatív megoldás az órán csinált példa alapján(egyszerre egyet tudunk kiszolgálni):

Sorszám	*A*	*B*	*C*
Átvinni kívánt mennyiség	150	80	120
1. kör	+100	+100 - 80 = 20	+100
2. kör	+200 -> 0	0	+200 - 120 = 80
3. kör	+100	0	0
4. kör	+200-150=50	0	0
5. kör	0	0	0

Változtatási okok a régi megoldáshoz képest:

1. nem nullázódik le

2. Egyszerre csak egy lehet kiszolgálva. A C a kisebb igényű ezért a mixman elv értelmében a C lesz kiszolgálva. Ha nincs igény, nem kap hitelértéket, ezért a B-nek 0-a a hitelértéke. Az A azért nullázódik le, mert akkor is nullázódás van, ha ki lenne szolgálva, de nem ő került sorra ( ezen többen is néztek órán, te a tanár így csinálta )

3. Még nem lett kiszolgálva A, itt már B se kap hitelértéket

4. Itt szolgálódik ki

5. Ez után már A sem kap hitelértéket

9. feladat

Modulációk, a kérdés az adatsebesség. Mindenképpen figyeljünk a megfelelő mértékegységre való átváltásra!

• QPSK: 2 bit/szimbólum
• 16-QAM: 4 bit/szimbólum
• 64-QAM: 6 bit/szimbólum

Pl.: 400 kbaud a szimbólumsebesség, mekkora az adatsebesség QPSK esetén: 1 szimbólum = 2 bit = 800 kbit/s (100 kbyte/s).

10. feladat

CSMA/CD, különféle kérdések az adatokra.

• R: adatsebesség
• c: fénysebesség
• L: szegmensméret
• M: minimális kerethossz
• T: résidő (=2t)

A "c" ha rézben vagy optikában terjed az adat, akkor Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle 2\cdot10^{8}} , ha pedig a levegőben (wireless), akkor Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle 3\cdot10^{8}} .

Példa:

• L: 200 m
• R: 10 Mbit/s
• Mekkora a minimális kerethossz és a résidő?

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle t=\frac{L}{c}}

Résidő: Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle 2t=\frac{2L}{c}=\frac{2\cdot2\cdot10^{2} \textrm{m}}{2\cdot10^{8} \textrm{m/s}}=2\cdot10^{-6}s=2{\mu}s}

Minimális kerethossz: Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle M={\lceil}T{\cdot}R\rceil=2\cdot10^{-6}s {\cdot} 10\cdot10^{6}bit/s = 20bit}

11. feladat

Hasonló az előzőhöz.

• R: Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle 4 Mbit/s = 4\cdot10^{6}bit/s}
• M (csomagméret): 1000 bájt
• Mennyi az adásidő és a terjedési idő?

Egy routernél megkülönböztetünk:

• várakozási időt;
• sorbanállási időt;
• adási időt;
• terjedési időt (ennek kétszerese a résidő).

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle t_{adasi}=\frac{M}{R}=\frac{8\cdot10^{3}}{4\cdot10^{6}}=2\cdot10^{-3}=2 ms = 2000{\mu}s}

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle t_{terjedesi}=\frac{L}{c}=\frac{500m}{2\cdot10^{8}\frac{m}{s}}=2,5\cdot10^{-6}s=2,5{\mu}s}

12. feladat

Ez egy súlyozott körbekérdezés (weighted round robin) ütemezési stratégiát bemutató feladat.

A, B, C összeköttetéseken az átlagos csomaghosszak 50, 500 és 1500 byte, valamint a súlyozásuk is meg van adva.

A kérdés az, hogy hány csomagot vagy byteot szolgáljunk ki az egyes összeköttetéseknek másodpercenként. Ehhez kiszámoljuk a súly/csomaghossz arányt az említett értékek osztásával, majd azokat közös nevezőre hozva megkapjuk a normalizált súly/csomaghossz arányt (60,9,4). Ez adja meg, hogy másodpercenként hány csomagot kell kiszolgálnunk az adott összeköttetéseknek. Ha azt szeretnénk megtudni, hogy ez byte-ban pontosan mennyi, akkor nincs egyéb dolgunk, mint megszorozni ezt az értéket az átlagos csomaghosszakkal.

	*A*	*B*	*C*	Megjegyzés
Csomaghossz	50	500	1500
Súlyok	0,5	0,75	1	egymáshoz képesti arány
Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle \frac{suly}{csomaghossz}}	Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle \frac{1}{100}}	Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle \frac{3}{2000}}	Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle \frac{1}{1500}}	legkisebb közös többszörös, *6000
	60	9	4	*csomaghossz
Adat	3000	4500	6000

Mondjuk a legkisebb közös többszörös itt 3000, nem 6000 de üsse kavics... (6000 az :), 3/2000 -> 4.5/3000 nem jó... --- KT)

Ahogy én értem, a lényeg az, hogy a súlyozás azt mondja meg, hogy a teljes sávszélesség hányadrészét használhatja az adott user (a többekhez képest). A súly/csomaghossz hányados pedig azt mondja meg, hogy a ráeső sávszélességből mennyit használ el egy csomag elküldése. A közös nevezőzés az arra jó, hogy megtudjuk, hogy a sávszélességkihasználási arányok mellett egy időben hány csomagot tud elküldeni az egyik, és hányat a másik. A felszorzás az már ténleg csak ellenörzés, csomagszám*csomaghossz= felhasznált sávszélesség. ---nellgwyn

13. feladat

10 Mbaud/sec jelzéssebességű vonalon QPSK-val küldünk csomagokat. Mivel a csatorna zajos, ezért a teljes adathoz 25% hibajavító kód adódik. A protokoll overhead (tehát az összes fejrész) 60%-a a ténylegesen hasznos adatnak. Hány Mbit/sec sebességgel tudjuk küldeni a hasznos adatot?

QPSK, tehát 4 szimbólum/jel => 2 bit/jel. 20 Mbit/sec a teljes sebesség, ebből +25% a hibajavítás => Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle \frac{20}{1,25} = 16 Mbit/sec } az adat és a fejléc. A hasznoshoz képest 60% a fejléc, azaz Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle \frac{16}{1,6} = 10 Mbit/sec. }

14. feladat

10 ms beszédszegmenseket tömörítetlen PCM kódolunk. RTP, UDP és IPv4 segítségével, 2:1 arányú fejrész tömörítéssel küldjük. Mekkorák lesznek az IP csomagok?

Tömörítetlen PCM kódolás az 64 kbit/sec => 8 kbyte/sec => 80 byte/10msec. Az IPv4 + UDP + RTP fejléc alapesetben 20 + 8 + 12 = 40 bájt. A 2:1 arányú tömörítés azt jelenti, hogy ennek a felére csökkentettük a fejléceket, tehát 20 bájtra.

80 + 20 = 100 bájt egy csomag.

15. feladat

Körülbelül hány áramkör kapcsolása végezhető el telefonminőség esetén, ha a TSI (Time Slot Interchanger) memóriájának elérési ideje 50 ns?

Az analóg-digitális átalakításról a következőt kell tudni (64 kbit/s-os beszéd esetén):

• mintavétel az analóg jelből 8 kHz-cel, azaz 125 mikroszekundumonként
• a minták ábrázolása 8 biten történik (kerekítése 256 szintre)
• tehát 8 bit/1 bájt 125 μs-onként

Azaz 125 μs a körülfordulási idő. Az 50 ns-ot megszorzod kettővel (mert kell adatot küldeni A->B-be és vissza B->A-ba is), majd a 125 μs-ot leosztod a kapott 100 ns-mal, akkor megoldásként 1250 jön ki.

16. feladat

Mikor kap nyugtát az adóállomás, ha előzőleg, első alkalommal foglaltnak érzékelte a csatornát?

• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{SIFS}} = 10 \mu \textrm{s} }
• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{slot}} = 20 \mu \textrm{s} }
• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{data}} = 1 \textrm{ms} } (Adatátviteli idő)
• Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle CW_{\textrm{rand}} = 0.3 }

Timeline: [--foglalt--|--Tdifs--||--Tcount--||--Tdata--||--Tsifs----nyugta--]

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{DIFS}} = T_{\textrm{SIFS}} + 2\cdot T_{\textrm{slot}} } (Ennyit várunk a foglaltnak észlelés után)

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{DIFS}} = 50 \mu s}

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{count} = \lfloor CW_{\textrm{rand}} * 31\mu s\rfloor * T_{\textrm{slot}}}

(Próbálkozás szerinti késleltetés, ha első alkalommal érzékelte foglaltnak: 31, ha másodszor: 63 ... stb. (Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle 2^x-1 } )

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{count}} = \lfloor 0.3*31 \rfloor*20 = 180 \mu s}

Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle T_{\textrm{DIFS}}+T_{\textrm{count}}+T_{\textrm{data}}+T_{\textrm{SIFS}}=50+180+1000+10=1240 \mu s} --- Gubek Andrea jegyzete alapján

17. feladat

Mikor kapunk nyugtát a központban, ha az ADSL linken a sorbanállási idő a felhasználónál 3 ms, a feldolgozási idő 4μs (feltételezve hogy a másik oldalon elhanyagolhatóak ezek a késleltetések), miközben:

• R Letöltés = 4 Mbit/s
• R Feltöltés = 512 kbit/s
• L Távolság = 2 km
• D Csomagméret = 1000 byte = 8000 bit
• D Nyugta = 64 byte = 512 bit
• C Terjedési sebesség = 2 * 10^8 m/s

a válaszát ms-ban adja meg.

T = Feldolgozás + Sorbanállás + Adás + 2 * Terjedés

Adás = ( D_csomag / R_letöltés ) + ( D_nyugta / R_feltöltés ) = ( 8000 / 4*10^6 )+ ( 512 / 512*10^3 ) = 3 ms

Terjedés Értelmezés sikertelen (SVG (a MathML egy böngészőkiegészítővel engedélyezhető): Érvénytelen válasz („Math extension cannot connect to Restbase.”) a(z) https://wikimedia.org/api/rest_v1/ szervertől:): {\displaystyle = 2 * L/C = 2 * 2000 / 2*10^8 = 2 * 10 \mu s = 0,02 \textrm{ms}}

Sorbanállás = 3 ms

Feldolgozás = 4 us = 0,004 ms

T = 3 + 0,02 + 3 + 0,004= 6,024 ms