Globális DMA probléma?

 ( trey | 2003. február 17., hétfő - 8:38 )

Globális DMA probléma?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Adott egy rendszer, csontig AMD cuccokbol, alaplapon is AMD chipset, legujabb kernel, ac2 -es patchel, es ide vinyok kozotti masolasnal megzabalja a procit, es pedig a kernel jol van konfigolva. Mi lehet itt a baj ? Itt epp forditva esetleg, hogy ac patch nem kene ?

[ Ezt az üzenetet szerkesztette:: Tomcsi 15-02-2003 03:00 ]

Mielõtt még teljesen eltemetnétek a linuxot!



Az UDMA módokhoz nem elég a drive-ot UDMA módba kapcsolni, ehhez az (alaplapi) IDE vezérlõt is be kell állítani, jobban mondva a kernelnek kezelnie kell tudni. (A general PCI IDE nem tudja az UDMA-t beállítani, mivel ez a rész igencsak chipset specifikus )Az alaplapi vezérlõ aktuális beállításairól az infokat, a /proc/ide könyvtárban találjátok. Itt kell lenni egy drivers file-nak, amiben az aktuális kernel driverek nevei vannak, meg egy másik file-nak, ahol az IDE vezérlõrõl az infók leledzenek. Pl. az én ALI-s alaplapomnál ez egy ali nevõ file. (VIA-snál pl. via, stb...) Ha nincs ilyen file-od, akkor mégsem jók a kernel beállítások, és így az UDMA-t sem használhatod.



Ha megnyitod a file-t, akkor általában egy táblázatos formában találsz infókat a vezérlõhöz csatlakozó drive-ok beállításáról.



Az UDMA nagyon jó, csak több szûk keresztmetszete is van a dolognak. Ugyanis, amit meg szoktak adni (33, 66, 100, 133Mb/s), az a maximális transzfer sebesség, nem az átlagos. Ezt a harddisk egész szépen tudja tartani, amíg a buffere (pár MB) ki nem ürül, ezután sajnos életbe lép a media->buffer átviteli sebesség, ami egy átlagos 7200rpm-es drive-nál ugy a 20-30Mb/s körül van. Persze ez az átviteli sebesség is változik egy diszken belül, attól függõen, hogy kívül, vagy belül jár a fej (mintha valami hasonló lenne a CD-k nél is ), nomeg a drive-tól is függ :- D . pl. egy 10G Maxtor drive benche (Winfo$)



Szóval, ha még a dologhoz hozzáadsz egy kis seek-elési idõt, máris odaértél a 20Mb/s sebesség közelébe, ami egy reális átviteli sebesség egy reális drive esetén .



pl. nálam a hdparm -tT /dev/hda a következõt adja:



/dev/hda:

Timing buffer-cache reads: 128 MB in 2.21 seconds = 57.92 MB/sec

Timing buffered disk reads: 64 MB in 2.31 seconds = 27.71 MB/sec



a /dev/hdb:



/dev/hdb:

Timing buffer-cache reads: 128 MB in 2.38 seconds = 53.78 MB/sec

Timing buffered disk reads: 64 MB in 8.83 seconds = 7.25 MB/sec



A hda-m egy Maxtor 5400rpm 80G UDMA-4-el (66MHz), a hdb-m egy 1G Maxtor DMA2-vel.



Egy másik 20G IBM winchi tesztje PIIX chipsetes alaplapi vezérlővel (szintén udma4):



/dev/hda:

Timing buffer-cache reads: 128 MB in 1.54 seconds = 83.28 MB/sec

Timing buffered disk reads: 64 MB in 2.13 seconds = 30.00 MB/sec



Mindezekből látszik, hogy igaziból a 33MHz-es udma simán elég a nagy file-ok (általában >2MB) esetén, hiszen a media->buffer transzfer nem gyorsabb ennél általában. Amúgy pl. a 10000rpm-es SCSI vinyók is kb. 30Mb/s körüli transzfert tudnak (hiába no, azokban is ugyanaz a fizika ) Ez egy 18G 10200rpm-es UWSCSI winchester benchmark-ja



Ja, egyes vezérlõknél elõfordulhat, hogy vagy mindkét ?drive? (vagy ?csatorna?, már nem emlékszek pontosan) UDMA, vagy egyik sem, így ha föllógatsz egy olyan drive-ot is, ami nem UDMA-s, akkor cs*szheted az egészet...



Windows-Linux file transfer külömbség persze nem lehet 20Mb/s. Az 1-2 Mb/s-es sebesség egyértelmúen azt jelenti, hogy kb. PIO4-ben dolgozik a drive . A filerendszertõl, jobban mondva annak kezelésétõl meg egyáltalán nem független a sebesség, hiszen a file-t olvasni kell (fragmentáltság esetén jo sokat seek-elni, meg ha nincs az allokációs tábla memóriában cach-elve, akkor amúgy is ), nomeg írni kell, azaz a megfelelõ bejegyzéseket betenni a megfelelõ helyre (ujabb finom seek-ek) , meg miegymás. Szóval a filerendszer független másolás legföljebb dd if=/dev/hda1 of=/dev/hdb2. Ja, ha egy winchester két partíciója között másolsz, akkor ne csodálkozz, hogy ´tetű´, extrán seek-elni kell a drágának, ha nem fér el valami memória cache-ben a file



Zsiráf



U.i.: Ja, a 2.4.20 esetén az ALI-s driver kiakad, frissíteni kell 21preXXX-re

U.i.: Ha meg zenét halgatsz közben (ugyannarról a winchesterről), akkor szegény vinyódnak seek-elni kell mint atom, úgyhogy ne csodálkozz, hogy nagyobb audio buffer nélkül néha beleszaggat, már bocs



[ Ezt az üzenetet szerkesztette:: szaszg 17-02-2003 09:11 ]

Globális DMA probléma?



 YikeSS

Hmm, nem látom a kérdest. Vagy talán ez a kérdés? Mire gondolsz konkrétan?

Szarakodik itt ez a rohadt net... eh...



EZ A KERDES:



A kovetkezo problemara keresek gyogyirt:

Ugy nez ki, hogy valami "globalis DMA gond" vagy irtonagy lamasag lehet korulottem linuxszerte, mert tobb kulonbozo konfiguracioju gepen is tapasztaltam a problemat. De konkretan az en gepemen.

Adott egy ASUS BX chipsetes alaplap PIII 667-es CPU-val,512MB RAM, Adaptec 29160 SCSI + 2db 10000RPM IBM SCSI HDD, 1db Maxtor 40GB IDE HDD.



Debian SID fut rajta 2.4.5-os kernellel.

Az a gondom, hogy barmelyik HDD-rol barmelyik masikra masolni qrva lassu, es NAGYON terheli a CPU-t. Akar SCSI-rol SCSI-re, akar IDE-rol IDE-re, akar SCSI-rol IDE-re, es forditva is.



Olyannyira lassu, hogy 2-3MB/sec-os sebesseggel megy, a CPU pedig akar 95%-os terheltseget is eleri. IDE HDD-nel HDPARM beallitva, kernelben elvileg minden normalisan bekonfig-va. Probaltam mar tobb kernellel is.



Az erdekesseg, hogy ezt mas gepeken is tapasztaltan mar, es Win2K alatt minden nagyon gyors, tehat elvileg nem HW problema van. Probaltam mar segitseget kerni irc-n is, de senki nem tudott semmi hasznosat.



Akit tud segitsen plz!.



Koszi.

A probléma ismero"s, sajnos nekem is jelentkezik. Linux alatt nem tudom a DMA -t 100% -kig kihasználni, hiába van a kernelbe a Use DMA if possible opció belefordítva.



Mellé még hdparm -al is rásegítek, de az eredmény kicsit javul csak.



Engem is érdekelne egy 100% -ig biztos, hatékony megoldás.

Az, hogy a másolás milyen gyors, az sok mindento"l függ:



kernel verzió

dma, stb beállítások...

fájlrendszer



Tapasztalatok: 2.4-es kernel: 1 darabig jó... de 500 MB fölötti fájloknál már lelassul.

2.2 jó, de régi, és pl. nincs reiser benne

reiser alapjában véve is picit lassúnak tu"nik ext2-höz képest, de gyorsabban helyreáll.

(ext3-at még nem próbáltam.)



Nálam másolásnál, ide-ide esetben 10-20 MByte/sec körül szokott produkálni: Vinyó: UDMA66 és UDMA100-as 5400 RPM-es Maxtorokkal...



PS.: vfat-vfat másolás kínszenvedés, bármilyen kernel mellett is...



gyu

Hat elhiszem, hogy sokmindentol fugg, de olyan kulonbseget elkepesztoen brutalisnak tartok, hogy:



Win alatt 17-20Mbyte/sec-el masolok barhonnan-barhova, linux alatt pedig 1-3 Mbyte, hat az azert tulzas. Fuggetlenul file-rendszertol, kernelverziotol, sehogy sem tudom normalis mukodesre birni. Szamomra ez a rendszer igy kesz rohej, de munkara totalisan alkalmatlan.



YikeSS

Ez tényleg túlzas, én is 10-20 MB/s (reiserFS -el) között tudok másolni, nálad valami más gáz lehet. Az 1-2 MB/s az kevés, valami nagyon el van szúrva ott.

Gond mint nalam. Volt.

Ujrarakod az egesz rendszered, csak amikor keri installnal a driver floppy-kat akkor leszeded az udma drivereket (4db floppy) potatohoz, es berakod, o" meg felmasolja fingom sincs hova. (ha feltudod masolni szimplan nemkell ujrarakni).



Nem tudom hogy mennyire van hatassal az scsi-re de szerintem ezzel megoldodik az udma-s es az scsi-s gondod is.



Ez az egyetlen otletem van...



En is szoptam amugy vele egy ideig.

(proci 100%on, kurva lassu, neha 5-6mp-re meghalt az egesz rendszerem)



Anonymous

Amúgy szerintem is kellő nagy probláma még a linux alatt DMA kezelés nem ártana ha mielőbb megcsinálnák, mert nagy a sebességkülönbség ez ügyben.



Én is 2.4.5-os kernelt használok ext2-vel, ezek vannak befordítva a kernelbe:



ATA/IDE/MFM/RLL support-on belül



Include IDE/ATA-2 DISK support

Include IDE/ATAPI CDROM support

[x] Generic PCI IDE chipset support

[x] Sharing PCI IDE interrupts support

[x] Generic PCI bus-master DMA support

[x] Use PCI DMA by default when available

[x] HPT366 chipset support

[x] Intel PIIXn chipsets support



hdparm-mal leellenőriztem és automatikusan rárakta mindenre vfat-vfat ISO 3-5MB/seccel vitte, bár amire másoltam egy lassú vinyó

vfat-ext2 ISO file kezdetben 17MB de 30%nal már 7MB/sec volt és csökkent tovább

ext2-ext2 nem tudtam teszteni, nincs kettő ext2s patrim, egyen meg nem volt értelme

a mérés alkalmával nem futott X és ssh-val csináltam (Celeron400 - 5400as vinyók)

epp ez a gondom, hogy a 30%-nal, mar csak 7MB a vegere meg mar csak 1. Azert lassul le, mert az elejen meg cache-be tolja, es az MC az vegig atlagot, szamol, ezert egyre kevesebbet mutat.



Szoval ez igy nem igazan jo. Szamomra a linux igy egy hasznalhatatlan szar. Sajnos igy gyakorlatilag semmire sem alkalmas, ahol nagyobb file-okkal is kell foglalkozni.



Kesz rohej.



Yikess

nekem is ugyan ez volt a problémám, de sikerült megoldani a hdparm nevű soft segitségével, konzolos, és könnyedén be lehet kapcsolni a DMA-t az adott eszközön, azóta semmi processzor terhelés másoláskor, én a rpmfind-ról töltöttem le.



the_coder

Ize, hdparm resze minden normalis disztribucionak. Pl. debian alatt megfelelo sources.list eseten:



apt-get install hdparm



Es mar hasznalhato is.



Udv: trey

Azert nem ilyen egyszeru az elet.

Pl nekem aTA100-as vinyo/alaplap.

(Soltek75DRV+Maxtro40G 7200rpm)



Kernelnel generic DMA support+VIA. Az eredmeny UDMA2-re tudom feltenni max.



Egyik gyerek ajanlotta IRC-n, hogy ne tegyek bele VIAxxx-et, csak genereicet.

Az eredmeny 95%CPU, a zene elkezd recsegni lehalkul alnyulik, majd megis szunik, a geppel valo kommunikacio is lelassul/megall egy idore(konzolvaltas pl)

Ezutan visszaraktam a VIACxxx supportot, most jo viszonylag, csak masolasnal (nagyobb fajl=4G felett), 20mp-kent megakad a zene. UDMA2 -re tudom feltenni max hdparm-mal.

UDMA 3/4/5 nem elerheto, vaalmi ilyesmit ir ki.



Ma meg megprobalom kiszedni a Generic supportot, es csak VIACxxx bennehagyni. Akkor mi lesz.



Szoval akinek nagyon nagy problemaja van veole ne forgasson bele a kernelbe minden chipsetet amit lat, csak ami tenyleg van a gepen.



Masik gpeen kb ugyanetz a konfignal megy az UDMA5. Szoval meg probalkozok.(igaz az RH)

De tolem vette a configfajlt a kernelhez..;PP

Elobb hulyeseget mondtam egy kicsit, ha a Generic Dma-t kiveszem, akkro az egesz DMA supportot kiveszem.

Szoal akkor nem tudok VIA chipsete valasztani.

Van ugyan meg par opcio amirol foggalmam sincs, hogy mi(vmi interrupts is van), de nem ertem a helpjet se annyira.



Szoal nagyon ugy nez ki, hogy nem megy.



Lehet, hogy a hdparm hibaja?



Nemtom.

Viszont jo lenne kideriteni!



Ha valaki meg Soltek75DRVx alaplapot hazsnal linux alatt, az irja mar be, hogy neki hogy sikerult az UDMA5...

Kosz.

Mielott eltemeted a linuxodat, probald meg egy kicsit ujabb kernellel is megmozditani es valoszinu erdemes lesz megpatch-elned ´-ac´-vel.



Udv: qzy