mTCP DOS Logo

Performance Notes

One of the design goals of mTCP is to get very good performance without using a tremendous amount of memory.

I measure the performance of mTCP using two different methods. The first method is to use the mTCP FTP client which is a good real world test. FTP involves disk I/O, so the results will vary greatly from machine to machine depending on the disk setup.

The second method is to use the 'speed test' option on netcat. This option sends and receives junk data from memory without touching the disk, but it still forces all data to go through the TCP/IP stack. It is a good way to measure the peak speed of a given machine while removing highly variable factors such as the disk subsystem.

All tests are conducted on a private network with minimal other traffic. The machines are connected by a 10Mb/sec hub, which might depress the results slightly if there are collisions. The other machine is a Linux server capable of running rings around anything I test.

Here are some numbers that I have measured for FTP:

FTP results
Machine Adapter Xfer Size Send Time
(Seconds)
Send Rate
(KB/sec)
Recv Time
(Seconds)
Recv Rate
(KB/sec)
  Adapter notes FTP notes
PCjr (4.77 NEC V20) Xircom 260163 10.9 23.3 17.1 14.9   Bi-directional, no INTs RAM disk, default buffer sizes
PCjr (4.77 NEC V20) WD8003 260163 7.2 35.3 13.0 19.6   IRQ2, Shared Memory RAM disk, default buffer sizes
IBM PC XT (4.77 8088) 3Com 3C503 1376275 48.3 27.8 55.9 24.0   IRQ2, Shared Memory Orig MFM drive, default buffer sizes
AMD 80386-40, 128K L2 NE2000 3239589 8.4 378.4 6.9 456.5     IDE drive, default buffer sizes
AMD 80386-40, 128K L2 Xircom 3239589 29.1 108.7 17.8 177.5   Non-bidi, INT7 IDE drive, default buffer sizes
Pentium 133 LinkSys LNE100 3239589 ~2 ~2MB/sec ~2 ~2MB/sec   IDE drive, default buffer sizes, 100Mb/sec LAN, numbers are approximate


The numbers on the Pentium 133 are approximate - they were being limited by the speed of the hard drive.

And here are a few more numbers reported by other people:

Machine Adapter Send Rate
(KB/sec)
Recv Rate
(KB/sec)
Compaq Contura Aero 486SL (33Mhz) (unknown)   273 (approximate)
Pentium III Xircom 205 205

Some fun observations:

And here are some numbers using the 'speedtest' option on Netcat:

Speedtest results
Machine Adapter Xfer Size Send Time
(Seconds)
Send Rate
(KB/sec)
Recv Time
(Seconds)
Recv Rate
(KB/sec)
  Adapter notes Other Notes
PCjr (4.77 NEC V20) Xircom 4194304 128.0 32.0 136.5 30.0   Bi-directional, no INTs Wall time is around 146 secs for recv;
PCjr (4.77 NEC V20) WD8003 4194304 62.1 66.0 76.2 53.8   IRQ2, Shared Memory Wall time and measured time are consistent
IBM PC XT (4.77 8088) 3Com 3C503 4194304 72.3 56.6 92.6 44.2   IRQ2, Shared Memory Wall time and measured time are consistent
AMD 80386-40, 128K L2 NE2000 4194304 6.2 666.0 6.0 683.8     Wall time and measured time are consistent
AMD 80386-40, 128K L2 Xircom 4194304 21.6 189.3 32.1 127.7   Non-bidi, INT7 Wall time and measured time are consistent
Pentium 133 LinkSys LNE100 4194304 0.77 5319.5 0.66 6206.1   Timer resolution is only 55ms ..  this test is a little short

More fun observations:

The netcat code that I provide for download uses a TCP/IP receive buffer that has a default size of 8192. Incoming TCP/IP packets always get copied into that buffer. For speedtest that extra copy is not necessary - the incoming data is not going to be used and we are not really interested in the performance of another memcpy. In reality, the real speedtest numbers for receiving data should be slightly higher than what is shown in the table.

Depending on the machine and adapter combination it is possible to lose an excessive number of timer interrupts on the machine. This will cause the machine to lose a few seconds of time, thus under reporting the amount of time a file transfer takes. Where I observed this happening I made a note of it.



Created August 29th, 2009, Last updated December 28th, 2009

(C)opyright Michael B. Brutman, mbbrutman@yahoo.com