You are not logged in.
Hello all, I'm an ex-gentoo user turned arch. Looking forward to it!
Anyway, I have a brand new OCZ Vertex SSD -- theoretical 230MB/s read times. In the livecd installer, hdparm gets 210MB/s reads, pretty awesome. However, in my current installation, I am only getting 75MB/s.
My kernel is 2.6.29, the livecd has 2.6.28. I checked, UDMA/133 is enabled on my drive. I (and some generous IRC users) have absolutely no idea what's happening here.
Any help would be appreciated!
[root@wakka jake]# hdparm -i /dev/sda
/dev/sda:
Model=OCZ-VERTEX, FwRev=1370, SerialNo=92M9W154QY80YY06496G
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=12288
BuffType=unknown, BuffSize=32767kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=62533296
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-5,6,7
Last edited by wakkadojo (2009-06-17 13:40:38)
Offline
2 questions.
What filesystem are you using?
What IO scheduler are you using?
I got an Intel SSD, and to get the best of it, I need to setup the elevator=noop on menu.lst. I'm using ext4 on it and it works pretty fast. I've also tryied xfs, which gives a very good performance too.
I hope it helps.
p.s. I'm not a ssd expert. I just played with a few settings until I got the best result. You can also play with the 'filesystem pressure' (or something like that). Have a look on google about the sysctl keys and learn how to tweak them. Just for reference, the key is vm.vfs_cache_pressure, and I set it to 70, but YMMV.
Last edited by kjon (2009-05-31 18:01:26)
They say that if you play a Win cd backward you hear satanic messages. That's nothing! 'cause if you play it forwards, it installs windows.
Offline
@kjon
I am using noop. The /boot partition is ext2, the other partition is ext4.
Offline
Second bet:
play with elevator=deadline and tweak the writing times. I don't know how to play with this scheduler, but some people have succeeded with ssd using it.
They say that if you play a Win cd backward you hear satanic messages. That's nothing! 'cause if you play it forwards, it installs windows.
Offline
I am thinking that the problem is with the installation, not the scheduler. I had the default scheduler, and had poor read times, so i switched to noop. This did not solve my problem.
Offline
Shouldn't hdparm results be independent of the filesystem used?
Try this as root
dd if=/dev/sda of=/dev/null bs=100M count=10
It should give you an estimate of how fast it can go.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Thanks to everyone who has helped. @ROOKIE, I get the same performance:
dd if=/dev/sda of=/dev/null bs=100M count=10
1048576000 bytes (1.0 GB) copied, 13.295 s, 78.9 MB/s
On a side note, when I use the --direct flag in hdparm, I get different results!
hdparm -t --direct /dev/sda
Timing O_DIRECT disk reads: 690 MB in 3.00 seconds = 229.63 MB/sec
So without --direct I get about 75MB/s, with --direct I get about 230MB/s (the manufacturer's published max read speed).
Not sure what this means exactly. Maybe I should go to the OCZ forums.
Offline
I think I've seen something about this before, but I don't know where exactly and I don't remember many details now
I think it had something to do with write cache being active, the drives that would allow it to be disabled performed much better, while one drive wouldn't disable write cache at all and perform less than optimally.
Try to disable the drive's write cache and try again, more than that I have no other ideas, forums and google will have to come to the rescue I guess.
hdparm -W 0 /dev/sda
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I have been all over google and many other forums, there's really nothing on this. I'm almost certain it's an Arch linux problem of some sort.
I just gave your suggestion a shot. Here's what we get:
# hdparm -t -W 0 /dev/sda
/dev/sda:
setting drive write-caching to 0 (off)
write-caching = 1 (on)
Timing buffered disk reads: 220 MB in 3.02 seconds = 72.96 MB/sec
So no improvement -- but then again it says it turns off write caching when it really does not.
However, I would like to point out that it is probably not write caching that is causing this slowdown, since on the livecd write caching is enabled, and others have not posted anything about disabling write caching to improve ssd performance.
Last edited by wakkadojo (2009-05-31 23:55:24)
Offline
I have found the article I was talking about http://www.phoronix.com/scan.php?page=a … mode&num=1
Which kernel versions did you use for the tests? Maybe some optimization for ssd drives is in effect in the latest kernels and your drive doesn't play well with that ....
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
The livecd uses some revision of kernel 2.6.28. I installed the latest (and only) available kernel: 2.6.29.4.
I tested the system in Ubuntu (reluctantly!) and benchmarked the hard drive at 200MB/s -- but Ubuntu has kernel 2.6.28. So what did I do -- I installed kernel 2.6.29 on Ubuntu, and viola, read speeds of 75MB/s!!!
Is there anything I can do, or I will just have to wait for the next kernel release and hope this problem has resolved itself by then? But keen insight ROOKIE, it was in fact a kernel problem.
Last edited by wakkadojo (2009-06-01 13:08:35)
Offline
I've read somewhere that the kernel devs where getting ready to identify when a system has an ssd and try to optimize the read/write requests for it maybe thats what is happening.
I don't know more than that, maybe there is some flag you can pass to the kernel to disable that (make it behave as it did before). Maybe someone that knows that will read this and give you some help, meanwhile I guess you can try our friend google, at least now you have an idea of what causes the problem.
Anyway, unless you really need the 200MB/s I guess the 75MB/s will be ok until the problem is fixed given that with an ssd you will have much lower access times .... unless that is being affected too
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I think I'll settle with my degraded performance... the system is pretty snappy though not as quick as I had hoped it would be. I'll cross my fingers that this will get resolved in the next kernel release. Does anyone have any idea when 2.6.30-ARCH will be stable?
Offline
I guess that soon after the kernel is deemed stable upstream, as far as I know they are still on the way there with release candidates.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I dont know anything about SSD's yet, but what seems some sort of obvious to me is: Why dont you downgrade your kernel to .28?
I dont know much about downgrading too, but if i was in your position this would be the right time to learn more about it i think.
Offline
@sveri80
Since I don't have the old kernel in my pacman cache, it is actually highly inconvenient for me to downgrade to 2.6.28: I will have to hunt down all packages and dependencies for the kernel because they are not in the repositories. This includes kernel-headers, firmware and such. Basically: not worth the trouble, and I'd probably break something in Arch.
Unless -- is there a simple way to downgrade the kernel (and drivers, like the nvidia driver I'm using)? If so, please fill me in!
Last edited by wakkadojo (2009-06-02 17:18:38)
Offline
Kernel bug report submitted: http://bugzilla.kernel.org/show_bug.cgi?id=13463
Offline
wakkadojo: While you wait you could try: http://bbs.archlinux.org/viewtopic.php?pid=557181
Offline
@Ashren
I already know that previous kernel revisions (specifically 2.6.28) work well with my SSD. Thanks for the link though, so now I can downgrade my packages to get the SSD performance without too much trouble. But for now I will wait and see if 2.6.30 resolves this issue.
Offline
TEMPORARY SOLUTION:
I just downloaded the linux 2.6.28.10 kernel source and did a custom installation. The new (well, old) kernel only broke the nvidia drivers, so I downloaded the latest x86_64 drivers from the nvidia website and installed them. Everything runs very nicely now: 220MB/s SSD reads.
Offline
I tried out the 2.6.30 kernel from [testing], and got 200-220 MB/s read speeds. This problem is isolated to the 2.6.29 kernel. Lets hope it doesn't pop up again in some future release!
Last edited by wakkadojo (2009-06-16 13:44:06)
Offline
if you want to go really wild, try the NILFS from 2.6.30
And for benchmarks, a tool such as fio can benchmark a lot of things. random/sequential read/writes with various options to play with. It also gives many interesting values such as latencies and stuff.
Last edited by Dieter@be (2009-06-16 14:07:42)
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline