# [Risolto] Sata, nVidia (ora MISTERO!!!)

## jbg70

Salve a tutti.

Ho una mb basata su chipset nVidia, esattamente la ASRock ALiveNF7G-HD720p R5.0 con un processore amd64 x2 4800+.

Partendo da un livecd con kernel 2.6.19-gentoo-r5 per x86 32bit, il comando hdparm -T /dev/sda restituisce:

/dev/sda:

 Timing cached reads:    4224 MB in  2.00 seconds = 2113.44 MB/sec

Dopo aver installato gentoo e compilato i kernel 2.6.19-r5 (quello della live), 2.6.24-r3, 2.6.23-r8 con genkernel, scaricando pero' lo stage3 per amd64, lo stesso comando restituisce:

/dev/sda:

 Timing cached reads:   2472 MB in  2.00 seconds = 1236.57 MB/sec

Il transfer rate sul canale SATA e' circa la meta'....

Il driver sata_nv funziona solo nel kernel 2.6.19 (che è 2.0), per gli altri kernel successivi, compreso l'ultimo che comprende sata_nv versione 3.5, il controller non viene nemmeno visto, costringendomi a caricare l'ahci.

Quello che vorrei sapere, da chi sicuramente ne sa piu' di me, e' da quale opzione del kernel puo' dipendere il calo di prestazioni durante il trasferimento sul canale SATA, visto che anche il 2.6.19 compilato con genkernel non mi da' lo stesso risultato del 2.6.19 della live?

Grazie e saluti.Last edited by jbg70 on Fri Mar 07, 2008 10:18 am; edited 2 times in total

----------

## Peach

beh  il solo fatto che non ti riconosca il bus nforce potrebbe essere sintomo di questo degrado prestazionale.

hai provato a cercare da qualche parte qualcosa del genere?

----------

## jbg70

In giro ho trovato che negli ultimi kernel, a causa di alcuni problemi, i pci id relativi chipset MCP67 sono stati spostati dal driver sata_nv in ahci, e questo spiega il perche' l'ultimo sata_nv, non vede nulla!

Sono certo, pero' che c'e' qualcosa che ho dimenticato nel kernel, perche' anche compilando il 2.6.19 in architettura amd64 che contiene il sata_nv che riconosce e funziona correttamente sulla live x86, le prestazioni sono dimezzate rispetto alla live!

Infatti se parto con il 2.6.19 compilato per amd64, il sata_nv riconosce correttamente perifieriche e controller, ma il transfer rate dalla memoria dell'HD rimane basso, mentre se parto con il cd della live che contiene lo stesso kernel, e sata_nv, ma compilati per x86, le prestazioni sono quasi il doppio.

Per compilare il 2.6.19, ho usato il /proc/config.gz della live. L'ho decompresso e messo nella /usr/src/linux come .config ed ho usato genkernel --menuconfig all.

Genkernel ha fatto dei cambiamenti modificando alcune parti per la nuova architettura, e quindi dopo aver verificato che fossero inclusi i moduli giusti, ho fatto proseguire.

Non vorrei che con architettura a 64bit, il transfer rate tra pc e memoria hd sia dimezzata!

Grazie e saluti...

----------

## jbg70

Ora e' davvero un mistero!!!

Scaricata la iso per la installazione minima per amd64, quindi kernel 2.6.19-r5 che usa il vecchio driver sata_nv e che funziona egregiamente al max delle prestazioni.

Ho decompresso e copiato il /proc/config.gz, sia in /usr/src/linux/.config, sia in /etc/kernels/kernel-config-x86_64-2.6.19-gentoo-r5, usato genkernel --menuconfig all.

Se infatti confronto i due /proc/config.gz cambiano solo nelle prime righe dove e' riportata la data!

I due .config quindi sono identici!

Ma le prestazioni sono quasi il doppio se parto dalla live!

Ora le differenze sono:

gcc e librerie

make.conf?

altro?

Ancora un indizio... questa e' proprio bella!

Ho copiato il kernel della live con il relativo initrd (gentoo e gentoo.igz) nella boot e ho aggiunto la relativa voce a lilo.

Se parto con quel kernel, ovviamente non trova il root device; quindi gli do /dev/sd3, e quindi parte felice e contento....

Ma hdparm mi da' ancora prestazioni dimezzate....

Ora il kernel e' quello della live... i moduli anche, perche' compresi nell'initrd....

Dove e' la differenza?

Altro indizio:

un diff ai due dmesg (live e da hd):

```

1,2c1,2

< Linux version 2.6.19-gentoo-r5 (root@poseidon) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #1 SMP Fri Mar 23 22:03:13 UTC 2007

< Command line: root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs loop=/image.squashfs cdroot initrd=gentoo.igz vga=791 BOOT_IMAGE=gentoo 

---

> Linux version 2.6.19-gentoo-r5 (root@peter) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)) #1 SMP Sun Mar 2 10:21:32 CET 2008

> Command line: BOOT_IMAGE=Linux-2.6.19-r5 ro root=100 console=ttyS0,115200 init=/linuxrc ramdisk=8192 real_root=/dev/sda3 udev

38,39c38,39

<   DMA zone: 1001 pages reserved

<   DMA zone: 2942 pages, LIFO batch:0

---

>   DMA zone: 1537 pages reserved

>   DMA zone: 2406 pages, LIFO batch:0

69,70c69,70

< Built 1 zonelists.  Total pages: 507864

< Kernel command line: root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs loop=/image.squashfs cdroot initrd=gentoo.igz vga=791 BOOT_IMAGE=gentoo 

---

> Built 1 zonelists.  Total pages: 507328

> Kernel command line: BOOT_IMAGE=Linux-2.6.19-r5 ro root=100 console=ttyS0,115200 init=/linuxrc ramdisk=8192 real_root=/dev/sda3 udev

74c74

< Console: colour dummy device 80x25

---

> Console: colour VGA+ 80x25

81,82c81,82

< Memory: 2023132k/2064064k available (2595k kernel code, 40188k reserved, 750k data, 228k init)

< Calibrating delay using timer specific routine.. 5244.35 BogoMIPS (lpj=26221763)

---

> Memory: 2025848k/2064064k available (2594k kernel code, 37612k reserved, 747k data, 228k init)

> Calibrating delay using timer specific routine.. 5244.45 BogoMIPS (lpj=26222252)

91c91

< result 13099636

---

> result 13099691

95c95

< Calibrating delay using timer specific routine.. 5238.98 BogoMIPS (lpj=26194928)

---

> Calibrating delay using timer specific routine.. 5239.12 BogoMIPS (lpj=26195639)

102c102

< CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 623 cycles)

---

> CPU 1: synchronized TSC with CPU 0 (last diff 3 cycles, maxerr 617 cycles)

106,107c106,107

< time.c: Detected 2619.928 MHz processor.

< migration_cost=274

---

> time.c: Detected 2619.939 MHz processor.

> migration_cost=232

109c109

< Freeing initrd memory: 4723k freed

---

> Freeing initrd memory: 2146k freed

276,281d275

< vesafb: framebuffer at 0xd0000000, mapped to 0xffffc20000080000, using 3072k, total 32768k

< vesafb: mode is 1024x768x16, linelength=2048, pages=1

< vesafb: scrolling: redraw

< vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0

< Console: switching to colour frame buffer device 128x48

< fb0: VESA VGA frame buffer device

397,399c391,393

< XFS: bad magic number

< XFS: SB validate failed

< UDF-fs: No VRS found

---

> XFS mounting filesystem sda3

> Ending clean XFS mount for filesystem: sda3

> sd 0:0:0:0: Attached scsi generic sg0 type 0

402,412c396

< UDF-fs: No VRS found

< XFS: bad magic number

< XFS: SB validate failed

< UDF-fs: No VRS found

< XFS mounting filesystem sda3

< Starting XFS recovery on filesystem: sda3 (logdev: internal)

< Ending XFS recovery on filesystem: sda3 (logdev: internal)

< ISO 9660 Extensions: Microsoft Joliet Level 3

< Unable to load NLS charset iso8859-1

< Unable to load NLS charset iso8859-1

< ISO 9660 Extensions: RRIP_1991A

---

> Adding 979956k swap on /dev/sda2.  Priority:-1 extents:1 across:979956k

414,417d397

< sd 0:0:0:0: Attached scsi generic sg0 type 0

< XFS mounting filesystem sda3

< Starting XFS recovery on filesystem: sda3 (logdev: internal)

< Ending XFS recovery on filesystem: sda3 (logdev: internal)

```

Puo' essere di aiuto?

Saluti e grazie.

----------

## Peach

ora direi che di differenze tra i due dmesg non è che ce ne siano... forse qualche valore leggermente diverso... ma non so se è sufficiente a spiegare il dimezzamento di prestazioni.

in ogni caso hai mica visto se hdparm -I differisce se lanciato da livecd che da disco?

----------

## xveilsidex

oggi ho provato a fare la stessa cosa con il live cd! ho anch'io una perdita del 50% nelle prestazioni di hdparm però non ho nvidia ho intel

----------

## MeMyselfAndI

Controllate la versione di hdparm.. da una certa versione in poi (che ora non ricordo) han corretto un bug che visualizzava erroneamente il doppio della velocita' di trasferimento dati.

controllate i changelog per maggiori info.

----------

## Kernel78

 *MeMyselfAndI wrote:*   

> Controllate la versione di hdparm.. da una certa versione in poi (che ora non ricordo) han corretto un bug che visualizzava erroneamente il doppio della velocita' di trasferimento dati.
> 
> controllate i changelog per maggiori info.

 

Adesso che l'hai scritto mi è venuto un flash ...

 *hdparm ChangeLog wrote:*   

> hdparm-6.9
> 
> - fix X2 over-reporting of -T results

 

----------

## MeMyselfAndI

Esattamente... a volte mi sorprendo pure io perche' mi tornano in mente certe cose  :Very Happy: 

----------

## jbg70

Subject aggiornato!

@MeMyselfAndI:

GRANDE! stavo diventando piu' matto di quello che gia' sono.... il che e' veramente difficile quando si e' molto vicini al valore massimo assoluto di pazzia!

Saluti.

----------

## xveilsidex

@jbg70  come hai risolto?  che versione di hdparm hai installato?

----------

## jbg70

Beh... la soluzione l'hanno data Kernel78 e MeMyselfAndI, quando hanno riportato che hdparm versione < 6.9 aveva un bug che calcolava male i valori del parametro -T su processori X2.

La live infatti ha hdparm 6.6, mentre ora su gentoo viene installata la 7.7.

I valori che ottengo con la 7.7 sono piu' bassi della 6.6, ma quelli ottenuti dalla 6.6 non erano reali!

La velocita' di lettura diretta dal disco (-t), e' sempre la stessa (circa 108MB/sec) con entrambe le versioni.

Saluti.

----------

## MeMyselfAndI

 *jbg70 wrote:*   

> 
> 
> La velocita' di lettura diretta dal disco (-t), e' sempre la stessa (circa 108MB/sec) con entrambe le versioni.
> 
> 

 

Urca miseria... e io che mi accontento dei 33 del mio laptop... ma usi un qualche tipo di raid ?

----------

## xveilsidex

okkey grazie   :Wink: 

----------

## jbg70

 *MeMyselfAndI wrote:*   

> 
> 
> Urca miseria... e io che mi accontento dei 33 del mio laptop... ma usi un qualche tipo di raid ?

 

Nessun Raid. E' semplicemente un Seagate ST3500320AS da 500GB.

Saluti.

----------

