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

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

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} }

• $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.

• C: 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
• C: 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}C\rceil=2\cdot10^{-6}s {\cdot} 10\cdot10^{6}bit/s = 20bit}

11. feladat

Hasonló az előzőhöz.

• C: É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}{C}=\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