Indus GT Sync - writes are slow

[rcgldr]

I've been trying to benchmark read and write times with the Indus master super-sync atr file (DOS XL 2.35I2), using INITSYNC to format a real floppy on the Indus GT. When I run a write read test, the read rate is ~3686 byte per second, which would correspond to an interleave of 6, but the write test is ~ 900 bytes per second, which would correspond to an "interleave" of 24 (18 + 6), like a full rotation after every sector write. I though verify was stuck on, but it's using command hex D0 ("P" + hex 80) for writes without verify, and D7 ("W" + hex 80) for writes with verify, slower still at 517 bytes per second, which would correspond to an "interleave" of 42 (18 + 18 + 6).

Edited July 2, 2018 by rcgldr

[_The Doctor__]

maybe old fashioned trial and error to adjust interleave 1 sector at a time until the writes speed up and then note the peek speed.... work backwards from that to figure out why that works the way it does... then work out a layout/scheme to get the writes out just in time. Reads might suffer slightly, but I doubt it.

Edited July 2, 2018 by _The Doctor__

[+Nezgar]

So... for reference as a baseline, try a disk with a regular Atari formatted skew, and see if it writes faster? Is this DD?

 

Also try a disk formatted with us doubler skew.

Edited July 2, 2018 by Nezgar

[+Faicuai]

I've been trying to benchmark read and write times with the Indus master super-sync atr file (DOS XL 2.35I2), using INITSYNC to format a real floppy on the Indus GT. When I run a write read test, the read rate is ~3686 byte per second, which would correspond to an interleave of 6, but the write test is ~ 900 bytes per second, which would correspond to an "interleave" of 24 (18 + 6), like a full rotation after every sector write. I though verify was stuck on, but it's using command hex D0 ("P" + hex 80) for writes without verify, and D7 ("W" + hex 80) for writes with verify, slower still at 517 bytes per second, which would correspond to an "interleave" of 42 (18 + 18 + 6).

 

Spot-on!

 

VERY fast reads, but very slow writes (in DOS-XL and GTSYNC=on, SuperSynchro).

 

However, same disk (with same format under SDX / GTSync) taken to SDX (with directory structure rewritten with SDX's FORMAT utility), and watch how speeds shoot up to 3,400 Bytes/Sec. for BOTH read / write operations. In other words, r /w difference disappears (!) PLUS an extra bonus of IndusGT fastest sector interleave (DOS-XL) being WELL handled by SDX (!)

[_The Doctor__]

is that the quick format, build only option, or the full format on the SDX re write?

[rcgldr]

I tested rates with SpartDos 2.3.

 

Using SpartaDos with floppy formatted on the 1050 with interleave of 7, the 1050 doubler is a bit faster on writes than the Indus doubler. 2900 bytes per second versus 2500 bytes per second. Both of them read just under 3000 bytes per second. The 1050 takes longer to format, one more revolution per track than the Indus, but I'm not sure what that means. I repeated the test, this time formatting on the Indus with interleave of 7 (doing this using XINIT from SpartaDos 2.3). Speeds about the same, Indus write speed was a bit less at 2400 bytes per second, but it could be a variation in where the test file is located (what sector of a track the write starts from).

Translating the rates = Indus write rate (2457 bytes per second) is equivalent to an interleave of 9, while 1050 write rate (2997 bytes per second) is equivalent to an interleave of 7.389 (7 + 7/18), so there is some form of track skewing during format. It seems unlikely that the drive track skews by analyzing the interleave table, and it's more likely that it's just a fixed delay after stepping the head to format each track.

The write times using the APE interface are faster because it's all sequential writes, no directory or linkage updates.

Edited July 2, 2018 by rcgldr

[+Faicuai]

I tested rates with SpartDos 2.3.

 

Using SpartaDos with floppy formatted on the 1050 with interleave of 7, the 1050 doubler is a bit faster on writes than the Indus doubler. 2900 bytes per second versus 2500 bytes per second. Both of them read just under 3000 bytes per second. The 1050 takes longer to format, one more revolution per track than the Indus, but I'm not sure what that means. I repeated the test, this time formatting on the Indus with interleave of 7 (doing this using XINIT from SpartaDos 2.3). Speeds about the same, Indus write speed was a bit less at 2400 bytes per second, but it could be a variation in where the test file is located (what sector of a track the write starts from).

Translating the rates = Indus write rate (2457 bytes per second) is equivalent to an interleave of 9, while 1050 write rate (2997 bytes per second) is equivalent to an interleave of 7.389 (7 + 7/18), so there is some form of track skewing during format. It seems unlikely that the drive track skews by analyzing the interleave table, and it's more likely that it's just a fixed delay after stepping the head to format each track.

The write times using the APE interface are faster because it's all sequential writes, no directory or linkage updates.

 

With SpartaDos 4.49, for instance, Indus-Doubler will write at 2,950+ Bytes / sec and read at 3,000 Bytes/sec.

 

Tested a like million times, here.

[+Nezgar]

Can the actual sector layouts used in relation to each test be posted?

 

I'm sure the resulting formatted skew between SpartaDOS 2.3 XINIT, SDX format on a 1050 US Doubler, and SDX on an Indus GT are different...

[Kyle22]

I've been trying to benchmark read and write times with the Indus master super-sync atr file (DOS XL 2.35I2), using INITSYNC to format a real floppy on the Indus GT. When I run a write read test, the read rate is ~3686 byte per second, which would correspond to an interleave of 6, but the write test is ~ 900 bytes per second, which would correspond to an "interleave" of 24 (18 + 6), like a full rotation after every sector write. I though verify was stuck on, but it's using command hex D0 ("P" + hex 80) for writes without verify, and D7 ("W" + hex 80) for writes with verify, slower still at 517 bytes per second, which would correspond to an "interleave" of 42 (18 + 18 + 6).

You DO have a RAMCharger in that Indus, right?

 

SuperSync is for 64K drives, it may be strange on stock drives. Try regular Synchromesh.

[+Faicuai]

You DO have a RAMCharger in that Indus, right?

 

SuperSync is for 64K drives, it may be strange on stock drives. Try regular Synchromesh.

 

It will be the same with or without RamCharger...

 

At least, on this side of the screen....

[Kyle22]

I'll have to test that. It's been quite a while.