SIO2PC writes faster than reads?

[Mazzspeed]

This is doing my head in!

 

I'm currently running a home made SIO2PC adapter using a quality Lotharek SIO plug and an FTDI board purchased from the electronics store up the road that I assume is genuine (the serial number is: AR0K9KYM according to Windows device manager), What's boggling my brain is the fact that my write speeds are faster than my read speeds using RespeQt running Divisor 0 with handshake on CTS (as that's what my board supports) and DTR control enabled. The device RespeQt is installed on is a 2.3Ghz Raspberry Pi 400 with storage provided by a USB 3.0 connected SSD drive.

 

Has anyone encountered this before?

 

I tried connecting the device to a Windows laptop running RespeQt and there's no way HSIO is stable, it just bombs as soon as you try to access the drive, although I didn't install the genuine FTDI drivers under Windows, so that may be why - As far as I know the drivers don't need to be installed under Raspberry Pi OS as they're included in the kernel.

 

I did find that if I disable Handshaking, speeds jump by about 1000 B/sec, but writes are still faster than reads and stability is compromised under Linux.

 

Open to suggestions/opinions as I'm out of ideas. I even shortened the shielded cable that was running between the SIO connector the the FT232 board and soldered all connections. I checked for resistance between the SIO terminal and the end of the wire that connects to the FT232 board and got 0.00 ohms with perfect continuity.

 

Images for reference:

 

 

 

 

 

[Sugarland]

Have you tried another type/brand of FTDI board?

[+bob1200xl]

Is D1: an actual drive? Drives tend to have cache buffers that are written to, with no latency. Reads, however, have to actually wait for the data to  run under the head(s). Makes reads slower?

 

Bob

 

[Mazzspeed]

18 minutes ago, Sugarland said:

Have you tried another type/brand of FTDI board?

Not yet. I've messaged Lotharek to see if his rev 2 SIO2PC adapter supports PROCEED.

 

10 minutes ago, bob1200xl said:

Is D1: an actual drive? Drives tend to have cache buffers that are written to, with no latency. Reads, however, have to actually wait for the data to  run under the head(s). Makes reads slower?

 

Bob

 

Bob, D1: is a 720 sector/512 bytes per sector 'hard disk' under RespeQt, see below. Your comments regarding cache buffers are interesting as on reads I get reports shown in the log file below regarding to 'Get status $ff' and 'Get PERCOM block...', I don't get these messages on writes and I think these messages (whatever they are) are the cause of my low read performance.

 

[+mytek]

I find that I often need to use a powered hub when shooting for divisor zero on a laptop. Desktops are usually not an issue, but many laptops have pretty feeble power on their USB ports. So try a powered hub and see if that fixes the problem for you.

 

[Mazzspeed]

37 minutes ago, mytek said:

I find that I often need to use a powered hub when shooting for divisor zero on a laptop. Desktops are usually not an issue, but many laptops have pretty feeble power on their USB ports. So try a powered hub and see if that fixes the problem for you.

 

That's a good tip my friend. I have a powered hub here, I'll try that.

 

Thank you for the suggestion.

[Mazzspeed]

Does anyone know the meaning of the entries in the log labeled:

 

- Get status $ff

- Get PERCOM block (....)

 

?

[Faicuai]

5 minutes ago, Mazzspeed said:

Does anyone know the meaning of the entries in the log labeled:

 

- Get status $ff

- Get PERCOM block (....)

 

?

 

SIO-chain misfire. Speed dropping to 19,200 bos, at those interleaved requests, and then raising back to Div. 0.

 

Two or three of those and the performance hit is huge.

 

Div. 0 speeds @ 512 bytes/sec (ATR, RespeQt, no PC-Link) are much higher:

 

 

 

 

[Mazzspeed]

3 minutes ago, Faicuai said:

 

SIO-chain misfire. Speed dropping to 19,200 bos, at those interleaved requests, and then raising back to Div. 0.

 

Two or three of those and the performance hit is huge.

 

Div. 0 speeds @ 512 bytes/sec (ATR, RespeQt, no PC-Link) are much higher:

 

 

 

 

The log shows when the speed drops from 19,200 bps to 125,000 bps, that was the problem I was getting initially before removing the caps off the SIO port.

 

After removing all caps on the SIO port I no longer see the transfer speed dropping to 19,200 bps and back to 125,000 bps in the log files and can't hear the speed changing via the SIO pips. I'm certain these log entries are the cause of my problems, but I don't know what they are or why RespeQt is performing the highlighted tasks.

 

I've yet to try the powered USB hub.

[Mazzspeed]

Just tried the powered hub. Adding a powered hub made it worse - Transfer toggled to 19200 bps three times and hung on each occasion.

 

I don't get it? It has to be that serial to USB board. I just don't know why?

 

EDIT: Could the fact that I didn't install the diodes make a difference? I thought they were only needed if you were running additional devices on the SIO port to avoid an open drain situation?

Edited May 20, 2021 by Mazzspeed

[Mazzspeed]

Does anyone know what status code $ff is? It looks like the status code is causing RespQt to read the percom block for some reason.

[Faicuai]

8 hours ago, Mazzspeed said:

code $ff is? It looks like the status code is causing RespQt to read the percom block

I did take another full run on Divisor-0, with 512 bytes/sec .ATR (RespeQt), via SIO-to-PC Interface (USB).

 

I only got one $FF code, and that was at the end of the WRITE cycle, and before initiating the READ cycle. Nothing else.

 

Effective speeds same, as I posted above (8 KB/sec write, +10 KB/sec read).  

[Mazzspeed]

33 minutes ago, Faicuai said:

I did take another full run on Divisor-0, with 512 bytes/sec .ATR (RespeQt), via SIO-to-PC Interface (USB).

 

I only got one $FF code, and that was at the end of the WRITE cycle, and before initiating the READ cycle. Nothing else.

 

Effective speeds same, as I posted above (8 KB/sec write, +10 KB/sec read).  

You should see it twice as far as I can tell. Once at the end of the write stage, and once at the end of the read stage. Now I'm starting to wonder if it's normal.

 

I'm not really interested in outright performance figures, I need to try and work out if this is an actual real issue before I waste money buying a replacement SIO2PC adapter that I may not need. The outright performance doesn't bother me, what bothers me is the fact things may not be working 100% and I like it when things work 100%, as writes are almost never faster than reads in my experience.

 

If anyone else wants to submit their RWTEST results with DMA off so I can get a clear basis of how RespeQt should perform using a 720 sector, 512 bytes/sector hard disk at divisor 0 please feel free to share your results so I can get a better understanding of what to expect in this scenario.

 

End of write:

 

 

End of read:

 

 

EDIT: The section highlighted in green at the end of the read cycle also has me confused. I'm not too sure what's happening here or if it's even normal?

 

Edited May 20, 2021 by Mazzspeed

[drac030]

It is the RWTEST deleting the temporary file.

[Faicuai]

1 hour ago, Mazzspeed said:

You should see it twice as far as I can tell.

Correct, I just checked again.

 

Only one in the middle, and then one at the very end.

[Mazzspeed]

34 minutes ago, drac030 said:

It is the RWTEST deleting the temporary file.

OK. Would that impact bench results? I see no errors in the log files it's just odd how writes are faster than reads. If I bench my PBI HDD I don't see this issue, reads are faster than writes - Which is what I'd expect.

[drac030]

The only thing abnormal in your setup is the effective speed around 7 KB/s while the bitrate is 125 kbps. If I have to guess, it might be due to retries occurring because the serial connection is not stable.

 

Here I am getting effectively about 9 KB/s at nominal bitrate 98 kbps (US index 2). Correction: this is PCLink which gives me that. On a 512-byte ATR I get about 7 KB/s like you. Still, this is US=2, not 0.

 

And no, deleting the file at the end would not affect the benchmark results.

Edited May 20, 2021 by drac030

[Mazzspeed]

7 minutes ago, drac030 said:

The only thing abnormal in your setup is the effective speed around 7 KB/s while the bitrate is 125 kbps. If I have to guess, it might be due to retries occurring because the serial connection is not stable.

 

Here I am getting effectively about 9 KB/s at nominal bitrate 98 kbps (US index 2).

 

And no, deleting the file at the end would not affect the benchmark results.

Here's a video of the run. Excuse the shakiness, trying to film with my left hand.

 

I can't see any retries and as shown in the top corner CPU usage is fine?

 

 

[drac030]

I do not know really because I do not use RespeQt. Anyways, write speed is the rate at which the Atari sends the data. Read speed is the rate at which the PC sends the data. Maybe there are big intervals between the command stage and data stage and that is why the overall reading speed is lower than expected. Why the writes seem slow too, I have no idea. As I said, the figures you get are only slightly better than normal results for US=2:

 

[Mazzspeed]

9 minutes ago, drac030 said:

I do not know really because I do not use RespeQt. Anyways, write speed is the rate at which the Atari sends the data. Read speed is the rate at which the PC sends the data. Maybe there are big intervals between the command stage and data stage and that is why the overall reading speed is lower than expected. Why the writes seem slow too, I have no idea. As I said, the figures you get are only slightly better than normal results for US=2:

 

Valid point which does stand to reason. It's strange how my results for divisor 0 compare to results on other systems for divisor 2.

Edited May 21, 2021 by Mazzspeed

[Faicuai]

Div. 2 got me curious, so I did a run with it, and this is what I am getting (for an apples-to-apples review, on stock-SIO A8 host):

 

 

 

[Mazzspeed]

8 hours ago, drac030 said:

I do not know really because I do not use RespeQt. Anyways, write speed is the rate at which the Atari sends the data. Read speed is the rate at which the PC sends the data. Maybe there are big intervals between the command stage and data stage and that is why the overall reading speed is lower than expected. Why the writes seem slow too, I have no idea. As I said, the figures you get are only slightly better than normal results for US=2:

 

Well here's something interesting...

 

I thought there could be a CPU bottleneck (although I doubted it as this Pi is actually running at 2.4Ghz and apparently RespeQt runs fine on a Pentium 233 MMX, the Pi should run rings around a Pentium 233 MMX), however writes use more CPU power than reads (look at the top two processes under HTOP, essentially the process is jumping threads - I should have pressed Shift & H to drop down to one visible process) and my writes are faster than my reads according to RWTEST...Makes no sense!

 

I must say, I am a bit surprised regarding RespeQt's ARM CPU usage. I installed RespeQt on my dual X5675 workstation, but I can't see the FT232 board via it's COM port, which is a little odd - Perhaps KDE doesn't have the drivers installed. I checked via terminal and I know I've got the right COM port.

 

I'll check more tomorrow, tired now. It would be a real shame if RespeQt doesn't run well on ARM devices, as I really have no interest in running a high powered desktop or Windows based laptop just to get a couple of virtual drives via SIO. The other interesting thing is I can drop right down to divisor 5 and writes are still faster than reads.