Hard Drive RWTEST.COM Performance (new/update)

[+Larry]

Here are some updated results from drac030's RWTEST.COM. Instead of being unordered, these have been listed in terms of fastest to slowest. By ordering these, some patterns are more evident. There are still some minor factors that prevent this from being a true "apples to apples" comparison, but I think it is pretty close.

 

Note there is a new "entry" in this from Bob1200XL. It is his internal flash card drive, but it is a true PBI device.

 

There is more data to come, but this is all I have accumulated thus far. These readings have come from several different persons, and the original sources can be found in several different threads here at AA. Please report any data errors that you might find.

 

READING (256-bytes/sector)

 

MIO Ram........45197....(MyDos?, Ramdisk)

130XE Ram....44683....(MyDos, Ramdisk)

 

KMK-JZ..........36714....(SDX, drive)

BW PBI..........29305....(Dos 2.0, CF)

BB.................26568....(SDX, drive)

KMK-JZ..........26040....(MyDos, drive)

KMK-JZ..........26040....(MyDos, CF)

BW PBI..........21695....(MyDos, CF)

BB.................20687....(MyDos, CF)

BB.................20373.....(MyDos, drive)

MIO 1.1.........14403....(MyDos?, drive)

MIO 1.4.........13195....(SDX, drive)

MyIDE 3.5F..... 9781....(MyDos, CF)

 

 

WRITING (256-bytes/sector)

 

130XE...........47953....(MyDos, Ramdisk)

MIO Ram.......37809....(MyDos?, Ramdisk)

 

BW PBI.........29305....(Dos 2.0, CF)

BW PBI.........21341....(MyDos,CF)

MIO 1.1........14144....(MyDos?, drive)

MyIDE 3.5F...11988....(MyDos, CF)

BB................11045....(MyDos, CF)

MIO 1.4........10082....(SDX, drive)

KMK-JZ..........9273....(MyDos, CF)

KMK-JZ..........8713....(SDX, drive)

KMK-JZ..........8585....(MyDos, drive)

BB.................8436....(SDX, drive)

BB.................7110....(MyDos, drive)

 

-Larry

Edited January 25, 2009 by Larry

[+warerat]

So I've been doing two things today-- hashing away at the MIO firmware and trying to nail down what the reliability problem is for those of you that have drives that kind of work. I think I found it.

 

All of the sudden, the MIO isn't a slouch anymore. This is with the unreleased 1.4b3 firmware, using RWTEST.COM with SDX 4.42. Ramdisk results done with SpartaDOS 3.2d. Drive is Seagate ST118273LC.

 

256-byte reads/writes:

Read-write test v.3.0

Copyright © 1994-2005 by KMK

 

DOS writing: 15123.6922 B/sek

DOS reading: 22995.0876 B/sek

DOS average: 19059.3899 B/sek

 

Native 512-byte read/writes:

Read-write test v.3.0

Copyright © 1994-2005 by KMK

 

DOS writing: 30481.8604 B/sek

DOS reading: 40959.9999 B/sek

DOS average: 35720.9301 B/sek

 

SpartaDOS ramdisk:

Read-write test v.3.0

Copyright © 1994-2005 by KMK

 

DOS writing: 40537.7319 B/sek

DOS reading: 46260.7058 B/sek

DOS average: 43399.2188 B/sek

Edited April 7, 2009 by warerat

[+Larry]

Most impressive! That's great news!

 

So I've been doing two things today-- hashing away at the MIO firmware and trying to nail down what the reliability problem is for those of you that have drives that kind of work. I think I found it.

 

All of the sudden, the MIO isn't a slouch anymore. This is with the unreleased 1.4b3 firmware, using RWTEST.COM with SDX 4.42. Ramdisk results done with SpartaDOS 3.2d. Drive is Seagate ST118273LC.

 

(snip...)

[flashjazzcat]

Sorry to dredge up an old topic, but I have new entries. I've been tinkering with a MyIDE driver for SpartaDOS X 4.42 and have managed to get a CF card working in CFA mode with 512 bytes per sector.

 

First using 256B/s:

 

DOS writing: 34761.9676 B/sek

DOS reading: 33686.8552 B/sek

DOS average: 34224.4114 B/sek

 

And with a 32MB, 512B/s volume:

 

DOS writing: 39849.0848 B/sek

DOS reading: 44157.094 B/sek

DOS average: 42003.0894 B/sek

 

Not sure if these are record-breaking figures (for MyIDE), but they're plenty fast with the FMS overhead.

Edited September 9, 2010 by flashjazzcat

[a8isa1]

Sorry to dredge up an old topic, but I have new entries. I've been tinkering with a MyIDE driver for SpartaDOS X 4.42 and have managed to get a CF card working in CFA mode with 512 bytes per sector.

 

First using 256B/s:

 

DOS writing: 34761.9676 B/sek

DOS reading: 33686.8552 B/sek

DOS average: 34224.4114 B/sek

 

And with a 32MB, 512B/s volume:

 

DOS writing: 39849.0848 B/sek

DOS reading: 44157.094 B/sek

DOS average: 42003.0894 B/sek

 

Not sure if these are record-breaking figures (for MyIDE), but they're plenty fast with the FMS overhead.

Great work!.

 

For 256-byte sectors your benchmarks are better than 3X quicker than MyIDE doing direct SIO transfers and you are doing it in DOS modes. Outstanding!

 

Keep this up and you are going make me finally switch to SDX (but I'll need a way to be able to use Action! and SDX together).

 

BTW, what's "CFA mode"?

 

- Steve

Edited September 9, 2010 by a8isa1

[flashjazzcat]

Great work!.

 

For 256-byte sectors your benchmarks are better than 3X quicker than MyIDE doing direct SIO transfers and you are doing it in DOS modes. Outstanding!

 

Keep this up and you are going make me finally switch to SDX (but I'll need a way to be able to use Action! and SDX together).

 

BTW, what's "CFA mode"?

I suspected there was a heavy overhead in the MyIDE ROM routines, but I must say I wasn't expecting this either.

 

To be clear, I'm using a slightly altered version of a driver written by someone I merely know as "Kyle" over on the AtariMax forums. He appears to have abandoned the project back in 2008. I have merely added support for 512 byte sectors at this stage, but results so far are hugely encouraging.

 

As for SpartaDOS X and Action! together, no problem: you'll need Internal SpartaDOS X, Action on disk, or a modified original SDX cart with piggy-back slot.

 

CFA stands for Compact Flash Association and it's an instruction set devised especially for compact flash devices. This enables us to run the I/O system in what's called 8-bit PIO mode in order to utilize the full 512 bytes in a sector. Naturally that way we're moving twice as much data per sector access, so it's all good. None of this would have come about if I hadn't performed a stability mod which finally enabled me to use one of the three CF cards I bought specially for MyIDE (most standard hard disks don't support CFA mode).

Edited September 9, 2010 by flashjazzcat

[Rybags]

Could you get any extra benefit by turning screen DMA off?

[+bf2k+]

Your numbers look great. For comparison, here's my numbers using a real HD: Seagate ST32430N attached to an ICD 1m MIO running Warerat's 1.4.0 beta firmware:

 

First using 256B/s:

 

DOS writing: 34761.9676 B/sek

DOS reading: 33686.8552 B/sek

DOS average: 34224.4114 B/sek

 

Real HD (256 byte sectors)

DOS writing: 11415.4566 B/sek

DOS reading: 22312.029 B/sek

DOS average: 16863.7428 B/sek

 

 

And with a 32MB, 512B/s volume:

 

DOS writing: 39849.0848 B/sek

DOS reading: 44157.094 B/sek

DOS average: 42003.0894 B/sek

 

 

(512 byte sectors)

DOS writing: 22964.4275 B/sek

DOS reading: 40905.3866 B/sek

DOS average: 31934.907 B/sek

 

Note with the real HD, the 512 byte numbers are roughly twice as fast... but not as fast as yours...

[flashjazzcat]

Could you get any extra benefit by turning screen DMA off?

I guess so; I could probably hit 60KB/s. I'll try turning off the stage 1 VBL as well.

 

Your numbers look great. For comparison, here's my numbers using a real HD: Seagate ST32430N attached to an ICD 1m MIO running Warerat's 1.4.0 beta firmware:

 

First using 256B/s:

 

DOS writing: 34761.9676 B/sek

DOS reading: 33686.8552 B/sek

DOS average: 34224.4114 B/sek

 

Real HD (256 byte sectors)

DOS writing: 11415.4566 B/sek

DOS reading: 22312.029 B/sek

DOS average: 16863.7428 B/sek

 

 

And with a 32MB, 512B/s volume:

 

DOS writing: 39849.0848 B/sek

DOS reading: 44157.094 B/sek

DOS average: 42003.0894 B/sek

 

 

(512 byte sectors)

DOS writing: 22964.4275 B/sek

DOS reading: 40905.3866 B/sek

DOS average: 31934.907 B/sek

 

Note with the real HD, the 512 byte numbers are roughly twice as fast... but not as fast as yours...

Trub (SDX) demonstrates upwards of 60KB/s read speeds using KMK/IDEa and 512 byte sectors. This kind of bandwidth is fast enought to stream video straight off the HDD via the FMS, while Sijmen's MyIDE videos required raw sector reads to attain sufficient speed. The MyIDE driver is already fast enough to stream video.

 

Partition tables aren't implemented with this driver yet, but I have no need of them. I'm inclined to think the most useful addition would be a PC based tool to read the content off the HDD.

Edited September 10, 2010 by flashjazzcat

[flashjazzcat]

This is the best I've been able to attain so far:

 

 

However, this is a buggy experimental driver (as you can probably deduce from the screenshot). I doubt a usable driver will perform this well. Shame, since it beats Trub's IDEa interface...

Edited September 10, 2010 by flashjazzcat

[flashjazzcat]

Doesn't look like these speeds will make it into the final driver unless Sijmen can tell me a way to avoid the need to check the status register before every data read.

 

Anyway, am working on a LBA partitioning scheme (the usual MyIDE CHS system is a nightmare), plus an FDISK program. The driver will be regularly updated to keep pace with SDX releases.

Edited September 11, 2010 by flashjazzcat

[twh/f2]

useful for comparison:

 

Read-write test v.3.4

 

SDX, SDrive, ATR/256 bytes, 16384 KB:

DOS writing: 4427.6760 B/sek

DOS reading: 28917.035 B/sek

DOS average: 16672.355 B/sek

 

i'm quite a bit surprised by the DOS reading result. 28Kb/s ??? faster than my ramdisk?? benchmark error?

 

Ramdisk, 256 bytes, 880kb

DOS writing: 24026.654 B/sek

DOS reading: 26351.814 B/sek

DOS average: 25189.234 B/sek

 

grtx,

\thomas

[twh/f2]

SpartaDOS ramdisk:

Read-write test v.3.0

Copyright © 1994-2005 by KMK

 

DOS writing: 40537.7319 B/sek

DOS reading: 46260.7058 B/sek

DOS average: 43399.2188 B/sek

 

I wonder why this ramdisk is almost twice as fast as mine:

 

Ramdisk, 256 bytes, 880kb

DOS writing: 24026.654 B/sek

DOS reading: 26351.814 B/sek

DOS average: 25189.234 B/sek

 

65816 ? or does the kind of ramdisk-hardware makes such a big difference?

 

grtx,

\thomas

[flashjazzcat]

Konrad warned me that the stage 1 VBL is disabled during SIO with low Pokey divisors, rendering the RWTEST results questionable. Not sure about the RAMdisks.

 

Your SDrive is writing 3 x faster than my SIO2SD at Pokey divisor 3. The appalling write speeds (just over 1KB/s) I'm getting with SIO2SD and SDX are one reason I'm pursuing this MyIDE driver with gusto.

[a8isa1]

useful for comparison:

 

Read-write test v.3.4

 

SDX, SDrive, ATR/256 bytes, 16384 KB:

DOS writing: 4427.6760 B/sek

DOS reading: 28917.035 B/sek

DOS average: 16672.355 B/sek

 

i'm quite a bit surprised by the DOS reading result. 28Kb/s ??? faster than my ramdisk?? benchmark error?

 

Ramdisk, 256 bytes, 880kb

DOS writing: 24026.654 B/sek

DOS reading: 26351.814 B/sek

DOS average: 25189.234 B/sek

 

grtx,

\thomas

Strange but my results for SDrive are very different.

 

[edited to improve appearance]

Read-write test v.3.5
© 1994-2009 by KMK

[800XL NTSC, [email protected] bits/sec using Hias' beta firmware (ver. ?) and HISIO.COM soft patch (from snapshot 1.20-1), MyDOS 4.53/4, DD, 65535 Sectors ATR]

DOS writing: 4090.538666 B/sek
DOS reading: 4970.781164 B/sek
DOS average: 3530.659915 B/sek

 

Here is SDrive at 128 kbits/sec (POKEY divisor 0)

 

Read-write test v.3.5
© 1994-2009 by KMK

[800XL NTSC, [email protected] bits/sec using Hias' beta firmware (ver. ?) and HISIO.COM soft patch (from snapshot 1.20-1), MyDOS 4.53/4, DD, 65535 Sectors ATR]

DOS writing: 5523.090182 B/sek
DOS reading: 7684.7693 B/sek
DOS average: 6603.9297 B/sek

 

and I also have results for MyIDE (4.2i)

 

Read-write test v.3.5
© 1994-2009 by KMK

[800XL NTSC, MyIDE 4.2i w/ Sandisk 2.0GB CF, MyDOS 4.53/4, DD, 65535 Sectors]

DOS writing: 7745.398633 B/sek
DOS reading: 7580.92105 B/sek
DOS average: 7663.1598 B/sek

 

-Steve Sheppard

 

[edit]

just adding results for ramdrive 1.0

 

Read-write test v.3.5
© 1994-2009 by KMK

[800XL NTSC, SDrive with Hias' beta firmware (ver. ?) , MyDOS 4.53/4, DD, 65535 Sectors ATR]

DOS writing: 18096.3922 B/sek
DOS reading: 19249.5936 B/sek
DOS average: 18672.9929 B/sek

 

Note: I have been unable to get Ramdrive (1.0) and HISIO.COM (1.20) to run at the same time.

Edited September 11, 2010 by a8isa1

[drac030]

This is SDX's SIO which disables VBL at Pokey divisors smaller than 7. Hias' SIO probably does not. This is why benchmark tests for very speedy SIO transfers are busted. We're currently working on fixing that.

 

This does not affect regular hard disks or ramdisk (exception: SDX' 65C816 ramdisk module disables VBL when running on a non-816-compatible OS).

Edited September 11, 2010 by drac030

[flashjazzcat]

This is SDX's SIO which disables VBL at Pokey divisors smaller than 7. Hias' SIO probably does not. This is why benchmark tests for very speedy SIO transfers are busted. We're currently working on fixing that.

Regardless of this, one can tell by the sector counter that my SIO2SD writes are very slow. Haven't got time to figure out why just now...

[drac030]

Try increasing the divisor. Slow writes probably mean that there are transmission errors and a command may not be completed without many retries.

[flashjazzcat]

Try increasing the divisor. Slow writes probably mean that there are transmission errors and a command may not be completed without many retries.

This is what I suspected. By the way, the S2S utility I stumbled upon at AtariArea the other day is an excellent SIO2SD tool.

 

Latest stable MyIDE driver results:

 

DOS writes: 41892.6276 B/sek

DOS reads: 48053.3081 B/sek

DOS average: 44972.9678 B/sek

 

This was accomplished by replacing:

 

LDA I_STAT

AND #$08

BNE LOOP

 

with:

 

BIT I_STAT

BMI LOOP

 

in the read loop, thus checking the device busy flag instead of the data ready flag. Appears to work OK. The write routine should be able to be optimised in the same way. Hopefully this will compensate for the (slight) calculation overhead when I come to implement LBA partition offsets.

Edited September 11, 2010 by flashjazzcat

[drac030]

BIT I_STAT

BMI LOOP

 

I think you could get rid of the BMI, I don't think the busy flag is ever set after DRQ appears.

[flashjazzcat]

I think you could get rid of the BMI, I don't think the busy flag is ever set after DRQ appears.

It's just another way of waiting for DRQ without actually testing the DRQ bit. Without that test, reads will be corrupted some of the time - that's now firmly established. I'm not sure if the net result is actually a short delay (i.e. a couple of NOPs might do the job), although how the Atari would outrun an IDE device is hard to figure.

Edited September 11, 2010 by flashjazzcat

[Rybags]

Got link for the S2S?

 

I think Hiass always has at least a minimal VBlank going... need it for timeout purposes.

[drac030]

BMI is 2 clocks per iteration, which it wastes. I meant this:

 

wdrq lda i_stat
and #$08
bne wdrq
loop bit i_stat
lda i_data
...

 

You waste 3 bytes, but the speed is the concern, right?

Edited September 11, 2010 by drac030

[flashjazzcat]

Got link for the S2S?

S2S

 

Enjoy - it's a superb little program, and can be installed resident.

 

s2i.txt

 

Translated docs as well.

 

BMI is 2 clocks per iteration, which it wastes. I meant this:

 

wdrq lda i_stat
and #$08
bne wdrq
loop bit i_stat
lda i_data
...

 

You waste 3 bytes, but the speed is the concern, right?

I don't get it. The first 3 lines of what you post have been completely disposed of and replaced by BIT/BMI. There's no point in testing the bits unless they're acted upon. I just tested a driver without the BMI to wait for the busy flag to clear and it doesn't run reliably.

Edited September 11, 2010 by flashjazzcat

[drac030]

I don't get it. The first 3 lines of what you post have been completely disposed of and replaced by BIT/BMI. There's no point in testing the bits unless they're acted upon. I just tested a driver without the BMI to wait for the busy flag to clear and it doesn't run reliably.

 

You shrunk the loop's execution time by removing and #$08, right? So I tell you, that you can shrink it further by trying to remove the BMI. The program is supposed to wait for DRQ (or BUSY clear), but as you already know, each loop iteration also needs reading I_STAT for the hardware to work reliably. So, again

 

wdrq
lda i_stat
and #$08
beq wdrq

 

This waits for DRQ *before* entering the read loop. Now there is the loop:

 

loop
bit i_stat ; this is required for stability - may be as well lda
lda data
sta (zz),y
iny 
bne loop

 

This way you get rid of the BMI executed (without any need or sense) at each iteration of the "loop"

Edited September 11, 2010 by drac030