Fidonet Portal






From: Dariusz Piatkowski (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net>

This post is a bit old, but since I picked up a new Samsung 840 Pro, 128GB
version I thought I'd give a brief update on how this behaves in the OS/2
environment.

Basically, just a follow-up to Trevor's response, this time giving some
detailed
benchmark results for my WD Raptor and the Samsung 840 Pro SDD.

Here they are:

1a) baseline WD Raptor results

Disk I/O disk 0-1: 286166 MB - WDC WD3000HLFS-01G6U0
Avg. data access time : 6.800 milliseconds
Cache/Bus xfer rate : 223.603 Megabytes/second
Track 0 xfer rate fwd : 121.104 Megabytes/second
Middle trk rate fwds. : 106.045 Megabytes/second
Last track rate bwds. : 75.157 Megabytes/second
Average Transfer rate : 100.769 Megabytes/second
Disk use CPU load : 1.910 percent
-----------------------------------------------------------------------
Total : 617.663 Disk I/O-marks


1b) 840 Pro SDD

Disk I/O disk 3-4: 122103 MB - Samsung SSD 840 PRO Series
Avg. data access time : --.--- milliseconds
Cache/Bus xfer rate : 188.459 Megabytes/second
Track 0 xfer rate fwd : 235.188 Megabytes/second
Middle trk rate fwds. : 235.352 Megabytes/second
Last track rate bwds. : 233.197 Megabytes/second
Average Transfer rate : 234.579 Megabytes/second
Disk use CPU load : 3.300 percent
-----------------------------------------------------------------------
Total : --.--- Disk I/O-marks


2a) now detailed File I/O results - WD Raptor

File I/O - Drive G:
4Kb seq. Uncached w : 2262.421 Kilobytes/second
4Kb seq. Uncached r : 62129.635 Kilobytes/second
4Kb random Uncached w : 450.564 Kilobytes/second
4Kb random Uncached r : 888.919 Kilobytes/second
4Kb seq. Cached w : 35177.709 Kilobytes/second
4Kb seq. Cached r : 65704.971 Kilobytes/second
4Kb random Cached w : 1684.466 Kilobytes/second
4Kb random Cached r : 1029.143 Kilobytes/second
8Kb seq. Uncached w : 3299.960 Kilobytes/second
8Kb seq. Uncached r : 128026.983 Kilobytes/second
8Kb random Uncached w : 1120.713 Kilobytes/second
8Kb random Uncached r : 2644.494 Kilobytes/second
8Kb seq. Cached w : 33186.686 Kilobytes/second
8Kb seq. Cached r : 108380.553 Kilobytes/second
8Kb random Cached w : 3356.424 Kilobytes/second
8Kb random Cached r : 2080.097 Kilobytes/second
16K seq. Uncached w : 6090.010 Kilobytes/second
16K seq. Uncached r : 154041.864 Kilobytes/second
16K random Uncached w : 1500.169 Kilobytes/second
16K random Uncached r : 5057.471 Kilobytes/second
16K seq. Cached w : 38905.286 Kilobytes/second
16K seq. Cached r : 137768.296 Kilobytes/second
16K random Cached w : 6513.552 Kilobytes/second
16K random Cached r : 4085.658 Kilobytes/second
32K seq. Uncached w : 4931.226 Kilobytes/second
32K seq. Uncached r : 138226.313 Kilobytes/second
32K random Uncached w : 2681.625 Kilobytes/second
32K random Uncached r : 9491.489 Kilobytes/second
32K seq. Cached w : 42859.992 Kilobytes/second
32K seq. Cached r : 139413.132 Kilobytes/second
32K random Cached w : 13464.812 Kilobytes/second
32K random Cached r : 5953.137 Kilobytes/second
64K seq. Uncached w : 5091.302 Kilobytes/second
64K seq. Uncached r : 117747.531 Kilobytes/second
64K random Uncached w : 3015.526 Kilobytes/second
64K random Uncached r : 16234.737 Kilobytes/second
64K seq. Cached w : 46932.757 Kilobytes/second
64K seq. Cached r : 127792.362 Kilobytes/second
64K random Cached w : 15775.802 Kilobytes/second
64K random Cached r : 16410.034 Kilobytes/second
-----------------------------------------------------------------------
Total : 37785.195 File I/O-marks


2b) 840Pro SDD

File I/O - Drive E:
4Kb seq. Uncached w : 24162.940 Kilobytes/second
4Kb seq. Uncached r : 156480.162 Kilobytes/second
4Kb random Uncached w : 31457.412 Kilobytes/second
4Kb random Uncached r : 56064.896 Kilobytes/second
4Kb seq. Cached w : 28993.574 Kilobytes/second
4Kb seq. Cached r : 86772.036 Kilobytes/second
4Kb random Cached w : 29090.492 Kilobytes/second
4Kb random Cached r : 55908.863 Kilobytes/second
8Kb seq. Uncached w : 37262.675 Kilobytes/second
8Kb seq. Uncached r : 238922.942 Kilobytes/second
8Kb random Uncached w : 39226.957 Kilobytes/second
8Kb random Uncached r : 101137.098 Kilobytes/second
8Kb seq. Cached w : 40209.659 Kilobytes/second
8Kb seq. Cached r : 134880.650 Kilobytes/second
8Kb random Cached w : 38925.228 Kilobytes/second
8Kb random Cached r : 102431.054 Kilobytes/second
16K seq. Uncached w : 42415.084 Kilobytes/second
16K seq. Uncached r : 330774.958 Kilobytes/second
16K random Uncached w : 45582.025 Kilobytes/second
16K random Uncached r : 173524.569 Kilobytes/second
16K seq. Cached w : 43380.061 Kilobytes/second
16K seq. Cached r : 181986.071 Kilobytes/second
16K random Cached w : 46185.924 Kilobytes/second
16K random Cached r : 170841.885 Kilobytes/second
32K seq. Uncached w : 48054.142 Kilobytes/second
32K seq. Uncached r : 403607.811 Kilobytes/second
32K random Uncached w : 49035.084 Kilobytes/second
32K random Uncached r : 257405.478 Kilobytes/second
32K seq. Cached w : 48122.187 Kilobytes/second
32K seq. Cached r : 179245.467 Kilobytes/second
32K random Cached w : 49737.439 Kilobytes/second
32K random Cached r : 177619.433 Kilobytes/second
64K seq. Uncached w : 48483.540 Kilobytes/second
64K seq. Uncached r : 403802.516 Kilobytes/second
64K random Uncached w : 49336.216 Kilobytes/second
64K random Uncached r : 258958.511 Kilobytes/second
64K seq. Cached w : 49054.125 Kilobytes/second
64K seq. Cached r : 179964.592 Kilobytes/second
64K random Cached w : 50336.106 Kilobytes/second
64K random Cached r : 179876.461 Kilobytes/second
-----------------------------------------------------------------------
Total : 116731.408 File I/O-marks


In short, the actual File I/O performance seems great...I'm thinking of
investing in one of these for my home PC now.

One thought remains...now that I have this particular drive mounted in my
machine (on a short basis, just a testbed really), what is the best way to test

it out and get a feel for real-world performance?

Thanks!

-Dariusz


On Tue, 9 Oct 2012 20:23:06 UTC, "Trevor Hemsley"
<Trevor.Hemsley@mytrousers.ntlworld.com> wrote:

> On Sat, 6 Oct 2012 16:37:07 UTC in comp.os.os2.setup.storage, "Dariusz
> Piatkowski" <dariusz@_NO-SPAM_mnsi.net> wrote:
>
> > Does anyone have a comparable test result for a SSD drive operating in our
OS/2
> > environment?
>
> I have my OS/2 system on a Crucial M4 128GB drive now. Sysbench read results
are
> as follows:
>
> Disk I/O disk 1-1: 122102 MB - M4-CT128M4SSD2
> Avg. data access time : --.--- milliseconds
> Cache/Bus xfer rate : 148.942 Megabytes/second
> Track 0 xfer rate fwd : 221.776 Megabytes/second
> Middle trk rate fwds. : 219.190 Megabytes/second
> Last track rate bwds. : 219.930 Megabytes/second
> Average Transfer rate : 220.299 Megabytes/second
> Disk use CPU load : 6.690 percent
> -----------------------------------------------------------------------
> Total : --.--- Disk I/O-marks
>
> The access time is too quick for sysbench to measure Smile And that pushes the
> total out too. This is quite an old system with only 3Gbps SATA controllers
so
> the Crucial could be faster if it were on a newer board with 6Gbps
controllers
> (assuming OS/2 supports such things!Wink.
>
> My system has been on this drive since the middle of June 2012 so perhaps too

> soon to see if it slows down. The problem will be that the drive does not
know
> when files are deleted so when the OS goes to rewrite a sector that is
already
> in use, it has to erase the old contents first and on an SSD this is the slow

> part.
>
>


--

--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Marcel Mller (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: =?ISO-8859-1?Q?Marcel_M=FCller?= <news.5.maazl@spamgourmet.org>

On 05.08.13 06.48, Dariusz Piatkowski wrote:
> In short, the actual File I/O performance seems great...I'm thinking of
> investing in one of these for my home PC now.

You can boost the performance of almost any old PC or laptop with an
SSD. This applies also to OS/2.

However, in case of OS/2 the operating system and drivers itself are the
limiting factor in SSD benchmarks. So it does not matter in any way,
whether your SSD is a bit faster or not. Maybe some benchmark shows
diferent results, but for sure you won't mention the difference in real
life. So do not waste your money for a 840 Pro. 840 (without Pro) will
do the job as well. (Almost the same applies for other operating systems
as well, but for different reasons.Wink

> One thought remains...now that I have this particular drive mounted in my
> machine (on a short basis, just a testbed really), what is the best way to
test
> it out and get a feel for real-world performance?

You need not test the real world performance of an SSD. It is well known
to be excellent. The access time is the key to it's performance.

Simply take an SSD that is sufficiently large for your needs, and place
the boot volume on it. (Anything else makes no sense.Wink I would recommend
Samsung 840 series because they have good performance and low power
consumption and moderate price. (Most SSDs waste a lot of power for
compression, but with low gain.Wink

Depending on your file system you might have a look at the partition
alignment. Using HPFS it will not give a large difference since the
allocation block size is only 512 bytes anyway. But using JFS you should
care about alignment. OS/2's tools will never create partitions with
correct alignment but if you use third party tools, OS/2 will run.
(Although LVM might claim about a corrupt partition table.Wink


Marcel
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: Dave Yeo <dave.r.yeo@gmail.com>


> Depending on your file system you might have a look at the partition
> alignment. Using HPFS it will not give a large difference since the
> allocation block size is only 512 bytes anyway. But using JFS you should
> care about alignment. OS/2's tools will never create partitions with
> correct alignment but if you use third party tools, OS/2 will run.
> (Although LVM might claim about a corrupt partition table.Wink

Can't you just use 512 kb blocks? eg

F:\test>chkdsk y:
The current hard disk drive is: Y:
The type of file system for the disk is JFS.
The JFS file system program has been started.
CHKDSK File system is currently mounted.
JFS0138: CHKDSK Checking a mounted file system does not produce dependable
results.

CHKDSK Block size in bytes: 512
ctrl-C

Extra bonus points as it can't be read by any other operating system
though it can be read at the sector level. Good for screwing up border
security where they use a Linux boot disk to scan your computer
Dave
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Marcel Mller (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: =?ISO-8859-1?Q?Marcel_M=FCller?= <news.5.maazl@spamgourmet.org>

On 10.08.13 07.09, Dave Yeo wrote:
>> But using JFS you should
>> care about alignment. OS/2's tools will never create partitions with
>> correct alignment but if you use third party tools, OS/2 will run.
>> (Although LVM might claim about a corrupt partition table.Wink
>
> Can't you just use 512 kb blocks? eg

This is a very bad idea. Why should you combine the (unavoidable)
disadvantage of HPFS in conjunction with SSDs with the disadvantages of
JFS at this small block size? (JFS becomes quite slow at 512 bytes per
block. I tested this with a freedb data store with several million small
files some years ago to conserve storage.Wink

SSDs usually have a write block size of 4kB (adjusted to the defaults of
most modern file systems like ext2/3/4, NTFS, JFS etc.Wink. Writing smaller
blocks causes read-modify-write cycles. In contrast to advanced format
hard disks (with also 4k write block size) the performance on SSDs does
not degrade that much, but the side effect of write amplification is
unwanted on an SSD. Writing 512 bytes causes the SSD to write 4kB which
is a write amplification of 8. Even writing a unaligned 4kB block of a
JFS volume causes the SSD to write 8kB (amplification 2). One should
avoid this to increase the SSDs lifetime.

So a JFS volume on an SSD should always start on an LBA address that is
dividable by 8. Creating the partition with Linux or whatever and
formatting with OS/2 should do the job. I don't know any OS/2 tool
(except for a sector editor) that can do the alignment.

On some systems there is another hack. If you set the BIOS explicitly to
an "even" disk geometry like 64 heads (0..63), 128 sectors (1..128) then
OS/2 will automatically align all partitions correctly. But the drawback
is, that partitions besides the first 2 GB of storage on the disk might
no longer boot, because the INT13 extensions of the BIOS and the drivers
might get confused by this setting.


Marcel
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: Dave Yeo <dave.r.yeo@gmail.com>


> On 10.08.13 07.09, Dave Yeo wrote:
>>> But using JFS you should
>>> care about alignment. OS/2's tools will never create partitions with
>>> correct alignment but if you use third party tools, OS/2 will run.
>>> (Although LVM might claim about a corrupt partition table.Wink
>>
>> Can't you just use 512 kb blocks? eg
>
> This is a very bad idea. Why should you combine the (unavoidable)
> disadvantage of HPFS in conjunction with SSDs with the disadvantages of
> JFS at this small block size? (JFS becomes quite slow at 512 bytes per
> block. I tested this with a freedb data store with several million small
> files some years ago to conserve storage.Wink

OK, I misunderstood you. The 512 kb blocks was just an experiment here.
Seems that DFSee could easily be extended (or perhaps already capable)
to create partitions that are correctly aligned.
Dave
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Marcel Mller (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: =?ISO-8859-1?Q?Marcel_M=FCller?= <news.5.maazl@spamgourmet.org>

On 12.08.13 05.06, Dave Yeo wrote:
> OK, I misunderstood you. The 512 kb blocks was just an experiment here.
> Seems that DFSee could easily be extended (or perhaps already capable)
> to create partitions that are correctly aligned.

Oh, you are right. I forgot about DFSee.

But AFAIK it is not really free and its handling is ... well, let's call
it advanced. But I am pretty sure that it can do the job.


Marcel
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Fred J. Tydeman (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: "Fred J. Tydeman" <tydeman.consulting@sbcglobal.net>


wrote:

> So a JFS volume on an SSD should always start on an LBA address that is
> dividable by 8. Creating the partition with Linux or whatever and
> formatting with OS/2 should do the job. I don't know any OS/2 tool
> (except for a sector editor) that can do the alignment.

Can a SSD have a mixture of partitions that are 0.5K and 4K blocks?
That is 0.5K for FAT-16, HPFS and 4K for NTFS, JFS, ext4.

> On some systems there is another hack. If you set the BIOS explicitly to
> an "even" disk geometry like 64 heads (0..63), 128 sectors (1..128) then
> OS/2 will automatically align all partitions correctly. But the drawback
> is, that partitions besides the first 2 GB of storage on the disk might
> no longer boot, because the INT13 extensions of the BIOS and the drivers
> might get confused by this setting.

Can DFSee do that?
---
Fred J. Tydeman Tydeman Consulting
tydeman@tybor.com Testing, numerics, programming
+1 (775) 287-5904 Vice-chair of PL22.11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Marcel Mller (1:396/4)
To: n/a
Date: Sun, 14.06.20 14:57
Re: SSD drives in OS/2?
From: =?windows-1252?Q?Marcel_M=FCller?= <news.5.maazl@spamgourmet.org>

On 13.08.13 16.28, Fred J. Tydeman wrote:

wrote:
>
>> So a JFS volume on an SSD should always start on an LBA address that is
>> dividable by 8. Creating the partition with Linux or whatever and
>> formatting with OS/2 should do the job. I don't know any OS/2 tool
>> (except for a sector editor) that can do the alignment.
>
> Can a SSD have a mixture of partitions that are 0.5K and 4K blocks?
> That is 0.5K for FAT-16, HPFS and 4K for NTFS, JFS, ext4.

The SSD won't directly care about that, but the more write commands with
less than 4k the more data is effectively written to the device.

BTW: FAT16 with 0,5k block size is not that common since it is
restricted to 32 MB. At 256 MB the cluster size is 4kB.
However, with FAT16 extra care needs to be taken to ensure the
alignment, because the first cluster of a FAT16 volume does usually
start at an odd sector number. It is possible to come around this by
using the special reserved sector field of the boot block.


Marcel
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

ABOUT

This forum contains echomail areas hosted on Nightmare BBS You can browse local echomail areas, italian fidonet areas and a selection of international fidonet areas, reading messages posted by users in Nightmare BBS or even other BBSs all over the world. You can find file areas too (functional to fidonet technology). You can browse echomail areas and download files with no registration, but if you want to write messages in echomail areas, or use fidonet netmail (private messages with fidomet technology), you have to register. Only a minimal set of data is required, functional to echomail and netmail usage (name, password, email); a registration and login with facebook is provided too, to allow easy registration. If you won't follow rules (each echomail areas has its own, regularly posted in the echomail), your account may be suspended;

CONTACT