Supposedly Interlnk in DOS 6 is just a demo of Fastlynx, written by the same people.

Were the files you transferred compressible? That could account for some of the variation in transfer speeds. At 10 bits/byte (because of start and stop bit) the theoretical maximum of a 115200 serial interface is 11520 bytes per second. So a 1MB file should take 1:31. If it's faster than that, it's either compression, or they are doing some direct bit-banging on the UART rather than using it in the normal way.

edit: Kermit (C-Kermit or MS-Kermt for DOS or the revived Kermit 95 for Windows) would be nice to see, but it takes a lot of configuration since the default is the stop-and-wait 90 bytes per packet protocol which is why it's remembered as slow. It does not do parallel however.

Fastlynx does use stream compression for parallel port transfers.

It also has a "faster" transfer mode when used with its own special cable.
(the pinout is available in the help file. Image taken.)

Ok, I ran some tests ....

(Forgive if math is in error - working with screen displays and a calculator + plus I do have some vision problems)
-at least reported number are correct - captured into a LOG by my TIMEIT tool -

Test systems were PIII-500m and P4-1.4g
running DOS 5.0

Timing was done with my TIMEIT program which records the system 55ms "tick", then executes the command, reads "tick" again and calculate elapsed time.
- so yeah, timing accuracy is limited to 55ms -

Test file was a series of randomly generated binary bytes of the size shown. I have a MTF (MakeTestFile) tool I use sometimes while testing:
> MTF BIN -B 10
Will generate "BIN" containing 10k (10x1024 = 10240) of random binary data.

I called the file to transfer "BIN" (so it would be first on my RamDisk) and used DDLINKs preset Key function to automatically enter 'C', 'Y', <ESC>
This basically transmits the first file that shows up in the directory to the other end.

First tests were done over COM at 115,200 with simple null-modem cable:

107-15-26 09:20p       10,240 R:\BIN
2> ddlink c=1 k=CY~E
3Elapsed 0:00:01.210
4
507-15-26 09:26p      102,400 R:\BIN
6> ddlink c=1 k=CY~E
7Elapsed 0:00:09.405
8
907-15-26 09:28p    1,024,000 R:\BIN
10> ddlink c=1 k=CY~E
11Elapsed 0:01:30.970

I didn't test >1meg as that takes a while to transfer serial.

1024000 bytes x 10 bits (start,8,stop) = 10240000 bits
10240000 / 115200 = 89 sec theoretical max
60sec+30sec = 90sec
DDLINK doesn't do compression - I don't see how it could be a whole lot faster

-

Next tests were done over LPT

107-15-26 09:34p       10,240 R:\BIN
2> ddlink l=1 k=CY~E
3Elapsed 0:00:00.550
4
507-15-26 09:36p      102,400 R:\BIN
6> ddlink l=1 k=CY~E
7Elapsed 0:00:02.090
8
907-15-26 09:38p    1,024,000 R:\BIN
10> ddlink l=1 k=CY~E
11Elapsed 0:00:17.985
12
1307-15-26 09:41p   10,240,000 R:\BIN
14> ddlink l=1 k=CY~E
15Elapsed 0:02:56.550

In this case I added a 10m file (LPT is much faster)
10240000 bytes / 176 seconds = 58182 bytes(x8=465456 bits)/second

-

And just to show it, I transmitted the 10m file over LAN

107-15-26 09:45p   10,240,000 R:\BIN
2> ddlink p= k=CY~E
3Elapsed 0:00:15.125

Obviously a lot faster
10240000 bytes / 15 seconds = 682666 bytes(x8=5461328 bits)/second
- My DOS lab test machines are connected through a (10 mbps hub)

-

I use DDLINK a LOT - and don't have any of the problems you describe.
I would like to figure out what's happening in your setup - perhaps we could run some tests at some point!

-edit- I had modified my TIMEIT tool to show milliseconds and had accidentally showed as xx:xx:xx.xxxx - fixed to .xxx

Btw - DDLINK.COM I was using shows "May 13 2025" in it's startup message.

FWIW - DDLINK.COM is stand alone needing NO other files (it does need a "packet driver" for LAN)
and is <18k (17,630 bytes) in size.

I created it to have an efficient/small way of moving files to/from an ImageDisk system booted from floppy (which uses a RamDrive for working storage)
- not everyone has DOS installed on a system these days!
It fits nicely on boot floppy, still leaving LOTS of space for ImageDisk and other tools!

I hadn't used DDLINK before, tested it out tonight.
Works fine, even though the server side is inside DOSBox and using a USB-serial.
Copying a 2,094,602 byte file, with B=4000, DDLINK does it in 3min9sec.
My properly-tuned Kermit does it it 3min17 sec.
Theoretical max is 3 min 2 sec, so both of these are right in line with expectations.

As DDLINK.TXT says it doesn't need RTS-CTS, it must use a stop-and-wait protocol? but that is fine for a low-latency, local connection like this.

Bootstrap mode worked too--though I have a null modem cable that has DSR properly connected at the DOS end (I had to crack open one end and modify it as such).

jakethompson1 wrote on 2026-07-16, 02:59:

I hadn't used DDLINK before, tested it out tonight. Works fine, even though the server side is inside DOSBox and using a USB-ser […]
Show full quote

I hadn't used DDLINK before, tested it out tonight.
Works fine, even though the server side is inside DOSBox and using a USB-serial.
Copying a 2,094,602 byte file, with B=4000, DDLINK does it in 3min9sec.
My properly-tuned Kermit does it it 3min17 sec.
Theoretical max is 3 min 2 sec, so both of these are right in line with expectations.

Always good to hear.

I use DDLINK under DosBox all the time - most often over LAN with DosBoxs virtual NE2000 network interface.
It is by far the easiest way I've found to move files between my DOS systems that don't have an "official" network configured and my more modern Winblows systems (with DDLINK running in DosBox)

As DDLINK.TXT says it doesn't need RTS-CTS, it must use a stop-and-wait protocol? but that is fine for a low-latency, local connection like this.

DDLINK is written using my own Micro-C/PC compiler which has a set of very efficient buffered, interrupt driven serial I/O functions ... on most systems it can run at 115,200 without losing data* and very low end-to-end turnaround time - the actual protocol is documented in detail within DDLINKs documentation (I even provide a [much simplified] sample program in C source which can communicate with it!)

* I've used it from 286-I7 without needing slower speeds ... the only time I've had to set it slower is when someone gave me a "Poqet PC" - a very slow CMOS 8088 system that runs on AA cells. It has DOS 3.3 in ROM, a small RamDisk, and a battery backed up CMOS RAM "hard drive" in which the battery had failed (and I've still not gotten around to replacing the officially non-removable cell) It has a proprietary expansion cable/connector which I don't have, but found a dead PCI card edge has the right spacing, and was able to make a serial connection that way. I have to bootstrap DDLINK to it, then run it at 19,200 to get reliable (no re-TXs) transfers - but that system is excruciatingly slow!

Bootstrap mode worked too--though I have a null modem cable that has DSR properly connected at the DOS end (I had to crack open one end and modify it as such).

DDLINKs serial I/O code doesn't care what RTS/CTS, DTR/DSR is doing - it needs only the basic serial wires (Rxd, Txd and Gnd)
The need for these signals during BOOTSTRAP is because it has to talk to a DOS CTTY console - and DOS needs these signals to communicate.
- a bog standard null-modem (Txd<>Rxd, Dtr<>Dsr, Rts<>Cts, Gnd) will work find to bootstrap.

jakethompson1 wrote on 2026-07-15, 22:17:

Supposedly Interlnk in DOS 6 is just a demo of Fastlynx, written by the same people.

Were the files you transferred compressible? That could account for some of the variation in transfer speeds. At 10 bits/byte (because of start and stop bit) the theoretical maximum of a 115200 serial interface is 11520 bytes per second. So a 1MB file should take 1:31. If it's faster than that, it's either compression, or they are doing some direct bit-banging on the UART rather than using it in the normal way.

edit: Kermit (C-Kermit or MS-Kermt for DOS or the revived Kermit 95 for Windows) would be nice to see, but it takes a lot of configuration since the default is the stop-and-wait 90 bytes per packet protocol which is why it's remembered as slow. It does not do parallel however.

I forgot to mention that the 2 files were already compressed (1 as zip and 1 as 7z).

Will take a look at Kermit. Needs to have a NC like interface though. One of the reasons I didn't include pcAnywhere was that it didn't have one (and also didn't support parallel).

DaveDDS wrote on 2026-07-16, 02:02:

I use DDLINK a LOT - and don't have any of the problems you describe.
I would like to figure out what's happening in your setup - perhaps we could run some tests at some point!

I don't understand it as well. More than willing to take a closer look. Just PM me or put it here if you need to test something or need more information.

DaveDDS wrote on 2026-07-16, 02:02:

Test file was a series of randomly generated binary bytes of the size shown. I have a MTF (MakeTestFile) tool I use sometimes while testing:
> MTF BIN -B 10
Will generate "BIN" containing 10k (10x1024 = 10240) of random binary data.

Dave, I looked through all your files (even your OLD files) on your site but I couldn't find MTF.

This utility will be very useful to create test files of random data. May you possibly either link to it or provide the MTF.COM file here as an upload?

zyzzle wrote on 2026-07-18, 20:26:

DaveDDS wrote on 2026-07-16, 02:02:

Test file was a series of randomly generated binary bytes of the size shown. I have a MTF (MakeTestFile) tool I use sometimes while testing:
> MTF BIN -B 10
Will generate "BIN" containing 10k (10x1024 = 10240) of random binary data.

Dave, I looked through all your files (even your OLD files) on your site but I couldn't find MTF.

This utility will be very useful to create test files of random data. May you possibly either link to it or provide the MTF.COM file here as an upload?

Yeah, it's a little tool I needed once and just "ripped out" for myself - I've never published it - It's a simple thing to do ... except ...

I didn't clean it up, make it look nice, add proper command help etc. - give me a few days and I'll see what I can make available.
(got a few enhancements I've wanted to add - but never found worth it - might do now (like being able to set random seed - currently it's randomized at startup from clock tick - but sometimes it would be nice to be able to generate the same "random" 😀 file)

Ok, here's a "first pass" at a public version:

Note that this is a DOS (16-bit) program and won't run under Win32
(It runs well in DosBox ... I could compile a .DVM version for those who might
want an "easier" way to run it under Win32/64.

1MakeTestFile
2
3use: MTF file[.ext] -B<size> [-R]*    Make [.BIN] Binary file of <size> k-bytes
4            ""      -T  ""             ""  [.TXT]  Text   ""  ""   ""     ""
5            ""      -L  ""             ""    ""     ""    ""  ""   ""    Lines
6
7*   -R          show random number generation seed
8    -Rvalue      set    ""    ""       ""      ""   to value
9
10Creates a "test" file of random binary data or text lines.
11
12Dave Dunfield   -   https://dunfield.themindfactory.com

Thanks, that's a very useful small DOS program. Been looking for something that can do this for awhile now. We should be able to produce the same "random" data with the same random seed using your -R switch. But randomized from clock tick at program start works also for truly random data, as clock ticks will always be different, assuming we don't change the date.

zyzzle wrote on 2026-07-20, 01:46:

Thanks, that's a very useful small DOS program. Been looking for something that can do this for awhile now. We should be able to produce the same "random" data with the same random seed using your -R switch. But randomized from clock tick at program start works also for truly random data, as clock ticks will always be different, assuming we don't change the date.

Doesn't actually have anything to do with the date.

The PC has a 55ms "tick" in BIOS - 18.2 a seconf x 60 secoonds x 60 mins x 24 hours = 1.5m ticks/day, the chances of running the same application at the sane "tick" - adjusted for differences in PC clocl speed make ot VERY unlikely that the "random sequence" will be the same for two different runs if the same program (and it it were truly randim - this woukd be entirely possible.