[elektro] ethernet flow control

[Abraham Gabor]

> > Nem az a gond, hogy túl sok csomag jön be?
> > Sok rövid csomagot feldolgozni sokkal rosszabb,
> > mint azonos mennyiségű adatot, ami nagyobb
> > adagokban jön.
>
> Így van ez a gondom.
>
> > A pause frame benne van a szabványban,
> > általában kezelni szokták tudni az eszközök,
> > ha maguk nem is küldik.
> > Nem nagyon tudsz mást csinálni. Ha nem
> > kezeli, akkor ismétel a fölsőbb szint.
> > Miért baj ez nálad?
>
> Mert nem használtam pause frame-t :)
> Most utánanéztem, megadott mac-ra kell megadott opkódot küldeni. Akkor
> tulképp már csak ellenőriznem kell, hogy megy-e az ezközzel.
> Olvastam még prioritás flowctrlt, az is hasonló etherblokk küldéssel
> müxik, csak azt is használják-e? Vagy az csak vlan-on van? A pause
> frame ha jól olvastam csak full-duplex esetében használható?

Nem érdemes foglalkozni vele ebben az esetben.
Aki nem kezeli a pause-t az a prioritást sem fogja.

> Amit a collisionról írtál, arról meg annyit találtam, hogy adás
> közben/végén ha kiderül a hiba akkor JAM jelet tesznek a vonalra
> amikor is 51.2us egységekkel növekvő késleltetéssel fog próbálkozni a
> küldő.

Így van. A küldő úgy érzi, hogy más is adni kezdett.
A 10 megás ethernet esetén volt divat, 100 Mbps full duplex-nél nem játszik.

> Nekem ez is jó lenne ha müxik, csak nemtom ezt hogy kell
> generálni? A phy doksijában kell lenni valaminek vagy a mac egység
> regisztereiben keressem a megoldást ?

Kommersz ethernet IC valószínűleg nem tudja.

Ezer éve, még a SZTAKI-ban fejlesztett Ethernet kártyához volt
egy disturbator firmware. Ez programozható eloszlással, szelektíven
rondított bele a csomagokba. (Pl. adott végpontról jövő, minden n. csomag.)
Jól lehetett vele tesztlni.

Gábor
----------------------------------------------------------------
Ábrahám Gábor                           http://cdtransport.atw.hu/
7+ Számítógép Hálózati Kft.             Tel : (06-1) 248-3214
1118, Budapest, Homoród u. 17.          Fax : (06-1) 248-3216