Deunan wrote on 2023-07-21, 10:28:

Transfer rates can vary, depending on how smart the TCP/IP implementation on the FTP server is, since DOS machines are slow and send/receive pretty much one packet at a time. Modern TCP stacks can buffer tons of data so the idea is to send as fast and as much as they can - this tends to overload DOS machine and it keeps dropping packets and have to wait for retry. But it works well enough to be usable even on 286 systems.

mTCP FTP transfers will send at least four packets at a time. (Four queued to the Ethernet adapter, plus whatever has already been sent on the wire.) With well behaved machines even an XT class machine on a slow adapter can keep up with minimal hiccups.

The problem comes with clients that insist on trying to transfer multiple files at a time. If your machine can only support a 40KB xfer rate (XT with an MFM hard disk), then multiple files at the same time just forces you to share that bandwidth.

By the time you get to a 286 system there should be no problems. And a 386 can keep up with anything.

Hm, I tend to download more than upload, maybe that's why I see more hiccups? I see the bytes counter go up and then stall for a few seconds, and the resulting overall transfer speed is half (or less) what the link is capable of. And it shouldn't be limited by HDD since more often then not it's a CF card. MFM aside even at PIO0 I should not be capped below 500k/s.

Use smartdrv for caching.

On CF cards? On slower CPUs that usually only slows the system down. It does help on MFM drives but you'll just hit the RAM buffer size in few seconds at best and it'll slow down to MFM write speeds.
But I guess I can try running some tests with SCSI drives, the controllers do DMA so won't be bottlenecked by CPU and I can just attach a fast enough HDD that won't saturate during writes (not with ISA controller anyway). I'll put that on my to-do list.

Can't hurt to try it. What system do you run this on?

A few different ones. 286 to Pentium but most issues are on slower machines, even 386DX-40 seem to struggle to maintain a consistent transfer speed. It's like burst of fast packets and then a stall for a few seconds. Rinse and repeat. It's still the fastest way to get files around, especially if they don't fit on a single floppy.

Maybe the CF cards are just too slow ?
In the past, I've measured different speeds with HDTune and an USB 3 card reader (the 1.1/2.0 models were unusable for benchmarking).
And it were NOT always the modern cards who were quick. Some of the older cards had a lower latency.
The range was 0.1ms to 12ms (worst), if memory serves. That's why I noted their access speeds on their labels, even.

Edit: On a side note, I've noticed quite often "hickups" on Windows 98SE with CF cards.
Enabling DMA helped a bit, but it were the CF cards who had trouble keeping up with things.
They're not made for handling thousands of small file read/writes, after all.
Their purpose is to serve digital cameras and other special hardware.
Hardware which reads/writes an continuous stream of data in a linear fashion (recording JPEGs, or MP4).

Edit: CF cards not necessarily have a buffer, also. In the past, they had 1KB to 4KB buffers, I vaguely remember.
That's not the case anymore, I think. CF cards have become cheap, like MLC/TLC SSDs:
The old SLC (an early MLC) models still had a DRAM buffer on the controller board, while modern SSDs do not.
Consumer models, I mean. Industrial or server models may still do. So maybe an "industrial" CF card is worth a try.
But be careful that it is a real industrial type.. Counterfeit flash media are popular.

Edit: Please also note that IDE "controllers" are just IDE host adapters. They're ISA/AT bus address decoders, more or less.
So if the ISA speed is being run out of specification, so is the CF card. Maybe some CF cards don't like tight timings.

Finally had some free time and sat down to solve the file transfer speed bump. The method I used was using winimg under windows 10 to move files into gotek images and just open them up like floppies on the target system.

Got cpu-z transferred.

Interesting that it reports 20mhz and low performance.

I am expecting this is likely from not having cyrix.exe setup yet. Or the anyclk device may not be setup correctly but I think that it is, will investigate.

Sphere478 wrote on 2023-07-30, 21:43:

I am expecting this is likely from not having cyrix.exe setup yet. Or the anyclk device may not be setup correctly but I think that it is, will investigate.

If you have the CPU misconfigured, for example set the use FLUSH with that input floating, you might be getting a constant cache flush which is not a free operation. This will degrade the CPU performance well below 386 levels.

Deunan wrote on 2023-07-30, 22:07:

Sphere478 wrote on 2023-07-30, 21:43:

I am expecting this is likely from not having cyrix.exe setup yet. Or the anyclk device may not be setup correctly but I think that it is, will investigate.

If you have the CPU misconfigured, for example set the use FLUSH with that input floating, you might be getting a constant cache flush which is not a free operation. This will degrade the CPU performance well below 386 levels.

Pretty good chance the registers aren't set up correctly. I haven't worked with cyrix.exe before, so I will be learning this and how to set it up shortly.

I figured out why I wasn't able to transfer files by CD. I think windows 10 was burning the files in a way that windows 95 didn't understand. I found a old CD I am pretty sure I burnt from windows XP and that worked.

Investigating possibility of a MR bios,
Re: How about a MR-BIOS ROM file repository?

In it’s current config (haven’t changed anything yet) it is about as fast as a 386 DX-40 according to speedsys in DOS. But cpu-z in windows says slower.

Tried to get clock doubling going. Didn’t work.. not sure why.

Currently running 20mhz crystal L L setting on AnyClk device. Which should be 80mhz? Is that proper?

It’s stable until I set clock doubling.

Tried setting H M setting for 16mhz x 4 64mhz

Didn’t work. System freezes almost immediately.

Am I to set a lower setting on bus?

I tried 3.6v at first then observed other’s results noting that 80mhz required 4.2v so I set that. It also didn’t help. Even at 64mhz

Perhaps I must set other registers first?

The registers could be the reason for the poor performance.

Now regarding clock doubling. I have seen that some M/Bs, Chipsets... Really do not like to work in this 2x mode.
My observation was though on a 386sx / 486sxlc system, but it could be something similar there.
Later someone else tried the same on this M/B + adapter and failed also.

Check my video:
https://www.youtube.com/watch?v=sgXdiCPwGUA

Sphere478 wrote on 2023-07-31, 03:16:

In it’s current config (haven’t changed anything yet) it is about as fast as a 386 DX-40 according to speedsys in DOS.

Ha, no, a decent cached 386DX-40 system would score about 6.50 here (without NPU due to the bug in Speedsys where 386+387 scores lower). This bar has what, 300 pixels or so? Any single pixel is a pretty big chunk of 386 performance, with such small values you simply have a huge reading/display error.

EDIT: Nope, actually my OPTi mobo does 6.50 or even 6.89 with tight timings when Cyrix CX-83D87-40-GP FASMATH is installed. I see you have someting there as well so you should be getting more than 6 and something like 9.21 / 9.40 without NPU (that was tested on different mobo though).

As for clock doubler (and that's assuming you are running at 20MHz) be aware it tends to have some limitations which are mobo-dependant. For some reason certain chipsets or cards, or combinations of both, do not like fast back-to-back I/O cycles - which can happen with internal cache and high clocks speeed. I'm not 100% sure why that is, the CPU bus should be running at half the internal clock after all, but perhaps some signal timings are affected. Point here is it usually works OK on PC mobos but it's not guaranteed.

I know this is going to be super obvious and rudimentary advice, but have you tried benchmarking with everything uninstalled and as simple as possible?

No expansion cards (other than those needed to run the diag), remove NPU, just the minimum amount of installed RAM, etc etc?

I ask because I once had a 386sx with a TI 486 upgrade installed that became a slug on valium when it had a math copro installed. Why? I have no idea!