ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Miért lassú a Linux...... amikor USB -s pendrájvra másolok? Pl. dd -vel vagy dd_rescue -val kiírok egy iso fájlt, ilyenkor ugye a fájlrendszer (ntfs-3g vagy vfat) nem lassítótényező, mert közvetlen a /dev/sdX -re írok és iso9660 lesz a fájlrendszer. Kb. normál sebességgel (~2400 Kbyte/sec) megy az írás a pendrájvra, de maga a rendszer közben használhatatlanul lassú, még az egérmutató is szaggat és a load felmegy 6.0 körülire. Nem tudok ablakot váltani, terminált váltani, stb.
# uname -a
Linux archlinux 3.0-ARCH #1 SMP PREEMPT Sat Aug 6 16:18:35 CEST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel GNU/Linux
# dmesg | tail
[ 989.951390] device-mapper: uevent: version 1.0.3
[ 989.951537] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised:
[ 1585.059900] usb 2-2: new high speed USB device number 2 using ehci_hcd
[ 1585.720353] Initializing USB Mass Storage driver...
[ 1585.720958] scsi2 : usb-storage 2-2:1.0
[ 1585.721127] usbcore: registered new interface driver usb-storage
[ 1585.721128] USB Mass Storage support registered.
[ 1585.736938] usbcore: registered new interface driver uas
[ 1586.721205] scsi 2:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
[ 1586.721484] sd 2:0:0:0: Attached scsi generic sg2 type 0
[ 1586.956450] sd 2:0:0:0: [sdb] 3903488 512-byte logical blocks: (1.99 GB/1.86 GiB)
[ 1586.956923] sd 2:0:0:0: [sdb] Write Protect is off
[ 1586.956927] sd 2:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 1586.957433] sd 2:0:0:0: [sdb] No Caching mode page present
[ 1586.957437] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1586.959916] sd 2:0:0:0: [sdb] No Caching mode page present
[ 1586.959922] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1586.963626] sd 2:0:0:0: [sdb] No Caching mode page present
[ 1586.963630] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1586.963633] sd 2:0:0:0: [sdb] Attached SCSI removable disk
# lshw -C disk
*-disk
description: SCSI Disk
physical id: 0.0.0
bus info: scsi@2:0.0.0
logical name: /dev/sdb
size: 1906MiB (1998MB)
capabilities: partitioned partitioned:dos
configuration: signature=7fffffff
Az IO scheduler lenne a gond vagy mi? Próbáltam a Con Kolivas BFS -t is, azzal is ugyanez a helyzet. Persze nemcsak Archon van ez a gondom, minden eddig használt disztrón belefutottam ebbe.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 7% Összes szavazat: 562
Új felhasználók
InformációKövess minket!Partnerünk |
+1
de a windows sem jobb. az usb a szar szerintem. utálom is!
/o\
értem én :), de pont ezt /o\ csináltam a héten eközben:
egy ubuntu 10.04-es gépről (hw: amd x2 4600, 2GB ram, valamilyen nforce chipset) egy arra rádugott samsung story 1TB lemezről (ntfs) le kellett mentenem az összes cumót (30-40GB-os backupok fájlok, tgz), újraformázni ext4-re, majd vissza rá a cumót. mivel nem volt elég hely a gépben lévő vinyón, ezért azt csináltam, hogy felcsatoltam a samsungot, és a saját munkahelyi gépemre (vista x64, hw: e8500, 8GB ram, valamilyen intel ich10r) húztam át az adatot ftp-vel (vsftp + "totikomi", gigabiten). de mivel azon sem volt elég a hely, ezért az egyik felét a gépben lévő vinyóra másoltam, a maradékot pedig a gépre rádugott usb-s vinyóra mentettem (wd scorpio blue). majd miután kész volt a másolás és a formázás, akkor ugyanez a kaland csak visszafelé.
eredmény: az ubuntus gépen végig a cpu 100% iowait (egyik mag) + 100% system (másik mag), load 6-7. közben rá-vnc-ztem, hogy wtf, és kicsit lassan nyitogatta az ablakokat meg hasonlók, de azért végülis nem roskadt meg teljesen (közben ez samba szerver is, azon nem volt érezhető lassulás). eközben a saját gépem, amire másoltam, azon semmi észlelhető nem volt közben. de miután a ráakasztott usb-re folytattam a másolást, akkor azon is ugyanez: 50% cpu usage (egyik mag), és lassú, akadozik az ablakváltás, stb. visszafelé másolásnál ugyanez: amint usb használatba került, lassúvá vált a rendszer.
próbáltam kikapcsolt vírusirtóval, "totikomi" helyett filezillával, de semmi különbség. a sebesség pedig átlagban 15, néha 20MB/s volt.
uhci_hcd nincs betöltve véletlenül?
De. Ez baj? o.O
szerk: eltávolítottam az uhci_hcd modult és a probléma ugyanúgy jelentkezik, csak mellé még az usb -s egerem sem működik.
Olvastam olyat, hogy a modulok betöltésének sorrendje nem mindegy, de már nem emlékszem, hogy mi a tuti. Esetleg vedd ki mindkettőt és töltsd vissza őket így is, úgy is. Már ha ígéretesebb ötletet nem kaptál, mert ez eléggé hátha...
Meghajtóid SATA, IDE?
CD írás közben is jelentkezik esetleg a belassulás?
SATA meghajtóim vannak (Lenovo ThinkPad laptop perpill, de korábban más gépeken is előjött a probléma), Hitachi HDD + Optiarc DVD író. CD/DVD írás közben nincs ilyen gondom. Viszont pendrájvból kipróbáltam több különböző márkát és modellt (Kingston, Adata), minddel ugyanez van.
Akkor viszont Fishernél lesz a pont szerintem.
szerk: amint látom, nem jött be.
irq conflictre tippelnek
cat /proc/interrupts
rescheduling...
aztan nezd meg az smp affinity temat, lehet az segit (ha nagy a cpu load is mikozben akadozik a gep)
(2.6.39-ben voltak usb-s powermanagement gondok, aztan a mostani 3.0.0-t is levaltotta mar a 3.0.1 ...)
Már 3.0.1 van fent, de az "uname -a" a fenti sort dobja. Részletesebb infó erről:
Interrupts:
# cat /proc/interrupts CPU0 CPU1 0: 97833 113823 IO-APIC-edge timer 1: 502 262 IO-APIC-edge i8042 8: 0 1 IO-APIC-edge rtc0 9: 1108 1110 IO-APIC-fasteoi acpi 12: 1337 1151 IO-APIC-edge i8042 14: 7664 6654 IO-APIC-edge ata_piix 15: 5089 3784 IO-APIC-edge ata_piix 16: 0 0 IO-APIC-fasteoi yenta, uhci_hcd:usb5 17: 10 7 IO-APIC-fasteoi firewire_ohci, uhci_hcd:usb6 18: 0 0 IO-APIC-fasteoi r592, mmc0, uhci_hcd:usb7 19: 14407 12279 IO-APIC-fasteoi ehci_hcd:usb2 20: 53 35 IO-APIC-fasteoi uhci_hcd:usb3 21: 6056 3769 IO-APIC-fasteoi uhci_hcd:usb4 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 40: 0 0 PCI-MSI-edge PCIe PME 41: 0 0 PCI-MSI-edge PCIe PME 42: 0 0 PCI-MSI-edge PCIe PME 43: 0 0 PCI-MSI-edge PCIe PME 44: 0 0 PCI-MSI-edge PCIe PME 45: 9461 7390 PCI-MSI-edge i915 46: 432 88 PCI-MSI-edge eth0 47: 12064 5631 PCI-MSI-edge iwl4965 48: 419 340 PCI-MSI-edge hda_intel NMI: 44 43 Non-maskable interrupts LOC: 67202 71032 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 44 43 Performance monitoring interrupts IWI: 0 0 IRQ work interrupts RES: 107328 110344 Rescheduling interrupts CAL: 108 158 Function call interrupts TLB: 1002 926 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 4 4 Machine check polls ERR: 0 MIS: 0A többit megnézem, köszi a tippet!
Kipróbáltam.
dd if=oneiric-desktop-i386.iso of=/dev/sdb
Semmi ilyesmit sem tapasztaltam. A CPU terhelés 10% alatt, a load nem száll el, közben a rendszer teljesen reszponzív.
iostat -d 5 -p sdb
--
trey @ gépház
Csak próbaképp nullákat írtam, hogy ne legyen az olvasás miatt + szűk keresztmetszet:
A cpu használat 3-15% között ugrál, memória van ~1GB szabad a 2GB -ból, swap -hoz nem nyúl a rendszer. S mellé nagyon irreszponzív, nem tudok csinálni semmit.
Mivel a "lassú" elég megfoghatatlan, csináltam egy videót az én rendszeremről miközben USB-re dd-zek. Közben megy egy recordmydesktop is. Az fogja nagyrészt a rendszert.
Ennél neked lassabb?
http://hup.hu/treyblog/20110807/re__miert_lassu_a_linux_amikor_usb-s
--
trey @ gépház
Nagyságrendekkel lassabb. Gyakorlatilag úgy kell elképzelni, hogy pl. ablakot sem tudok váltani, nemhogy recordmydesktop -ot futtatni. :/
(köszi a videót egyébként, ilyen sebességnek örülnék)
Ennyi adatból egyetlen különbséget látok csak. Neked 64 bites nekem 32 bites rendszer van. Illetve nekem T6670 processzorom van. Ez is Thinkpad. Ja, meg az, hogy nekem 2.6.38 kernel van, neked 3.0. Próbáltad már régebbi kernellel?
--
trey @ gépház
Kipróbálom a 2.6.32 -est, az van az Archoz, mint LTS. Bár korábban is volt ilyen gondom (2.6.32 kernellel, meg amiket gyárilag tartalmaztak ezek a disztrók). Ha úgysem jó, akkor kipróbálok egy 32bites rendszert.
Szerk: kipróbáltam egy 32bites Ubuntu Nattyn. A load "csak" 3.5 körüli értékre kúszik fel másolás közben, memória ugyanúgy van ~1GB szabad és a procihasználat is megáll 15% alatt. A sar szerint %iowait értéke 85 körül van a másolás során. dmesg | tail is ugyanazokat dobálja, mint 64 bites Archon. Viszont használhatóbb marad a rendszer.
Ha van rajta picimaci vagy expressz, akkor esetleg az is szóba jöhet. ~4k HUF
Látom lecserélted a HP 6720s-t
# dd if=/dev/zero of=/dev/sdh1 bs=1024k count=10241024+0 beolvasott rekord
1024+0 kiírt rekord
1073741824 bájt (1,1 GB) másolva, 163,125 mp, 6,6 MB/s
# top #csak az első sora
top - 22:36:42 up 3:14, 1 user, load average: 2.90, 2.04, 1.10
# iostat -d 5 -p sdh
Linux 3.0-ARCH (cern) 2011-08-08 _x86_64_ (4 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdh 0,97 0,39 107,07 4534 1237458
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdh 40,00 0,00 4800,00 0 24000
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdh 40,00 0,00 4800,00 0 24000
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdh 40,00 0,00 4800,00 0 24000
A rendszer reszponzív, semmi akadás, mintha nem is csinálna a gép semmit.
Desktop gép, AMD athlon II,x640, 4 Gb ram, nforce chipset, előlapi usb-be dugott PNY pendrive, arch alap x64-es kernel.
lspci:
00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)Tudom, ettől most nem lettél okosabb, de mint látod, nem feltétlen az arch kerneljében van a hiba.
---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.
"No Caching mode page present"
"minden eddig használt disztrón belefutottam ebbe"
Milyen disztrók voltak azok?
Esetleg egy 10.10 Ubuntu live cd-vel ki tudod próbálni, hogy azon is ez van-e?
Ja: Winen jó ezen a notin?
Ubuntu 10.04/10.10/11.04, Debian 5/6, Fedora 14, OpenSUSE 11.4, Arch.
Windowson jó ezen a gépen, XP -vel és 7-tel is, ott nincs ilyen gond.
Hát én nem vagyok kernel guru (sem), de a "No Caching mode page present" nem normális, szóval itt kéne kereskedni.
Enyém 2 GB Kingston:
toma@ubx3:~$ dmesg | tail
[ 4207.473144] scsi 7:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
[ 4207.475443] sd 7:0:0:0: Attached scsi generic sg1 type 0
[ 4209.786305] sd 7:0:0:0: [sdb] 3966976 512-byte logical blocks: (2.03 GB/1.89 GiB)
[ 4209.786903] sd 7:0:0:0: [sdb] Write Protect is off
[ 4209.786915] sd 7:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 4209.786924] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 4209.791276] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 4209.838076] sdb: sdb1
[ 4209.840643] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 4209.840661] sd 7:0:0:0: [sdb] Attached SCSI removable disk
Előtúrtam egy másik pendrájvot:
Ezzel is ua.
Milyen ThinkPad ez?
ThinkPad T61 (type: 7659-AB7)
Ez a probléma engem is nagyon idegesít. Több gépen is jelentkezik, tehát nem hardverhiba, viszont a kernelt minden gépen én fordítom, tehát lehet, hogy valamit nem jól csinálok.
A probléma nálam az, hogy az usbnél (és egyébként nfs nél is) nagy write cache időnkénti ürítésekor az egész gép filerendszerei lockolódnak, ami usb1 es pendrive ra másolásnál (pl pda usb storage emulációja) több perc is lehet... Nagyon gáz.
Legjobb az lenne, ha az usbnél, vagy nsfnél nem lenne write cache egyáltalán.
Ha jól gondolom, a tényleges írásnál van ez a lock, tehát az I/O műveletnél. Ezen a sync opcióval történő mount aligha fog segíteni, sőt, mivel a filerendszer leírói minden változásnál kiíródnak a fizikai eszközre, lényegesen lassabb lesz az egész. Így az az idő is több lesz, amíg a kellemetlenség fennáll. Meg hamarabb tönkremegy a pendrive:
sync All I/O to the filesystem should be done synchronously. In caseof media with limited number of write cycles (e.g. some flash
drives) "sync" may cause life-cycle shortening.
Nem tudom, mi a hiba, ugyanakkor valami olyasmi a gyanúm, hogy vagy az USB interface, vagy az eszköz nem támogat valamilyen adatátviteli módot, bufferelt írást, így kénytelen a kernel, tehát a CPU byte-onként írogatni. Szerintem valami ilyesmi lehet a konkrét probléma hátterében, de tegyük hozzá, ez csak fantázia a részemről, nem tudom, így van-e.
tr [:lower:] [:upper:] <<<locsemegeLOCSEMEGE
USB1-en még az olvasás is büntet, nem, hogy az írás. :)
Sajnos a hw kizárható, mivel nfs nél pontosan ugyanez a probléma jelentkezik. Nem az a gond, hogy lassú a feltöltés Internetes nfs re, mert kivárom. Hanem, hogy addig minden lehal, még a tálcán lévő óra sem frissül. Konzolban cat /proc/meminfo nál látszik, hogy a Writeback-et üríti, és addig nem enged semmi írást. Kiürül, utána egy pillanatra OK, majd újra. Emiatt gyakorlatilag használhatatlan az nfs számomra, kivéve ahol min. 100 megabit van gépek között, és az usb is. Nem hiszem, hogy ez normális, de nem tudom mit csinálok rosszul. Egyébként Gentoo, és legújabb kernel (perpill 3as)
Hm.. Nézzetek már egy valamilyen LTS live cuccot, hogy azzal mit mutat. Mindketten 3-as kernellel vagytok, s ugyanaz a para. Ráadásul mindketten olyan disztróval, amiben így vagy úgy hákolni kell (Gentoo és Arch). Töltsetek egy Fedora-t, vagy Ubuntu-t, ami még régebbi kerneles, lehetőleg ne túl friss legyen, hogy a legfrissebb lib verziókat is kizárhassuk, majd uccu neki, dd if=/dev/random of=/dev/usbeszkoz.
Nem lehet, hogy az új kernellel együtt van valami újabb függőség, ami bekavar? Csak magát a kernelt kizárhatjuk, tudomásom szerint trey is 3-asozik, de majd megerősít, vagy nem.
"tudomásom szerint trey is 3-asozik, de majd megerősít, vagy nem."
Nem, én az Ubuntu 11.04 által szállított kernelt használom. Ami jelenleg a 2.6.38-10
--
trey @ gépház
Közben látom, hogy fentebb már ez is ki lett próbálva.
Kipróbáltam VMware alatt az Ubuntu 11.10 alpha3-mal. Abban már 3.0-s kernel van. Abban sem jelentkezik nálam a probléma, bár ott az USB write VMware alatt nem az igazi. Van itthon másik notebookom is, majd lehet, hogy azon is megnézem.
--
trey @ gépház
Kezd egyre gyanúsabb lenni nekem, hogy a srácoknál valami hw összetevő nem klappol linux alatt.
Nem véletlenül kérdeztem a ThinkPad típusát, rákeresve a neten a TinkPadok USB problémáira linuxon van egy halom találat. A T4x-es sorozatnál az ehci letiltása(!) van javasolva, a T6x-eknél meg a cache-es dolog gyakori, illetve egész érdekes tesztfail eredmények vannak...
Kipróbáltam ezt az egészet egy 5 éves notebookon, amiben 1,4GHz-es Celeron, mer 1,2 GB RAM (1GB + 256 MB) van. 3.0-s kernel. Semmi probléma sincs vele. Teljesen reszponzív a rendszer.
--
trey @ gépház
Nem régóta van 3-as, korábban is ugyanezt csinálta. Pont azért rakok mindig legújabb kernelt, mert várom, hogy a probléma magától megoldódjon :D Majd kipróbálom live cdről, más-e.
> Nem az a gond, hogy lassú a feltöltés Internetes nfs re, mert kivárom. Hanem, hogy addig minden lehal
itt érdemes egy percre megállni és főt hajtani: 2011-re a linux már egy netes feltöltést sem bír ki döglés nélkül
Azért valljuk be őszintén, ezzel a szöveggel simán beférsz a gabucino.be-n a hupmeme szekcióba! :D
Én ma futottam bele ebbe, ez a 2.6.38-as THP/compaction regresszió lesz: http://thread.gmane.org/gmane.linux.kernel/1200542
Próbáld ki a következőt, nekem 2.6.40-en megoldotta ezt a jelenséget:
echo never >/sys/kernel/mm/transparent_hugepage/defragFedora hibajegy: https://bugzilla.redhat.com/show_bug.cgi?id=735946
A topicnyitónak valszeg nem ez a gondja, mert az egérmutató szaggatása nem tipikus tünete ennek a regressziónak, no meg szerintem a 32 bitre váltás ezt nem oldaná meg; bár nem ellenőriztem.
Pont tegnap írtam Arch-ról image-t pendrive-ra, majd ma a pendrive-ról raktam fel az iso-t. Sem az íráskor, sem pedig az olvasáskor nem tapasztaltam hasonlót. (kernel 2.6.39)
___
Blogom
{CFS,BFS} != {AS,CFQ,noop,DL}
___
info
Köszi, jogos.
masik tipp: esetleg egy masik pendrive-al probalkozz
vagy ha van esetleg usb-s kulso hdd-d, akkor azzal merd ossze
(nekem sajna volt mar dolgom nagyon gyenge minosegu, lassu pendrival, amire kb 1x cd sebessegevel lehet irni) (bar nem lett tole hasznalhatatlanul lassu a gep)
Megnézem USB-s külső winyóval este, abból is van vagy három.
Van egy tippem, mi lehet a gond. Szerintem nem a géppel, s nem a kernellel van a baj, hanem a device-szal. Fikció, amit írok, de így képzelem.
A kernel megkérdezi az eszközt, mekkora a buffere. Kap egy méretet, s ekkora buffert kezd el tunkolni talán bulk módban. Ugyanakkor itt kapott valami lehetetlenül kis méretet. Ekkor ugye az történik, hogy a pici csomagot elküldi az USB kontrollernek. Éppen kilép a kernel abból a rutinból, amelyik megtömte adattal a kontrollert vagy felhúzta a DMA-t, máris jön az IT a kontrollertől, hogy kész van, átvitte azt a kevés adatot. Kernel újra felhúzza a DMA-t vagy tunkolja az adatot, s így tovább. Tehát a device buffere nagyon kicsi - vagy nincs is -, így aztán állandóan ezzel kell a kernelnek foglalkoznia.
A kernelnek mindössze annyi nyugta marad, amíg kiíródik egy lap a flash-be a pendrive-on. Aztán kezdődik minden elölről. Az a gyanúm, egy normális pendrive-val a jelenség nem jönne elő.
Az én gépem a pendrive-jaim írása, olvasása közben teljesen válaszolékony. Gyanítom, a Te pendrive-oddal nálam is nagyon magas load lenne.
tr [:lower:] [:upper:] <<<locsemegeLOCSEMEGE
Van több pendrive-om: 2x Kingston Datatraveler 2GB, Adata 4GB. Minddel előjön a gond.
Valójában inkább az ellenkezője. Olyan write buffert ír tele a másolásnál, amekkora az eszköznek nincs. Aztán amíg azt üríti, lehal az egész gép.
Ez nem az ellenkezője. Épp ezt írtam. ;) Tehát a device buffere kicsi szerintem is.
Ugyanakkor a visszajelzésből úgy tűnik, más baj lehet.
tr [:lower:] [:upper:] <<<locsemegeLOCSEMEGE
Közben valaki adhatna protippet, hogyan keressek a gondra angolul. Mert rendre csak olyasmit találok, ahol az a júzerek gondja, hogy maga az írási sebesség lassú pendrájvra és nem a rendszer.
"ThinkPad T61" "Asking for cache data failed" "No Caching mode page present"
:)
A "Caching mode page" az az eszköznek egy dolga (a pendrivenak), nem a laptopnak...sdparm-mal le lehet kérdezni a mode pageket, ki lehet próbálni, hogy valóban nincs ilyenje az usb sticknek.
Amúgy kétlem, hogy emiatt lenne lassú.
Na és akkor mi miatt, ne titokzatoskodj már, hahó!?
Hát arról fogalmam sincs :)
De nekem még egy TP-LINK routeren is használható volt az USB (Linux kernellel), valami DMA, IRQ izé, vagy csak simán szar az USB vezérlő/pendrive...
# sdparm -a /dev/sdb /dev/sdb: USB 2.0 USB Flash Drive 0.00 Read write error recovery mode page: AWRE 0 [cha: n, def: 0, sav: 0] ARRE 0 [cha: n, def: 0, sav: 0] TB 0 [cha: y, def: 0, sav: 0] RC 0 [cha: y, def: 0, sav: 0] EER 0 [cha: y, def: 0, sav: 0] PER 0 [cha: y, def: 0, sav: 0] DTE 0 [cha: y, def: 0, sav: 1] DCR 0 [cha: y, def: 0, sav: 0] RRC 10 [cha: y, def: 0, sav: 0] COR_S 0 [cha: y, def: 0, sav: 1] HOC 0 [cha: n, def: 18, sav:244] DSOC 0 [cha: n, def: 0, sav: 11] TPERE 0 [cha: n, def: 0, sav: 0] # sdparm -a /dev/sdc /dev/sdc: Kingston DataTraveler 2.0 PMAP Read write error recovery mode page: AWRE 0 [cha: n, def: 0, sav: 0] ARRE 0 [cha: n, def: 0, sav: 0] TB 0 [cha: n, def: 0, sav: 0] RC 0 [cha: n, def: 0, sav: 0] EER 0 [cha: n, def: 0, sav: 0] PER 0 [cha: n, def: 0, sav: 0] DTE 0 [cha: n, def: 0, sav: 0] DCR 0 [cha: n, def: 0, sav: 0] RRC 48 [cha: y, def: 48, sav:255] COR_S 0 [cha: n, def: 0, sav: 0] HOC 0 [cha: n, def: 0, sav: 0] DSOC 0 [cha: n, def: 0, sav: 0] TPERE 0 [cha: n, def: 0, sav: 0] WRC 68 [cha: y, def: 68, sav: 68] RTL 29793 [cha: y, def:29793, sav:29793] Power condition mode page: STANDBY_Y 0 [cha: n, def: 0, sav: 0] IDLE_C 0 [cha: n, def: 0, sav: 0] IDLE_B 0 [cha: n, def: 0, sav: 0] IDLE 1 [cha: y, def: 1, sav: 1] STANDBY 1 [cha: y, def: 1, sav: 1] ICT 0 [cha: n, def: 0, sav: 0] SCT 1147237473 [cha: y, def:1147237473, sav:1147237473] SAT ATA Power condition mode page: APMP 0 [cha: n, def: 0, sav: 0] APM 0 [cha: n, def: 0, sav: 0]Na, hát tényleg nincs caching mode page, a kernel nem hazudik :)
Ha nagyon nincs jobb ötlet, fordíts preempt nélküli kernelt.
Most frissítettem az mp3 lejátszó tartalmát. cka 800 mega egy rakás fájlban:
mp3 lejátszó async-el csatolva.
Nagyjából ilyen eredménnyel.A CPU átlagban 10% körül maradt.
A load average az ingadozott, de a rendszer egyáltalán nem lockolt. Használt rendszer debian lenny 32bit, 2magos amd, kernel egyedileg összegányolt 2.6.27.y alapú. PREEMPT nincs.
--------
Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.
Amúgy nálad mi volt az a konkrét hiba, amiért ennyire gyűlölöd a preemptív kernelt? :)
--
Don't be an Ubuntard!
1. Az, hogy radikális mértékben csökkentette a hibatűrést, ami 2.6.x óta amúgy sem (volt ?) a linux kernel erőssége.
/ Megjegyezem hogy én 2.6.27.y-nál (y>=50) egyelőre leragadtam,
mert még mindig lusta vagyok squeeze re frissíteni is, még cka fél évig support a lennyre úgyis, úgyhogy lehet hogy azóta a linux kernel csodaszép és hibátlan :-) /
Amennyire emlékszem PaX/grsec -el is mutatott problémát. Persze ez több éves történet,
nem foglalkozok én már IT vel egyáltalán max. r=1 user szinten, az ember egy idő után feladja a kísérletezést,
van jobb dó'gom is.
2. Konkrétan bizonyos hw/kernel hibák bekövetkezésekor fordult elő, hogy zárolta előlem, mint felhasználó elől a rendszert,
hasonló módon mint szubcsinál, ami nem túl meglepő tekintve hogy a preemptív kernel ugye a kernel folyamatokat is simán megszakíthatja,
aztán hogy ennek ugye vannak következményei stabilitás, terhelés terén is, az egy más tészta. ;-)
3. Kb. heti rendszerességel előfordult pl. xorg segfault.
Ami persze lehet ezer más dologtól is, de mikor visszaálltam no preempt+anticiprofaszomra,
érdekes módon ez megszűnt, így nehéz más ok-okozati összefüggést találni.
4. Több benne a marketing, mint a valóság (legalábbis normál desktopon). Ennek persze az is az oka, hogy egy desktop rendszeren is rengeteg szerver típusú alkalmazást futtathatunk (pl. cups, exim.),
nem igazán jellemző az, hogy van egy darab olyan kiemelt alkalmazás, ami annyira fontos, és életbevágó,
hogy futását akár kernel processzek megszakításával is folyamatosan biztosítsuk,
vagy várassuk az usert a parkolóban, amíg egy lomha folyamat méltóztatik befejeződni.
5. Dehogy konkrét példa is legyen vagy 3 évvel ezelőttről egy cpuidle-s kernel bug,
ami preemptív fordítás mellett úgy kizárt a rendszerből s2ram visszatéréskor, hogy resetbe kellett rúgni, ha nem akartam öregestig várni.
Úgyhogy igen, kimondható,
hogy részemről létező dolog a preemptív kernel utálata.
És kb. ez volt az utolsó csepp, nagyjából itt fejeztem be ezt az egész preemtív cirkusszal való kísérletezést,
meg az ütemezőcserélgetést is.
Marad szépen normál nem preemptív, hagyomás anticiprofaszom schedulerrel, és csókolom, múkodik jól, és dolog nincs vele.
Persze tudom, hogy 2.6.27.y már régi ócska akármilyen 60szor kijavították a nyavalyáimat, rigolyáimat a csodaúj kernelekben / talán már a 2.6.27ben is, meg se próbáltam ezzel a preemptív cuccot bevallom /, blabla blabla bla...
sajnos én megrögzött módon maradok a megszokott működő cuccosnál.
Amúgy 3 éve ezt a példa kedvéért említett indoklást mintha már hallottam volna, / régen volt, biztos javították izé /
mikor utoljára kipróbáltam ezt a preemptív nyavalyát.
S lám nincsenek szubcsihoz hasonló gondjaim, majd mikor squeeze-re átállok, majd felhúzok egy debian féle 2.6.32.y-t (nem is tudom hol jár y>=30 körül ?) anticipróval meg preempt nélkül.
--------------
Úgyhogy tippeltem most szubcsinak, hogy esetleg dobja ki a preempt-et, ha más ötlet nincs. 50 % esélye van. Vagy megoldja a problémáját, vagy nem. :-)
Nála is van valami kernel cirkusz a cache hiányával, lehet hogy ez meg a preempt kombó idézi elő, hogy a rendszer baszik a felhasználóra nagy ívben.
Az említett nálam járt legutóbbi konkrét példa is hasonló volt. (cpuidle bug+preempt) Tény és való a két eset között 60 millió kernel verzió és kb. 3 év eltelt.
--------
Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.
Próbáld meg a slow szó helyett az unresponsive szót, vagy a not responsive kifejezést használni.
--
Don't be an Ubuntard!
Legutóbb vásároltam Androidra egy 8 gigás HC-s SD kártyát. Az eladó javasolta, hogy a HC-t vegyem, mert az nagyságrendekkel gyorsabb a nem-HC-nál és egyébként is a 2 gigás eddigi kártyámhoz képest bődületes sebessége lesz majd.
Szóval a tetű lassú kártyámat hipergyors HC kártyára cseréltem.
A kisördög azért ott lapult bennem és ddrescue-val megmértem a sebességeket (olvasás):
Tetű lassú nem-HC: 14000 k/s
Villámgyors HC: 19000 k/s
Hát, tényleg bődületes sebességgel vágtáznak ezek a HC-s kártyák. Végülis nem vert át, mert valóban gyorsabb lett a kártya, csak mondjuk észrevenni nem fogom.
Höhöhö, Speed Class Rating vs. High Capacity fail. :)
Olyan meggyőző volt, hogy elhittem, hogy a HC sebesség. :(
Palira vettek.
Most csináltam egy olyat, hogy a winchestert Arch Linuxszal együtt átdobtam egy T400 (type: 6474-B84) laposba és kipróbáltam, ott mi a helyzet pendrájvra másolás közben. Egy fokkal gördülékenyebb a rendszer, pl. tudok ablakot váltani másolás közben (de csak lassan, módjával), de böngészőben új tabot nyitni nem (sőt, ha egy lap éppen elkezdett betöltődni a másolás kezdetkor, akkor az úgy is marad, csak a másolás végeztével töltődik be).
Azt figyeltem meg, hogy a dd_rescue esetében a folyamatjelző gyorsan végigszalad, mintha kiírta volna az adatokat a stickre, aztán a promptot mégsem adja vissza, hanem kb. 2-3 percig még ír (villog a pendrájv is, meg látszik iostat -tal is az írás). Közben az %iowait értéke 98,9 körül van sar -ral figyelve.
Akkor most az van, hogy:
a) lehet, hogy van 3 különböző USB -s stick -kem és mind rossz
b) a T61 -et, mint hibás HW -t kizárom amiatt, hogy a T400 -on is jelentkezik a gond
c) a winchestert is kizárom, mint hibalehetőség, mert /dev/zero -t dd -zve is lassul a T400 -on is a rendszer
d) valami nem stimmel a 64 bites Arch Linuxommal (kernel konfig vagy ilyesmi)
Szerk: 512k -s blokkméretet használva a dd -hez és így írva a pend. -ra viszonylag használható marad a rendszer. Ha viszont pl. 4MB a blokkméret, akkor billentyűleütést sem tud érzékelni/lekezelni a rendszer az írás ideje alatt.
Szerintem próbáld meg 512 byte-os illetve 2 kiB-os blokkmérettel is.
Nem néztem meg, mi a T61, T400 - én csak a T54 és T72 modellekről hallottam, de ezekkel háborút szokás nyerni ;) -, mindenesetre szerintem az az igazán releváns dolog, milyen chip-ek vannak az alaplapon, azokhoz milyen driver mozdul meg a kernelben, mennyire jó dokumentáció alapján sikerült a driver-eket a fejlesztőknek implementálni.
tr [:lower:] [:upper:] <<<locsemegeLOCSEMEGE
32bites Archon ugyanazzal a géppel, ugyanazzal a pendrávval:
Bár az értékek hasonlóak, mégis teljesen használható marad a rendszerem másolás közben. Hm.. valami 64 bit bug? o.O
Egyébként nem találok hirtelen okot, ami miatt a laposon 64 bit kellene nekem, így maradok a 32 bit mellett.
linux, 2011
Vista x64 SP2 Core2 Q6600 CPU 8GB DDR2 1066 Ram, Raid0 SATA2 HDD
HTC touch HD telefon rádugva háttértár módban, a telóban class10-es 16GB-os SDHC kártya.
Másolás a kártyáról: - 7800kb/s
Írás kártyára: - 3450kb/s
keresgéltem mert szánalmasnak találtam a sebességet, találtam egy progit: http://www.oo-software.com/home/en/products/ooclevercache/
Másolás a kártyáról: - 34560kb/s
Írás kártyára:- 18900kb/s
érdekes.......
esetleg 64 biten ezen parancsok kiadása után változik valami?
vagy
Megnézem majd, köszi a tippet.
Kipróbáltam mindkettőt, semmivel sem jobb.
--
Discover It - Have a lot of fun!
Valami fejleményed van már?
Nem pendrive, nem chipset hiba, nálam is ugyanez a hibajelenség (és nem most jött, már jó ideje, szóval nem valamelyik új kernel hozta).
3.1.9, opensuse 12.1 x64
--
Discover It - Have a lot of fun!
Azóta megmaradtam a 32bites kernel mellett, azzal nem jött elő ez a gond. Majd valamikor ha unatkozom, megnézem az újabb (3.2+) kernelverziókat 64biten, hogy változott -e valami vagy megoldja -e a gondot más IO scheduler használata.
Hát én évek óta 64 biten tolom...
--
Discover It - Have a lot of fun!
subscribe
+1