Dotaz: Velmi pomalý disk

[JF]

Někdy, když zadám ls, tak se minutu nic neděje a pak se vysype výpis. To i disketa před 20 lety byla rychlejší.

V syslogu nenajdu žádný problém při práci s diskem, disk žádné chyby ve S.M.A.R.T. nehlásí. Běžná rychlost při práci s diskem je 100MB/s.

Možná je chyba i na straně řadiče: 00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 03)

Netuším, co je špatně.

root@xxx:/usr/sbin# hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:     2 MB in  2.63 seconds = 780.14 kB/sec
 Timing buffered disk reads:   34 MB in  4.43 seconds =   7.67 MB/sec

root@xxx:/usr/sbin# hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   1628 MB in  2.00 seconds = 813.81 MB/sec
 Timing buffered disk reads:   34 MB in  4.41 seconds =   7.70 MB/sec
root@xxx:/usr/sbin# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   1660 MB in  2.00 seconds = 829.97 MB/sec
 Timing buffered disk reads:  300 MB in  3.02 seconds =  99.42 MB/sec

root@dvouramenna:/usr/sbin# hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:     2 MB in  7.95 seconds = 257.46 kB/sec
 Timing buffered disk reads:    2 MB in  4.42 seconds = 463.67 kB/sec

root@xxx:/usr/sbin# hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   1568 MB in  2.00 seconds = 784.49 MB/sec
 Timing buffered disk reads:  298 MB in  3.01 seconds =  99.02 MB/sec

Výpis S.M.A.R.T.:

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD7500AADS-00M2B0
Serial Number:    WD-WCAV54941177
Firmware Version: 01.00A01
User Capacity:    750,156,374,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Sep 11 14:35:03 2011 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x85) Offline data collection activity
                                        was aborted by an interrupting command from host.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                 (15600) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 181) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   128   114   021    Pre-fail  Always       -       6583
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       112
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   081   081   000    Old_age   Always       -       13913
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       110
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       72
193 Load_Cycle_Count        0x0032   189   189   000    Old_age   Always       -       35701
194 Temperature_Celsius     0x0022   101   092   000    Old_age   Always       -       46
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       3
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     13911         -
# 2  Short offline       Completed without error       00%     13908         -
# 3  Extended offline    Completed without error       00%      7803         -
# 4  Short offline       Completed without error       00%        76         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Technologii intellipark jsem vypnul a tak se snad disk sám od sebe nezastavuje.

---

---

Odpovědi

[chrono]

Určite počas spustenia hdparm žiadny iný program nepracoval s diskom?

[JF]

Možná syslog pár zpráviček. Nic intenzivního jsem nespouštěl.

Ale takhle brutálně by to nic nezpomalilo.

Na svém PC když kompiluji v jedné konzoli kernel, ve druhé wine tak se mi ls na takhle dlouho nezasekává.

Mám podezření na nějakou "ekologickou" vlastnost disku či řadiče. Když jsem spustil intenzivní práci s diskem tak se naopak disk zrychlil.

[vencour]

Co jiný datový kabel, zkusil jsi?

[JF]

V případě chybného kabelu bych čekal chyby CRC ve S.M.A.R.T.u. Uznávám, že kabel je také horký kandidát na pochybné chování.

Po pár hodinách experimentů to vypadá na problém IDE/AHCI. V AHCI módu je řadič disku stabilnější. Že by už IDE režim nebyl příliš testován? Přitom dosažená rychlost v módu AHCI není vyšší než v módu IDE.

Teď to běží bez prodlev, ale nechci to zakřiknout.

[JF]

Bohužel je to jinak.

Síťová karta eth4 má zaregistrován IRQ_17, ale ve skutečnosti vyvolává IRQ_19. A na IRQ_19 je jako na potvoru HDD.

Nějak mi nepomohl ani parametr "irqpoll", právě proto, že je přerušení již zaregistrováno (jinde).

Zatím si vystačím s eth0 až eth3 ;).

Nedá se nějak kernelu vnutit, že pro PCI zařízení má použít jiný vektor přerušení?

[ewew]

Pokiaľ ja viem, tak IRQ má za úlohu strážiť BIOS pri inicializačných testoch.

Akú máš distribúciu, koľko jadier v CPU alebo počet CPU ? Tiež by nebolo od veci nastaviť aby určité IRQ odbavovalo prvé jadro ďalšie druhé. Daná funkcia sa volá smp_affinity. Cesta k funkcii /proc/irq/(dané irq)/smp_affinity. detaily sú v balíčku dokumentácie kernelu.

Ja osobne to nemám ako vyskúšať, pretože mám všetko len jedno jadrové PC.

[JF]

Podle mě to není afinitou. A to proto, že se vyvolá chybný vektor. Tohle je chyba routovací tabulky přerušení v BIOSu a možná ji umi kernel Linuxu nějak obejít:

root@xxx:~# ifconfig eth4 up
[240621.653007] irq 19: nobody cared (try booting with the "irqpoll" option)
[240621.653018] Pid: 0, comm: swapper Not tainted 2.6.39.4 #3
[240621.653023] Call Trace:
[240621.653037]  [c10702f3] ? __report_bad_irq+0x33/0xc0
[240621.653045]  [c1070528] ? note_interrupt+0x1a8/0x1e0
[240621.653054]  [c106e99e] ? handle_irq_event_percpu+0xde/0x1e0
[240621.653061]  [c1070c50] ? (rtl8169_interrupt+0x0/0x390 [r8169])
[240621.653185] Disabling IRQ #19
[240623.750696] 0000:03:0f.0: tulip_stop_rxtx() failed (CSR5 0xf0218104 CSR6 0xb2420200)
[240631.272619] eth4: no IPv6 routers present

[Nereknu]

Zrejme sa my podarilo nájsť spôsob ako vynútiť IRQ pre dané zariadenie.

Nainštaluj si balík linux-doc-x.x.xx a potom si pozri tento súbor /usr/share/doc/linux-doc-x.x.xx/Documentation/kernel-parameters.txt.gz. Rozbal ho a hladaj v ňom slovo IRQ. Je tam pár parametrov, ktoré by mohli zlepšiť situáciu.

[JF]

To jsem si četl, ještě zkusím něco pohledat.

Když kompletně vypnu APIC, tak skutečně IRQ běží jen na procesoru 0.

Ale dojde úplně ke stejnému konfliktu. Eth4 reportuje IRQ15, ale fyzicky vyvolá IRQ6

root@xxx:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         37          0          0          0    XT-PIC-XT-PIC    timer
  1:          8          0          0          0    XT-PIC-XT-PIC    i8042
  2:          0          0          0          0    XT-PIC-XT-PIC    cascade
  5:      36014          0          0          0    XT-PIC-XT-PIC    ahci, ath, eth1
  6:     100002          0          0          0    XT-PIC-XT-PIC    ath, eth0, eth2
  8:          1          0          0          0    XT-PIC-XT-PIC    rtc0
  9:          0          0          0          0    XT-PIC-XT-PIC    acpi
 12:      35246          0          0          0    XT-PIC-XT-PIC    ath, eth3
 14:          0          0          0          0    XT-PIC-XT-PIC    ide0
 15:          0          0          0          0    XT-PIC-XT-PIC    eth4
NMI:          0          0          0          0   Non-maskable interrupts
LOC:     162586     162148     162161     162133   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RES:        101         41         29         34   Rescheduling interrupts
CAL:         67       1230        111        108   Function call interrupts
TLB:         23         18        274        240   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:          2          2          2          2   Machine check polls
ERR:          0
MIS:          0

root@xxx:~# ifconfig eth4
eth4      Link encap:Ethernet  HWaddr 00:48:54:00:B3:03
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:15 Base address:0x2000

root@xxx:~# ifconfig eth4 up
root@xxx:~#
Message from syslogd@xxx at Sat Sep 24 17:40:12 2011 ...
xxx kernel: [  186.586025] Disabling IRQ #6

[trubicoid2]

a mas zapnuty MSI? a co rika /proc/interrupts?

[JF]

root@xxx:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:        233        212        194        191   IO-APIC-edge      timer
  1:          2          2          2          2   IO-APIC-edge      i8042
  8:          0          1          0          0   IO-APIC-edge      rtc0
  9:          1          0          0          0   IO-APIC-fasteoi   acpi
 14:          0          0          0          0   IO-APIC-edge      ide0
 16:    6445884    6448369    6445257    6447997   IO-APIC-fasteoi   ath, eth3
 18:    9437482    9436003    9439608    9436284   IO-APIC-fasteoi   ahci, ath, eth1
 19:     200306     199275     198801     199388   IO-APIC-fasteoi   ath, eth0, eth2
NMI:          0          0          0          0   Non-maskable interrupts
LOC:   70954857   70959479   70943350   70975490   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RES:      12417      10205       5651       5737   Rescheduling interrupts
CAL:     112440      95949        151        162   Function call interrupts
TLB:       8453       6865      85103      60211   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:        785        785        785        785   Machine check polls
ERR:          0
MIS:          0
root@xxx:~# ifconfig eth4
eth4      Link encap:Ethernet  HWaddr 00:48:54:00:B3:03
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:17 Base address:0x2000

[trubicoid2]

tak MSI nemas zapnuty, nerika o MSI neco dmesg? podporuje deska MSI? mas zkompilovany MSI v jadre?

jeste by mohla pomoct volba jadra http://cateee.net/lkddb/web-lkddb/X86_REROUTE_FOR_BROKEN_BOOT_IRQS.html

pripadne vypnout v biosu to co nepotrebujes a udelat tim vice mista, trebas ide0

[JF]

Bohužel deska MSI vůbec neumí. V celém manuálu k desce není o MSI ani zmínka.

Díval jsem se do jádra a MSI je standardní součástí ovladače PCI sběrnice. To se snad ani nedá vypnout.

CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y Nepomohlo.

[trubicoid2]

MSI a MSI-X je soucasti specifikace PCI, v manualu to nebude, jestli mas PCI 2.2 a PCI Express, tak by to ta deska mela umet

a u me teda MSI jadre jde vypnout, kdyz je zapnuty, tak navic muzu povolit Interrupt Remapping, to by mozna taky pomohlo

ty mas nejaky standartni distribucni jadro? a co dmesg | grep -i msi ?

a dmesg | grep -i apic ?

[ewew]

Nedávno som na svojom PC vypol sekundárny radič IDE a po spustení PC som zbadal, že dané IRQ si schmatla zvuková karta. Skús napríklad danú sieťovku výpnúť a zapnúť či si potom nezoberie iné IRQ.

To je len taká zaujímavosť čo sa mi prihodila.

[chochi]

Jestli pomuze prerazeni IRQ tak mas stesti.
Jednou jsem tenhle problem resil u kamarada (obcas jel disk pod 1MB/s) u WD Caviar Green. Stejne se choval ve dvou verzich Linuxu i ve Win 7. Problem byl, ze tohle je vlastnost nekterych WDC Green, takze se to vyresilo reklamaci a vymenou za novy.
Takze kdyby nepomohl prerazeni IRQ, tak bych to videl na reklamaci (na internetu se da najit par diskuzi o tomhle problemu tehle disku).

PS: Problem se neobjevil hned, ale po par mesicich.

[JF]

Možná je to skutečně tímhle. Disk je přesně WD green. A běhal velmi rychle po zakoupení.

Síťová karta je zakázaná, takže k žádnému konfliktu IRQ nedochází.

Psal jsem i na podporu u WD a tam mi nabízeli výměnu. Těm jsem samozřejmě nic o IRQ neřekl.

root@xxx:~# sync && nice -9 hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 1642 MB in 2.00 seconds = 821.38 MB/sec Timing buffered disk reads: 296 MB in 3.00 seconds = 98.66 MB/sec

Budu disk pozorovat, každopádně díky za info.

[ewew]

Zdravím

Máš tam nainštalovaný atop ?

Urob nasledujúci pokus.

1. Naištaluj si atop. Potom ho spusti cez terminal v grafickom prostredí alebo na inej konzole. Odpoj sieť.
2. Nastav si obnovovanie v atop na 1s. Stačí stlačiť klávesu i a potom číslo 1, enter
3. Na inom terminály (ttyx) spustí problemový príkaz.

Ak irq bude v jednotkách percent a rýchlosť disku bude lepšia. Tak problém vytvárala sieťová karta. Niekde som tu čítal, že to väčšinou robia karty s Realtek čipom. Ak nie je nutné preveriť disk pomocou testu S.M.A.R.T.

Poznámka : Takéto testy by mali byť vykonávané v móde Single (pri štarte zvoliť recovery) alebo init 1.

K výpisu SMART. Parameter 9 - ceľkový čas behu disku. Neviem koľko už ten disk máš ale ja by som ho radšej vymenil. Samozrejme ak len väčšinu času točil platňamy by to nemusel byť problém. Parameter 199 - ceľkový počet neopraviteľných CRC chýb. Pokiaľ ma pamäť neklame, tak na wiki bolo odporučanie na výmenu datového kábla.

Ďalšia možnosť je použiť badblocks.

VAROVANIE !!!! Pozor v žiadnom prípade nedávaj rw test, lebo si spoľahlivo zničíš data !!!! VAROVANIE

[JF]

Parametr 55 hdd nezná 5 Reallocated_Sector_Ct 0
9 Power_On_Hours 14224
196 Reallocated_Event_Count 0
Jenže většinu času se disk fláká.

VAROVANIE !!!! Pozor v žiadnom prípade nedávaj rw test, lebo si spoľahlivo zničíš data !!!! VAROVANIE

BTW je možno spustit nedestruktivní RW test, který si zapamatuje sektor, udělá test a zase vrátí původní hodnotu. To jsem také zkoužel a nic. Bohužel tenhle typ testu běží 3 dny v kuse.

Jenže mám takovou obavu, že disk může sice mít problémy s čtením sektorů, ale umí je opravit. Takže vlastně k žádné viditelné chybě ani nedošlo.

Neviem koľko už ten disk máš ale ja by som ho radšej vymenil.
Ještě je 1/2 roku v záruce. Nikdy už nekoupím green disk. Za tu pakárnu to nestojí.

Ak irq bude v jednotkách percent a rýchlosť disku bude lepšia. Tak problém vytvárala sieťová karta. Niekde som tu čítal, že to väčšinou robia karty s Realtek čipom. Ak nie je nutné preveriť disk pomocou testu S.M.A.R.T.

Problém je trochu jiný. Nikoho asi nenapadlo, že někdo k miniITX desce s jedním PCI slotem připojí 4 síťové karty ;). Teď k žádnému IRQ konfliktu nedochází, protože je eth4 SW vypnutá.

[pc2005]

Ono mnoho miniITX desek nemá ani vyvedený všechny INTx linky do PCI slotu, resp. nepodporuje PCI stromečky.

[frr]

On totiž jakýkoli "stromeček" je dost proprietární záležitost. Prakticky vyžaduje speciálně (atypicky) zapojený slot na motherboardu - aby se ošetřily signály, které jsou pro každý slot unikátní/oddělené. Transparentně rozvedete ADxy, stromeček si může uzmout nějaké ADxy linky v roli IDSEL (a s trochou štěstí mu to i projde), ale už nerozpletete REQ/GNT (i když - možná že i jo, nějakým lehce netriviálním dekodérem) a především od motherboardu s jediným PCI slotem nelze očekávat, že bude počítat v "tabulce přiřazení IRQček slotům" s neexistujícími sloty (které si stromeček nějak po svém vycucá z prstu únosem náhodně zvolených ADxy linek v roli IDSEL) a že to celé nakonec bude fungovat. Konkrétně mapování IRQček na PCI sloty je vždycky natvrdo zakódováno v nějaké tabulce v BIOSu, která je board-specific. Nelze to a není to autodetekováno z holého hardwaru při inicializaci PCI sběrnice, a neexistuje pro toto přiřazení jednoznačný standard (existuje jakási konvence, jak se čtyři INT linky mezi PCI sloty "protáčejí", ale není vytesána do kamene a výrobci motherboardů se s oblibou dopouštějí výjimek při číslování onboard zařízení apod).

Zmíněný problém s doručováním IRQ nesprávnému vektoru znamená v principu vždycky "bordel v BIOSové tabulce mapování IRQ na PCI sloty". A tento případ je nezvyklý v tom, že to není nepořádek na straně výrobce boardu (BIOSu), ale na straně člověka, který skládal sestavu a bezelstně použil stromeček Modularita hardwaru tohoto zrna se totiž na PCI sběrnici až tak často nevidí. => pokud PCI stromeček, tak vždycky do boardu, který ho explicitně podporuje.

Jo kdyby se to do boardu píchalo do PCI-e, tak je situace maličko jiná v tom, že by stromeček musel být aktivní, a tedy obsahovat PCI-e bridge, a tedy pravděpodobně také IO(X)APIC... a zas by to nefungovalo u Intelu v "grafickém" slotu apod. A není nakonec vůbec jisté, že by BIOS ty IRQ linky naroutoval správně.

Jedna "případová studie" volně k tématu (přihřeju si polívčičku):

http://www.fccps.cz/download/adv/frr/PCI104/PCI104_case_logical.gif

http://www.fccps.cz/download/adv/frr/PCI104/PCI104_case.html

Na Linuxu je kouzelné, že tyhle problémy umí do značné míry zviditelnit a zahlásit. Proto ho s oblibou používám na debugování hardwaru.

[pc2005]

Jo ten systém přerušení na PCI je fakt hodně šílenej. Škoda, že od začátku nedělali MSI.

ad Intel "grafický" slot. To je zase kvůli BIOSu nebo má Intel ten slot nějak hezky upravený?

BTW Opět jeden z důvodů proč vyžadovat dokumentaci hw desky (v corebootu si to snad člověk už dokáže nastavit lépe).

[frr]

Zákaz čehokoli kromě grafiky ve slotu PCI-e x16 na desktopových čipsetech Intel je obchodní rozhodnutí intelu, implementované v BIOSu. Aby se líp prodávaly dražší "serverové" čipsety, koncepčně takřka identické s desktopovými. Technicky v hardwaru tam žádné omezení není, jak dokazuje průmyslový hardware od Advantechu a dalších (tentýž desktopový nebo dokonce "mobilní" čipset, RAIDy a síťovky ve slotu x16 fungují, ovšem cena je taky někde úplně jinde). Pro úplnost: grafické sloty PCI-e u čipsetů Intel až po 4x series mají jedno hardwarové specifikum: část PCI-e pinů má alternativní funkci jako SDVO, která se aktivuje zasunutím ADD2 karty. S příchodem čipsetů 5x/6x series je to už historie.

Je fakt, že systém drátování přerušení na PCI je jakoby "přílepkem" standardu PCI, který s podstatou PCI sběrnice moc nesouvisí a vypadá spíš jako dědictví architektury x86 PC. MSI je součástí standardu PCI tuším od verze 2.3, uměly to používat třeba SCSI RAIDy od Adaptecu (na bázi procesorů Intel IOP/Xscale).

Zas na druhou stranu PCI-e vč. MSI je asi docela složitá záležitost - na malých embedded procesorech se to zatím moc nevyskytuje. Uvědomil jsem si to nedávno při zkoumání WiFi hardwaru - u firem jako Mikrotik nebo Ubiquiti byste Mini-PCIe hledal marně, všechen tenhle malý hardware na bázi ARM/Mips má zatím MiniPCI. MiniPCI-e je k vidění jenom v průmyslových x86 PCčkách (a v noťasech), což je trochu jiná kategorie cenově i topným výkonem :-/

[pc2005]

Aha, takže jen problém s Intelem. Jsem se bál, že to nějak hardwarově sabotoval. O tom, že jde strčit ADD2 karta jsem už slyšel. Bylo by to docela dobrá featura, kdyby Intel neseděl na patentech.

Jj taky je škoda, že ty malý krabičky nemaj PCIe. Ono to bude asi hlavně proto, že linková rychlost PCIe je někdy i řádově vyšší než hodiny procesoru. Nicméně embedded CPU s PCIe se najít daj. Jeden s ARMem mám v patičce.

[frr]

No jasně, tuhle Vaši patičku jsem zaznamenal už před časem zmíněný procík od TI je hezký kousek, a mj. živoucí důkaz, že PCI-e x2 není nesmysl, ačkoli ji u Intelu nikde nepotkáte

[pc2005]

Jo mi jsme si psali maila že?

[pc2005]

*omg my

[JF]

Podle poslední analýzy je disk OK.

K totálnímu zpomalení došlo z mnoha důvodů.

Disk sice umí zapisovat stabilní rychlostí 90Mbit/s - to jsem ověřil i po roce provozu, ale má velice pomalý seek. Nejspíše někdo nezvládl NCQ. Vypnout se NCQ asi nedá. Při zápisu adresáře se těch seeků nadělalo až běda.

Další vlastnost filesystému (write barrier) sice vynutí okamžitý zápis žurnálu z cache disku na povrch, ale tím se vše ještě mnohonásobně zpomalí.

-- další nedostatky samozřejmě rychlosti zápisu do disku nepřidaly. Po upgrade BIOSu na verzi A08 problém s přerušením zmizel. Zařízení, které dělalo konflikt mám stále vypnuté, takže tahle chyba mi prozatím nevadí.

[trubicoid2]

NCQ vypnes takto:

(mozna bude potreba prepnout sata radic do AHCI modu v biosu, ale zase kdyz by nebyl v AHCI, tak by spravne nemelo ncq fungovat)

 

#echo "Disabling NCQ"

for i in /sys/block/sd?

do

echo 1 > ${i}/device/queue_depth

done

 

write barrier jde vypnout jako voba pri mountu nebo ve fstabu

[frr]

Jste si jist, že to vypne NCQ?
Tohle jenom řekne Linuxu, aby zkrátil frontu "současně běžících transakcí" blokového zařízení na 1.
Podle mého to ale nutně neznamená, že HW-specific driver (libata) přestane používat NCQ-specific příkazy, tzn. Read FPDMA Queued / Write FPDMA Queued. Příkazy popisuje tenhle whitepaper, str.5-6.
Čili je možné, že Linux se bude s diskem dál bavit přes NCQ command set, ale bude mu lžičkovat transakce po 1 ks (a čekat u každé na vyřízení).

Druhá otázka je, jestli náhodou přesně tohle taky neobejde konkrétní bug "v oblasti NCQ" ve firmwaru disku

Pokud jde o to skutečně zakázat NCQ, tak doporučuji ve zdrojácích kernelu soubor Documentation/kernel-parameters.txt, hledejte zmínku o libata.force= a [no]ncq. Zřejmě by mělo zafungovat něco jako libata.force=0.0:noncq . Já jsem tenhle argument pozoroval v kernelu 2.6.35.7 a netuším, jak je přesně starý.

[trubicoid2]

nevim jak a jestli to ncq vypne, ale disky mi potom jedou rychleji, treba RAID rebuild se tim vypnutim ncq zrychli o 42%, noncq zkusim

[frr]

tak to je opravdu velmi vypečená implementace NCQ Rebuild RAIDu je taková příjemně sekvenční zátěž...

[Trubicoid2]

Sekvencni nebo nesekvencni to je jedno, ncq by to nemelo brzdit, ne? Je vubec nejakej test, kterej ncq zrychli? Ja zadnej nenasel :(

[frr]

No právě - brzdit by to nemělo, a to ani při krásné sekvenční zátěži, na které prakticky není co optimalizovat Tam by měl být vliv NCQ cca nulový.
Na čem by měl být vidět přínos NCQ? Na směsi náhodných zápisů a snad náhodného čtení (nejlépe ve více vláknech). A spíš než podle subjektivního dojmu v jednom konkrétním vlákně by se to mělo hodnotit podle agregátní průchodnosti měřené v IOps (třeba utilitou iostat z balíku sysstat). Nebo časem na dokončení nějaké dávkové úlohy / benchmarku. Když se podpora NCQ v Linuxu objevila, doprovodné komentáře v LKML tuším zmiňovaly urychlení kompilace jádra o nějaké desítky procent. Dovedu si představit, že by rychleji mohla běhat databázová zátěž ve stylu write-mostly, nebo i s vysokým podílem čtení, ale v mnoha vláknech.

Čtení s asynchronním dokončením =neblokující už Linux umí, ale zatím není mnoho aplikací, které by ho používaly - vlákno obvykle čeká na návrat funkce read() apod., než podá další požadavek. Kdežto při zápisu se uplatňuje systémový write-back buffering, takže tam není problém mít naráz ve frontě mnoho požadavků.

Mám takový svůj testovací prográmek, který umí generovat náhodnou zátěž na úrovni blokového zařízení. By default jenom čte, ale dá se mu říct, aby i zapisoval - pak je ovšem destruktivní k datům (zničí na disku filesystém). Když čte, tak blokujícím způsobem => jedním vláknem nic neotestujete. Náhodný zápis, to je jiné kafe - pokud na disku nemáte zatím data.

Pak si vzpomínám na benchmark Bonnie++2, který benchmarkuje především filesystém. Protože jede nad filesystémem, není destruktivní ke stávajícím datům, přestože i zapisuje (vytváří si k tomu své vlastní soubory). Konkrétně specialitou tohoto prográmku je sadistický benchmark na vytváření a rušení velikého množství souborů a adresářů, který způsobuje velmi zajímavý mix náhodných transakcí na blokové vrstvě. Nejlíp když ho pustíte párkrát paralelně ve dvou či více adresářích. Bohužel v dobách, kdy jsem si s ním hrál (2.6.18 - 2.6.24) měl pod Linuxem drobnou nectnost: dokázal dostat do kolen většinu filesystémů, se kterými jsem si v té době hrál. Vybavuji si Ext3 a XFS. Při spuštění nad Ext3 se stávalo, že operační systém zahnil zajímavým způsobem - běžící programy v zásadě reagovaly, ale jenom do chvíle, kdy jste program ukončil a měl se vrátit shell (bash). V tu chvíli konzole umřela a už to nešlo vyprostit. Totéž při pokusu spustit další program z shellu. Přitom iostat ukazoval 0 Tps. Jediný FS, který to vždycky přežil, byl Reiser 3. Dneska už je doba někde jinde, aspoň doufám...

Nějaký základní bencmark disku umí provést tuším taky HDPARM.

Je zajímavé sledovat, jak různé disky "škálují" IOps podle toho, jak moc dobře jim řadíte náhodné transakce výtahovým algoritmem - tzn. nakolik blízko sebe transakce jsou. Některým diskům to jde výborně (Velociraptor, Cheetah), jiným to moc nejde (desktopové disky). Vlastně jsem o tom už něco napsal... Dá se třeba ladit hloubka fronty v OS, dá se taky použít "short stroking" na disku - tzn. omezit zátěž na nějaký oddíl (podmnožinu) celého povrchu disku.

Pokud jsem schopen posoudit, tak při dokonale náhodném seekování nemá fronta o hloubce 32 transakcí příliš velký vliv. U externích RAIDů na SCSI mívalo smysl zvětšit hloubku fronty na hostitelském HBA v serveru až na 128-256 transakcí. Každopádně hostitelský operační systém má mnohem víc RAMky a lze ho vyladit na ještě mnohem větší hloubku fronty (i když je to vždycky "něco za něco" a Linux není v této oblasti úplně tou největší hvězdou).
Kouzlo NCQ uvnitř disku by mohlo spočívat třeba v tom, že disk zná přesnou fyzickou geometrii a umí inteligentně řadit "lokálně rozházené" transakce tak, aby minimalizoval rotační latenci - tzn. skákat mezi blízkými stopami v rámci jedné otáčky - tzn. optimální pořadí nemusí odpovídat prostému seřazení seeků podle vnějších LBA adres. Jinak si myslím, že NCQ může mít nějaký vliv spíš u operačních systémů, které samy nedokážou seeky dost dobře optimalizovat. Teoreticky by mohlo být přínosem také obejdení latence "dotaz-odpověď", která vynikne bez použití TCQ/NCQ - vedle přenosových zpoždění může jít také o manipulaci s transakcemi na straně disku i hostitele, to všechno se bez TCQ/NCQ serializuje. Netuším, kolik tato "manipulační latence" činí, a dost možná se bude lišit u různých kategorií disků.

[trubicoid2]

tak na kompilaci kernelu NCQ vliv nema, neni pomalejsi ani rychlejsi pri make -j5 (mam 4 cpu)

a tvuj program havaruje v ncurses, jestli by to slo opravit, tak bych zkusil i ten zapis:

,------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------. |/dev/sda, CHS: 46593/255/63, LBA sectors: 3907029168 | |Sector size: 512, LBA bytes: 2000398934016, Trans.sz: 65536 | |___________________________________________________________________________________________________________________________________________________________________________________________________________________________~._______._____| |Pass 0, Transfer rate: 3304.9 kB/s, 51.6 Tps | Program received signal SIGSEGV, Segmentation fault.---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------' [Switching to Thread 0x7ffff7fd8700 (LWP 6070)] 0x000000392202f860 in tputs () from /lib64/libncurses.so.5 (gdb)

[frr]

no hezky :-O Pro zajímavost, co je to za distro? Z té hlášky vidím něco 64b...

[frr]

Mimochodem, rozumím správně, že jste to zkusil spustit pod gdb? Pokud ano, nebyl by backtrace (bt) odkud to přesně přiletělo? A hele, ten terminál byl nějakej hrozně širokej

[trubicoid2]

aha, tak to fakt bude jenom sirkou terminalu? :) ja mam sirokouhlej display :)
v nesirokym terminalu to jede dobe, jen cisla hodne skacou i pri pouziti -e, tak zadny rozdil mezi NCQ vypnutym a zapnutym nevidim, nejde udelat nejakej prumer?

mam gentoo 64b, ncurses 5.7-r7

baktrace ze sirokyho zde:
#0  0x000000392202f860 in tputs () from /lib64/libncurses.so.5
#1  0x00000039220249d7 in ?? () from /lib64/libncurses.so.5
#2  0x0000003922025753 in ?? () from /lib64/libncurses.so.5
#3  0x0000003922025e36 in ?? () from /lib64/libncurses.so.5
#4  0x0000003922027639 in doupdate () from /lib64/libncurses.so.5
#5  0x000000392201e317 in wrefresh () from /lib64/libncurses.so.5
#6  0x0000000000403220 in test_thread::print_progress (this=0x60b090) at hddtest.cc:361
#7  0x0000000000403e67 in test_thread::rnd_test (this=0x60b090, rw=114 'r') at hddtest.cc:608
#8  0x000000000040434e in test_thread::work (this=0x60b090) at hddtest.cc:784
#9  0x0000000000402ad7 in test_thread::memberize (this=0x60b090) at hddtest.cc:243
#10 0x0000000000402904 in test_thread::thr_func (this_thr=0x60b090) at hddtest.cc:208
#11 0x000000391ec06f7c in start_thread () from /lib64/libpthread.so.0
#12 0x000000391e4e15ed in clone () from /lib64/libc.so.6

[frr]

Zrovna na to koukám Ten řádek je dlouhej 235 znaků. A už asi vím, kde je problém: mrkněte do zdrojáku na řádek 130 (cituji:)
unsigned long int disco_buf[200]; // noone's ever gonna have a curses window this wide

Všecko ostatní alokuju dynamicky (nebo spíš není co alokovat, třeba rámečky zařídí ncurses), jenom na tohle jedno pole jsem se vy$#@l...

Čísla skáčou? Jako že údaj o Tps skáče? Jak moc skáče? Měl jsem pocit, že při "random seek" testu by se měl údaj vypisovat jednou za vteřinu. Viz užití funkce print_progress() v metodě test_thread::rnd_test(). Že bych měl ještě bug v počítání času? To snad ne...
Pokud ta čísla skáčou od sekundy k sekundě o víc jak pár procent, tak je to možná příznak nějaké závady v hardwaru. U desktopových točivých disků jsem býval zvyklý na poměrně stabilní údaj v rozmezí 60 - 75 Tps.
Pokud chcete delší průměrovací interval, možná byste to dokázal ve zdrojáku opravit (odhadem na řádcích 344-348 se třikrát vyskytuje konstanta 1000). Jako cmdline argument to zatím nemám. Nebo si na další konzoli spusťte iostat, ten bere periodu výpisu ve vteřinách jako první argument.

[trubicoid2]

Tak s -e a s 300s prumerovanim v iostat to tolik neskace, ale zadny pozitivni vliv NCQ pri nahodnem zapise se nekona:

Na jednom pocitaci bez NCQ mam 154-164 Tps a 155-157 Tps s NCQ.

Na druhym pocitaci bez NCQ mam 176-185 Tps a 178-183 Tps s NCQ.

[JF]

Děkuji za rady. Už jsem na to rezignoval a koupím si HDD black edition. Podle kamaráda mají nove Black edition skoro stejnou spotřebu jako green edition před 2 lety.

Podezírám pěkně vypečený bug ve firmware disku.

root@xxx:/var/log# time ls
acpid debug.2 maillog.3 removed_packages
...............................
real 6m52.245s
user 0m0.000s
sys 0m0.027s


akorát mi vrtá hlavou, co těch 6 minut disk vlastně dělá.

real 0m0.004s
user 0m0.000s
sys 0m0.003s


Jindy to trvá 4ms.

root@xxx:~# hdparm -tT /dev/sda2
/dev/sda2:
Timing cached reads: 1622 MB in 2.00 seconds = 811.25 MB/sec
Timing buffered disk reads: 300 MB in 3.00 seconds = 99.98 MB/sec


Těch skoro 99Mbit/s disk umí trvale udržet při kopírování z disku na disk po sektorech bez seeku.

[JF]

Nový disk nevykazuje vůbec žádné zpomalení ani záseky Linuxu. Takže to bylo kompletně diskem. (Kdyby vykazoval, tak by to byla chyba ovladace v kernelu.)

root@xxx:/DATA# hdparm -tT /dev/sda2
/dev/sda2: Timing cached reads: 1216 MB in 2.00 seconds = 608.09 MB/sec
Timing buffered disk reads: 364 MB in 3.01 seconds = 120.98 MB/sec

Když vidím reklamu na "ekologické" komponenty do PC, tak se mi z nich dělá nějak nevolno.