linux-hw digest, 39 kötet, 2 szám

[Bartók István]

100Mbit-es portban szepen muzsikal, ki is tol 80M+ forgalmat (NFS),
gondoltam nagy okosan atrakom gigabites portra, had szoljon. Miutan
atraktam a forgalma leesett ~20Mbitre.
ethtool mutatja, hogy feljon gigabiten, dmesg-ben is latszik hogy ,
valahogy megsem mukodik ahogy kellene.

Ki kellene iktatni az autonegotiationt.
Arra tippelek, half-duplex lett a link.

bartoki:~$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:03:47:D5:A2:CB
inet addr:152.66.208.5 Bcast:152.66.215.255 Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:718241728 errors:0 dropped:0 overruns:0 frame:0
TX packets:561667351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:274569206 (261.8 MiB) TX bytes:3865421410 (3.5 GiB)

bartoki:~$

Két számlálót kellene megnézni:
- frame:0
- collisions:0

Ha a frame: számláló növekszik, akkor hibás kereteket vesz (frame errors).

Azok a csomagok elvesznek, ezért a TCP visszaszabályoz (azt hiszi torlódás
van), vagy az NFS timeoutra vár újraküldés előtt, emiatt lesz lassú a net.

Elég ha 5% vagy akár 1% csomag elvész, máris töredékére eshet vissza a
sebesség.

Az ilyen frame errorokat leggyakrabban ez a kétféle hiba okozza:

1) Lehet hogy a link egyik végén lévő berendezés half-duplexnek tekinti a
linket, a másik meg full-duplexnek - ezt írta KissG. Ilyenkor "late
collision" történik, aminek illene megjelennie a frame: és a collision:
számlálókban is (talán még a TX oldali carrier: számlálóban is).

2) Lehet hogy egyszerűen csak nem elég jó minőségű a kábel, a csatlakozók,
a kifejtés, vagy az eszközök a kábel két végén. Ilyenkor nem kellene a
collision: számlálónak nőnie, csak a frame: -nek.

Nem managgelheto switchek, szoval ott nem tudok allitani semmit.

Az én vallásom tiltja hogy nem managgelhető switchet vegyek :), pont az
ilyen debuggolhatatlanság miatt.

Egy normális hálózati eszköz szépen számolja a különböző hibákat - pl. az
említett late collision-t megkülönbözteti a sima collision-tól - ezért
aztán tisztán látszik a számlálókból hogy mi megy a hálózaton.

[Miloska]

Post by Bartók István
- frame:0
- collisions:0
Ha a frame: számláló növekszik, akkor hibás kereteket vesz (frame errors).

Koszonom a reszletes es korrekt leirast!

'Sajnos' a hiba szamlalok nem nonek, 0-n allnak.

Post by Bartók István
Az én vallásom tiltja hogy nem managgelhető switchet vegyek :), pont az
ilyen debuggolhatatlanság miatt.

Gyanusak nekem is, de valoszinutlennek tartom, hogy ket kulonbozo koru
es gyartoju gagyi switch is ennyire gagyi legyen. Persze nem
lehetetlen.

Koszonom megegyszer a kimerito valaszt.

[Gabor Gombas]

Post by Bartók István
bartoki:~$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:03:47:D5:A2:CB
inet addr:152.66.208.5 Bcast:152.66.215.255 Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:718241728 errors:0 dropped:0 overruns:0 frame:0
TX packets:561667351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:274569206 (261.8 MiB) TX bytes:3865421410 (3.5 GiB)
bartoki:~$
- frame:0
- collisions:0

Illetve a kliensen "nfsstat -c", es nezni a "retrans" erteket. Ha a
csomag pl. 2 switch kozott veszik el, akkor az ifconfig egyik oldalon
sem fog hibat mutatni.

Gabor

[Bartók István]

Post by Gabor Gombas

Post by Bartók István
- frame:0
- collisions:0

Illetve a kliensen "nfsstat -c", es nezni a "retrans" erteket. Ha a
csomag pl. 2 switch kozott veszik el, akkor az ifconfig egyik oldalon
sem fog hibat mutatni.

Érdemes lehet még a "netstat -s" nézegetése is, abból is kisülnek
mindenféle retransmit meg bad segment dolgok...

[Kosa Attila]

Post by Bartók István
ps: bocs hogy az előző mailemmel elrontottam a Subjectet, most már így
hagyom hogy legalább ezek a levelek egy threadben legyenek :(

Nem a Subject-tol fugg a levelek thread-be rendezese, legalabbis
rendes levelezoprogram eseten :) Az In-Reply-To sor az a
levelben, amely alapjan peldaul a mutt vegzi a thread-be
rendezest.