10Kb/s max letöltési sebesség

Ubuntu Linux

Sziasztok!

Adott egy új vas Gigabyte EP35-DS3, Intel E8200, 2x2GB DDR2, 2x 500GB WD SATAII HDD.
Debian 4 és Ubuntu 8.04 lett rá külön-külön installálva a teszt kedvéért, de egyikkel sem sikerül 10Kb/s fölé vinni a letöltési sebességet. A gép egy Céges hálózatban lenne File és Web szerver, minden sallang nélkül, egy 4Megás bérelt vonalon. A router egy Cisco 1700 szériás eszköz.

Ha közvetlen router után van kötve sem sikerül a sebességen javítani, sem akkor ha a hálózat bármely végpontjára helyezem a gépet. Próbáltam már IPV6 kikapcs, bekapcs, hálókártya speed setup, dns mahinálás, alaplapi hálókártya letiltás, egy régebbi jól működő kártya beüzemelés, de semmi.

A gépre tesztelésből WinXP is került, ezzel nem merült fel sebesség probléma.

Ugyanez a gép otthoni környezetben ASUS 500GP routerre kötve megy, ami a csövön kifér.

Minden segítőkész ötletet szivesen veszek és kipróbálok.

zsomlEE

  • 5006 megtekintés

( psc | 2008. 06. 27., p – 19:50 )

Véletlen nem alaplapi Realtek hálókártya?

Én nem állítottam, hogy a hardver sz@r, mindössze azt írtam, hogy a Realtek 811B lesz a baj szerintem.
Nem részleteztem, hogy a driver, vagy maga a hardver miatt.
Egy tény, Linux és FreeBSD alatt nekem is (és ahogy olvasom másoknak is) hasonlóan rossz tapasztalataim vannak az említett vezérlővel, illetve hasonló kategóriás, integrált Realtek társaival. Nem tudom, hogy a hardver vagy a driver-e a sz@r, de nem is érdekel, hisz a végeredmény szempontjából tök mindegy. Nem működik jól, és kész. Másmilyen kártyát kell venni.

Sajnos a más kártya verzió 1.0-án túl vagyok egy Realtek 8631 vagy valami hasonló chippes PCI kártyával, de valami "márkásabbal" még bepróbálkozom. Viszont a Realtek oldaláról letöltött driver és a disztribúciókba integrált driverrel sem működött, nem hinném Realtek ennyire bénalenne- Ráadásul évek óta jó tapasztalatom van a hardverrel, és közel 400 gépünk működik Realtek hálókártyával.

Kisarkítottan fogalmaztam: te azt írtad, hogy az a baj, hogy RT811B a kártya. Erre reagáltam, hogy önmagában ez nem lehet a baj, sőt, mivel más szoftverrel működik, így esélyes inkább a szoftveres oldalon keresni a hibát. Sajnos az ópenszósz huszárok hozzáállása/véleménye -tapasztalatok szerint- a fenti, ergo ha Linux alatt problémás valaminek a használata, akkor tök mindegy, hogy más OS-sel csont nélkül működik, a hardver a hibás -- eszükbe sem jut, hogy igen, a Linuxban is lehet hiba. Nem a kárty nem működik jól, hanem Linux alatt problémás a használata -- az openszósz előnyét kihasználva lehet saját drivert hegeszteni hozzá, vagy bugriportolni (bár a bugriport túloldalán is a "vegyélmáshardvert" hozzáállás dívik...), vagy a gyártót keresni -- jó sokan, sokszor, hogy probléma vagyon a cuccal. És persze lehet másfajta kártyát is venni, meg előtte hardverkompatibilitási listát nézegetni...

( cstamas | 2008. 06. 28., szo – 11:51 )

Vegyél bele hálókártyát.

Hálókártya: Intel, Broadcom
hirtelen ez a két név jutott eszembe (nyilvánvaló van még több is).

Amit a realtek gyárt az nem hálókártya.

( tamsa | 2008. 06. 28., szo – 17:57 )

A port amire kötöd milyen beállításokkal bír?
Auto? 10Mb/100Mb Half/Duplex/FullDuplex ?

És a kártya min áll ?

mii-tool és mii-diag mit mond Linux alatt?
WIndows alatt mik a hálókártya beállításai ?

Legyen összhangban a switchport és a hálókártya beáálítása.

Egyes hálókártyák nem értik meg a hálózati eszközzel.

mo.: külön külön összekonfigolni őket.
Ez Realtech cuccokra főleg igaz.

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Hát a router oldali port adatait nem tudom, mivel Eurowebtől bérelt eszköz, nincs rálátásom. :-(
De azt az infót ajánlották szerver oldalon próbáljak 100Mb full duplex, vagy hal duplex beállításokkal, de egyik sem vezetett eredményre. :-(

Mire a szerverhez ér az adat átmegy 2 rack szekérnyen is az adat, 100Mb -os hálózati eszközökkel felszerelt hálózat.

( gyrgyvrs | 2008. 06. 28., szo – 18:05 )

A hálózat egyáltalán milyen sebességű? Routerre közvetlenül rákötve próbáltad (tehát 100 Mb vagy 1 Gb kábellel, server és kliens is közvetlenül kötve), vagy a céges hálón keresztül?
szerk
Ja, ha WinXP-vel megy, akkor nem ez a gond, bocsi...

( maniac | 2008. 06. 28., szo – 19:14 )

99%, hogy a linuxos modullal van baj. Probalj meg ujabb kernelt, vagy masik halokartyat.

Ha csak a céges hálón nem megy, akkor én is a kártya duplexitását, sebességbeállítását nézném meg, és ugyanarra állítanám, amire a switchport, amin lóg, be lett húzva. Hint: az "auto/auto" megoldás (majd összefütyülnek a portok) rejtélyes hibák és sebességproblémák okozója, érdemes fixre behúzni mind a két végén. (Egyébként ezt is befolyásolja az, hogy milyen szoftverrel tekeri az emberfia az adott kártyát...)

A router valszeg "Auto"-ra van állítva, de linux oldalon próbálkoztam duplexitást állítani, de nem lett jobb a helyzet. HA minden kötél szakad a router oldalon még próbálkozom a szolgáltatóval, csak elég nehéz lesz megértetni velük, hogy nem megy 1 gép a 400 közül, és ez az ő routerük hibája. :-(

Drivert már a legújabbat feltettem.

Nem managelhető switchek vannak a rack szekrényben, csak mezei 10/100-as Planet 24 portosok, ha jól emlékszem.
Próbáltam már minden variációt, router-switch-gép. router-gép, router-xxxx switch-gép. de semmi cáltozás.

400 portja nincs. :-) A 400 gépet VPN-ben az országban 60 telephelyen szedem össze, de a központunkban 80 gép körül vagyunk "csak". :-)

Aham. Ha a switc-en nem lehet duplexitást/sebességet betrótozni, akkor a gépen sem érdemes ezzel foglalkozni, javítani így nem fog a helyzeten, az viszont látszik, hogy Win alatt megy, Linux alatt nem -- vagy heggggggeszt valaki hozzá jó kernelmodult, vagy Windows-only megoldás lesz ebben a kombinációban...

Újra aktuálissá vált a téma és egyre rémisztőbb.

Ubuntu 8.10 megjelenésében bizakodtam, hát a helyzet változatlan, fogtam egy új(1 hónapos) és egy régebbi(4 éves) vasat, hát a helyzet változatlan, majd fogtam egy 3com, linksys kártyát a helyzet változatlan... IPV6 persze kikapcsolva, hátha az a gond...

Dühömben feltettem egy debian 3.1r5-öt és láss csodát hasít, mi a "fax" külömbség lehet a hálózatkezelésben??? hol keressem a 2 rendszer között a hibát a rendszermag és a csomag verziókon kívül? :-(

hmm ez így nem annyira informális, hogy ezt meg azt a distribet feltettem. Inkább úgy kellene megközelíteni, hogy ez a kernel van fennt, és ezzel a kernellel egy másigk gépről tudok ftp-zni oda vissza full sebességgel vagy sem.
Ha ez megvan akkor jöhet a cisco (persze ha előtte ott a planet akkor már szerintem nem oszt szoroz jelen esetben)

Szóval diagnosztika:

-1, Melyik kernel hogyan ismeri fel.
-2, # ethtool eth0 mit mutat?
-3, másik gép azonos switchen hogyan érhető el ftp protokollon? (oda-vissza!)

aztán majd lehet továbbmenni!

A kernel dolgot megnézem köszönöm, de önmagában a rendszer stabil és full sebességgel tudok rá másolni switchen keresztül. :-( A ciscoba nem tudok bele lépni, mert inviteltől béreljük, kb 6 éves eszköz bérelt vonali, és hiába jelzem feléjük a nyűgömet széttárják a kezüket. :-(

Vegigolvastam az egesz eddigi hiszteriat. Esetleg meg-e lehetne-e oldani-e, hogy copy-and-paste modon a sokszaz segitokesz ember lasson vegre mondjuk:
uname -a
ethtool eth0
kimenetet a mukodo konfig (debil lany) es akarmi mas linux ami nem megy rendszerekrol? Vagy mondjuk azt a trivialis infot, amit egy dmesg erre a szarra ki tud irni?

Itt mar tobben kertek ilyesmit, de csak hallgatas volt a vege.

UBUNTU 8.10 nem működő:

Linux intranet2 2.6.27-7-server #1 SMP Tue Nov 4 20:16:57 UTC 2008 x86_64 GNU/Linux

Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes

driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:04:00.0

Egy kis sebességteszt:

root@intranet2:~# wget ftp://ftp.fsn.hu/pub/mozilla/firefox/releases/3.1b1/linux-i686/hu/firef…
--2008-11-11 08:47:51-- ftp://ftp.fsn.hu/pub/mozilla/firefox/releases/3.1b1/linux-i686/hu/firef…
=> `firefox-3.1b1.tar.bz2'
Resolving ftp.fsn.hu... 195.228.252.133
Connecting to ftp.fsn.hu|195.228.252.133|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/mozilla/firefox/releases/3.1b1/linux-i686/hu ... done.
==> SIZE firefox-3.1b1.tar.bz2 ... 9771213
==> PASV ... done. ==> RETR firefox-3.1b1.tar.bz2 ... done.
Length: 9771213 (9,3M)

0% [ ] 14.280 594B/s eta 4h 43m

Most feldobom rá a deb 3.1r5-öt egy másik vinyóra és kimásolom ugyanezt.

A jelenleg működő szerver adatai:

Linux intranet 2.4.27-2-386 #1 Wed Nov 30 21:38:51 JST 2005 i686 GNU/Linux

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: puag
Wake-on: g
Link detected: yes

driver: e100
version: 2.3.43-k1
firmware-version: N/A
bus-info: 02:0c.0

( LGee | 2008. 07. 03., cs – 16:22 )

dmesg/ethtool stb alapjan a kartya ilyen sebessegen megy?

( sirenter | 2008. 11. 11., k – 09:35 )

Az ioatdma kernelmodul betöltése is megérne egy kipróbálást.

( sirenter | 2008. 11. 11., k – 09:50 )

# lsmod
ha nincs a listában, akkor:
# modprobe ioatdma

( informer v | 2008. 11. 11., k – 11:59 )

kitennél a netre valahová egy ilyet:

foo#tcpdump -i eth0 -c 100 -s 0 -w ./tcpdump.raw

letöltenénk és belenéznénk mi is megy arrafelé?

A gép a x.x.32.230 fix IP-s
A x.x.32.254 az egy másik Linux szerver(LAMP,SMB) szintén fix ip-s, de nem gateway, viszont intel a hardver.
A gateway az x.x.32.1 lenne.

A ciscon nincs 2 ip tartomány csak a x.x.32.x-be tartozik (DHCP-ve osztja a gépeknek), hogy amúgy a béreltvonal felöl mi a fix ip, azt nem tudom.

Most feltettem egy másik dump-ot, amit letöltés közben készítettem, ITT található

egyébként megnézve a csomagokat, én úgy látom, hogy befelé jön lassan a cumó. Azt hinné az ember, hogy a küldő lassú de nem.
vagy nagy a collision azon a hálón, de érdekes hogy Rx az meg jó, tehát vagy cserélj kábelt vagy a driver nem tudja feldolgozni időben a bejövő csomagokat. (esetleg IRQ probléma?)

Persze ezt cáfolja a belső forgalom ami meg tökéletes(? a x.x.32.46 -ra ha scp-zel vagy ftp-zel oda vissza az meg jó? ki lehet hajtani 9MByte/sec -cel?).

amúgy passz :-(

( arpi_esp v | 2008. 11. 11., k – 14:51 )

tipikusan halfduplex-fullduplex mismatch eseten szokott ilyen sebessegre lelassulni. azaz ha az egyik eszkoz fullduplexre van allitva, a masik pedig half-ra. feltetelezem csak egyik (letoltes) iranyba lassu ennyire, masik iranyba jobb a speed.

cisco eszkozok legendasan szarok autonegotation tekinteteben, ritkan sikerul eltalalniuk a megfelelo beallitasokat, jobb kezzel fixen bealllitani, persze ehhez hozza kene ferned a routerhez/switchhez. mivel - ha jol ertettem - ugyanez a gep+rendszer masik halozaton mukodik normalis sebesseggel, en a halozati eszkozokben keresnem a megoldast.

esetleg alitsd be kezzel a halokartyat halfduplex-re (ethtool-al). es nezd meg ugy.

A'rpi

A gépet a hálózat több pontján próbáltam különböző kábelekkel, sőt mint az elején valahol írtam a routerre közvetlenül kötve sem sikerült semmit kihozni belőle... :-(

Egyszer a duplexitásokat és sebességeket állítva sikerült egy 50-60k körüli érétket elérni, de azóta se sehogyan, az valami csoda folytán lehetett.

Dühömben kértem, hogy a routert cseréljék le, ami megint hetek kérdése. :-(

No szerintem nézzük elöször a dolgoket, azt láttam, hogy elég sokmindent kipróbáltál, de az tény, hogy nálad hasít bent meg nem, így én kizárnék egy csomó dolgot, és inkább a dobozon kívül keresném a gondoket.
Kezd el pingelni a router, vagy már cucc ip-jét. Esetleg a router külső lábának IP-jét, vagy a szolgáltatói vonal másik oldalán lévő IP-t (biztos adnak egyet, amit lehet)
Ezután növeld a csomag méretét.
ping host -s 1400
ping host -s 1500 -M do
esetleg kapcsold be, hogy ne fragment-áljon, így megtudod mekkora MTU-t tud fogadn a távoli oldal.
Mert ez okozhat lassulást. Ha csökkenteni kell az MTU-t, azt az iptables-ben tudod megtenni.
Ha már ennyit dolgozol rajta, egy tesztet még megér

itt most nem a fiziai kapcsolatra gondoltam, mert minek csökkentsem a fiziai interface mtu-ját, ha az jó, de lehet egy olyan csatorna amin már nem jó az addigi mtu méret, és ha a kettő közötti eszköz nem tud fragmentálni, vagy azt a csomag nem engedi meg, akkor dobódik/hat. ilyen pl az adsl kapcsolat ahol ugyebár a pppoe miatt lecsökken a csomagméret maximuma, a pppoe head miatt.
Ekkor sem a fizikai if paramétereit állítod, hanem csinálsz egy rule bejegyzést.
hát így.

Szia,

Illetve szia mindenki! Lehet már nem érdekel senkit, de a probléma megoldódott. Feb elején Invitel kicserélte routert, de nem ez lett a megoldás, hanem:

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

Ha valakit érdekel a miért az bővebben belekutakodhat a dologba.

Üdv: zsomLEE