• Please review our updated Terms and Rules here

A new mTCP is available! (version 2020-01-01)

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,407
The short story: a new version of mTCP is available at http://www.brutman.com/mTCP/

The longer story ...

While the pace of releases has slowed in the past few years, rest assured that I am still actively fixing bugs and making improvements. This release improves flow control for TCP connections that are experiencing dropped packets, fixes ANSI emulation bugs in Telnet, sees a mostly rewritten (and improved!) HTGet, and adds a new feature to FTP to help people avoid corrupting data by using the wrong file transfer mode. The full list of changes can be found at http://brutman.com/mTCP/mTCP_2020-01-01_Release_Notes.html .


Downloads:

All downloads can be found at http://www.brutman.com/mTCP/.

Two versions of the programs are available for download. The standard version contains the standard EXE files. The UPX version contains EXE files that have been compressed with the UPX utility to save room on disk. When you run these versions they take a little longer to start, but if you are tight on disk space or are using floppy disks this is a good trade-off.

Documentation is available separately as a PDF file. I don’t include the PDF file with the binary versions because small DOS machines often can read PDF files.

Source code and developer documentation is available in a separate zip archive.


Support:

As always, if you have a bug report, are having trouble making things work, or just have a suggestion please email me at mbbrutman@gmail.com. While I might see bug reports or help requests in other places, email is the best, most direct way to get my attention.


Enjoy!
-Mike
 
Woohoo!

I'd like to benchmark my various adapters using the raw socket performance testing you used to create mTCP_Performance.html. Is this outlined in the documentation, or should I just blast NC.EXE with netcat?
 
I think it's in the doc, but here is a quick synopsis:

Send test:
  • Run "spdtest -send -listen 2000 -mb 8" (change the amount of data to be transferred as appropriate)
  • Linux side: time netcat your_dos_machine 2000 > delete.me

Receive test:
  • Run "spdtest -receive -listen 2000"
  • Linux side: time netcat your_dos_machine 2000 < delete.me

Doing it in this order has the advantage of having the input file for netcat created for you instead of using to use DD to generate data first.

Time the transfer from the Linux side; on the DOS side some packet drivers disable interrupts for too long, causing clock skew. I use the best 3 out of five transfers.

I also have newer timing data to post; I just couldn't get it all done at once. I'd appreciate (and post) any timing data that anybody wants to send me. I'm also looking to post a collection of packet drivers, so I'll take those too.


Thanks!
Mike
 
Excellent! Downloaded and installed, looking forward to trying to put it through its paces on my weird mongrel of a machine.
 
Send test:
  • Run "spdtest -send -listen 2000 -mb 8" (change the amount of data to be transferred as appropriate)
  • Linux side: time netcat your_dos_machine 2000 > delete.me

Receive test:
  • Run "spdtest -receive -listen 2000"
  • Linux side: time netcat your_dos_machine 2000 < delete.me

Turns out you need "-q 0" when netcat sends, or else it never closes, so: time netcat -q 0 1.2.3.4 2000 < delete.me

For an Intel Etherexpress 8/16 (running in 8-bit mode) on an IBM 5160 (4.77 MHz, original 8088), over a wireless dongle attached to the ethernet card, my times are:

Send test: 2:00.89 (about 67 KB/s)
Receive test: 1:52.29 (about 73 KB/s)
MTU: 1500, MSS Local 1460, Remote 1460

I got curious if the dongle was substantially affecting transfer rates, so I hooked up a cat5 cable and retested and saw no significant improvement (1-2 seconds variance).
 
It depends on the netcat package you have installed. Apparently there is a "NetBSD" version and a traditional version. (Or something like that.)
 
Er, I forgot to mention this ... I'm testing a few machines today and I'll have more recent data uploaded later.
 
Ok, some more results ...

Code:
Send:    43.4, Recv:    40.5, PCjr (NEC V20@4.77Mhz), Xircom PE3 on a bi-directional parallel port
Send:    76.7, Recv:    77.0, PCjr (NEC V20@4.77Mhz), 3Com 3C503 (8 bit ISA Bus)
Send:   115.3, Recv:   117.6, PCjr (NEC V20@4.77Mhz), WD8003WT (8 bit ISA Bus)
Send:   190.3, Recv:   191.9, PS/2 Model 25 (8086@8Mhz), 3Com 3C503
Send:   702.0, Recv:  1001.8, 80386DX@40Mhz, Davicom (16 bit ISA Bus)
Send: 10638.4, Recv: 10590.3, Pentium 133, LinkSys 100LNE (PCI Bus)

So your Intel card is running around where the PCjr with the 3Com 3C503 is. The Jr has a little bit of a boost because of the NEC V20 but otherwise it's a comparable platform.

Random observations:
  • The WD8003 is a standout card; the onboard memory really makes it fly.
  • The 3Com 3C503 can perform reasonably well when given a better bus; the Model 25 is getting almost 2.5x better speeds than the PCjr when the expected speedup is closer to 2x.
  • The 386 confuses me .. it can handle the full line speed of the card when receiving but can only hit about 70% on sending.
  • The Pentium 133 was incredible .. Those speeds are about maxing out a 100Mb/sec connection. (The send rate is 87 megabits per second!)
 
Another speed test, and a bug report:

AT&T PC 6300, 8MHz 8086, NSC 8390-based board using the SMC/WD/IBM packet driver: 163KB/s send, 165KB/s receive

Bug report: I still have to run DHCP a second time after setting the time or else I get "your DHCP lease has expired". To work around this, my autoexec.bat looks like:

dhcp
sntp -set xxxx
dhcp
 
Quibble - that's not a bug.

If you ran DHCP before setting the system time then it's going to write a bad timestamp. Then you run SNTP and the machine jumps far into the future. Which makes the DHCP timestamp look prehistoric.

What you really want is a combined DHCP/SNTP program that gets an IP address, the current time, and then writes it out once. But that's a convenience; the workaround to run DHCP twice is good enough for now.

The AT&T seems slow; the PS/2 model 25 with the same CPU and clock rate is faster with a 3Com 3C503 card. Do you know the exact card that is in the AT&T?
 
The exact card appears to be an SMC Elite16 Combo (8013 EWC). It is exactly this card: https://www.ebay.com/itm/SMC-8013EWC-ISA-ETHERNET-ADAPTER-61-600406-000-DOA-WARRANTY-/282393242179. It also has a RAM window of 8KB, which I've configured at D000. (port 280, IRQ 3, for the curious)

I'll test as many different brands of cards as I can in my 8086 (it's a real 8086, not an NEC V30) and report back. The Intel Etherexpress series of cards (I have two to test) will have to use my EXP8.COM packet driver because the default crnwyr driver (and I think the Intel-provided EXP16.COM) require 80186 instructions, ironically.
 
Last edited:
Quibble - that's not a bug.

If you ran DHCP before setting the system time then it's going to write a bad timestamp. Then you run SNTP and the machine jumps far into the future. Which makes the DHCP timestamp look prehistoric.

What you really want is a combined DHCP/SNTP program that gets an IP address, the current time, and then writes it out once. But that's a convenience; the workaround to run DHCP twice is good enough for now.

The AT&T seems slow; the PS/2 model 25 with the same CPU and clock rate is faster with a 3Com 3C503 card. Do you know the exact card that is in the AT&T?

wouldn't an easy fix be to make the SNTP program calculate the offset between existing system time and the internet time, then adjust the DHCP timestamp accordingly and write it back to the config file?

you could qualify the write on the timestamp being X number of seconds away from system time to make sure it only takes effect when running them back to back
 
That would probably work, but it's not really worth fixing - it's easy enough to just run DHCP again after SNTP to rewrite the timestamp with the current time.

In general I don't like mixing functions from different programs together. The DHCP utility writes the DHCP information, and SNTP fetches the time. Adding code to SNTP to handle DHCP timestamps doesn't help on newer machines that have a clock and also leads to more code to maintain.

I've thought about a combined utility but it's low on the priority list, mostly for the same reasons - not too many machines need it and it's duplicated code. I think things like IPv6, additional FTP features, a simplified HTTP server, etc. probably are more important.
 
A command-line option to SNTP to adjust the DHCP lease shouldn't be too hard to add, but adding a note to the documentation about how SNTP must always be followed by DHCP on systems without a battery-backed clock would be helpful.

So, I tried other cards, and quickly realized why I use this network card in the 6300: Like all M24-based systems without the "bus adapter kit", 16-bit port reads fail on the 6300, as the bytes return swapped. So you can only use memory-window-based cards, and this is the only card I have that provides a memory window and doesn't require an AUI transceiver. I think the speed differences we're seeing is because mine only has an 8k window, although I'll check the packet driver to see if it's doing something stupid.
 
Feature request: Add MFMT to FTPSRV. This would ensure that files I dump onto a new vintage system retain their date/timestamps. To do that today on drives not practical to hook up to modern systems, I have to zip everything, then unzip on the vintage system. If there isn't 2x the room, this gets tedious :)

REST would be helpful too, for dodgy connections that keep restarting. But this isn't as critical.
 
Back
Top