Another request - can you send me a trace of FTP4DOS transferring the same file? Are you on a real machine or a virtual machine? Do you have any power saving TSRs loaded?

I know my code is calling the DOS Idle interrupt and the interrupt to signal the program is idle when it's just spinning waiting for packets. (Int 2F, AX=1680x). If FTP4DOS is not doing that it might explain the difference.

In general, they both poll to see if new packets have arrived, and then they try to write whatever they have to keep the TCP window open and available. My code updates the file transfer progress on the screen using BIOS calls, and that might be slowing it down, but probably not by such a huge factor.

FTP4DOS spins in a loop, reading from the TCP buffer and writing whatever it finds until the TCP buffer is empty. It will write up to 4KB at a time. My code is slightly different in that it does multiple reads from the socket until it fills the file buffer, and then it does the write. While that should improve performance by making for larger write sizes, it might also prevent the code from polling for the next packet for a few more milliseconds. That kind of subtle difference matters a lot on a faster machine.

mbbrutman wrote on 2026-06-29, 04:21:

Another request - can you send me a trace of FTP4DOS transferring the same file?

Attached.

Are you on a real machine or a virtual machine?

Real - described in the original post.

Do you have any power saving TSRs loaded?

No.

Meanwhile, the benchmark for various combinations of FTP_TCP_BUFFER and FTP_FILE_BUFFER is running, please wait...

Here you are - my quick and dirty benchmark, and the results, with the unimportant stuff filtered out...

Looks like it's best to leave FTP_TCP_BUFFER at default, and set FTP_FILE_BUFFER 2048.

I've fixed FTP_FILE_BUFFER at 2048, and downloaded a larger file - the max speed is at FTP_TCP_BUFFER 10240, but only slightly better than at the default FTP_TCP_BUFFER 8192.

Updating the screen does slow down the transfer a lot:

ftp ... < response.txt
3332 KB/s

ftp ... < response.txt > log.txt
5425 KB/s

...but that's definitely not the main problem here.

Ok, so you have confirmed that flow control related to buffer sizes and file writes is what is causing the difference. I'll look at your data and make some notes in the documentation about how to set better buffer sizes. Based on your data, the rules of thumb for faster machines are very different from those for slower machines. I'll also do something about the progress update, possibly making it time based (1 second) instead of KB based.

And 5400+ KB/sec is quite a difference from where you started ...

Mike

Yeah, the Packet Driver isn't bad at all when you know how to use it!

MTU 1500
FTP_FILE_BUFFER 2048
everything else default

ftp ... < response.txt > log.txt

PD by Seth Simon: 5425
NDIS+DIS_PKT: 5395
ODI+ODIPKT: 5395

This thread piqued my interest...

The e100pkt.com packet driver (v0.3) by Seth Simon is actually pretty efficiently coded in general so I was surprised to see that it copies packet data using 'rep movsb'. Not 'rep movsd' or even 'rep movsw' as I would have expected for a driver made for 386+ hardware.

So I've done a few very minor tweaks (optimizations) to it and since I don't have the hardware myself I can't test my changes. Grzyb, would you mind testing if this works and benchmark it? If it works and is an actual improvement I'll notify Seth.

_Krille_ wrote on 2026-08-26, 20:38:

Grzyb, would you mind testing if this works and benchmark it?

MTU 1500
FTP_FILE_BUFFER 2048

ftp 192.168.0.2 < response > log

response:

1anonymous
2password
3cd download
4get test1g.zip nul
5get test1g.zip nul
6get test1g.zip nul
7get test1g.zip
8get test1g.zip
9get test1g.zip
10cd ../upload
11put test1g.zip 1
12put test1g.zip 2
13put test1g.zip 3
14bye

The original PD by Seth Simon:

11000000170 bytes received in 85.415 seconds (11488.995 KBytes/sec)
21000000170 bytes received in 85.030 seconds (11488.995 KBytes/sec)
31000000170 bytes received in 85.030 seconds (11488.995 KBytes/sec)
41000000170 bytes received in 177.540 seconds (5517.310 KBytes/sec)
51000000170 bytes received in 178.365 seconds (5486.314 KBytes/sec)
61000000170 bytes received in 179.795 seconds (5455.673 KBytes/sec)
71000000170 bytes sent in 183.975 seconds (5336.417 KBytes/sec)
81000000170 bytes sent in 184.580 seconds (5307.415 KBytes/sec)
91000000170 bytes sent in 183.920 seconds (5336.417 KBytes/sec)

The version modified by _Krille_:

11000000170 bytes received in 85.085 seconds (11488.995 KBytes/sec)
21000000170 bytes received in 85.030 seconds (11488.995 KBytes/sec)
31000000170 bytes received in 85.030 seconds (11488.995 KBytes/sec)
41000000170 bytes received in 176.825 seconds (5548.667 KBytes/sec)
51000000170 bytes received in 177.925 seconds (5517.310 KBytes/sec)
61000000170 bytes received in 177.980 seconds (5517.310 KBytes/sec)
71000000170 bytes sent in 183.920 seconds (5336.417 KBytes/sec)
81000000170 bytes sent in 183.920 seconds (5336.417 KBytes/sec)
91000000170 bytes sent in 183.920 seconds (5336.417 KBytes/sec)

Sorry, but the original version is already good enough to either saturate the 100 Mbps Ethernet, or hit the HDD limits...

After posting that I made a slightly better version. But yes, if it's not bottlenecked by the CPU I guess it won't make much of a difference. I suppose your Pentium III is just too fast. Makes me wonder how much of a difference it would make on the slowest CPU:s (486? Pentium?) though.

The problem was clearly visible with default FTP_FILE_BUFFER - let's see if the new driver can alleviate it...

MTU 1500
everything else default

grep -a -E 'driver|KBytes' LOG

1 �                      E100PKT 0.3, packet driver for DOS                    �
2100000174 bytes received in 8.855 seconds (11097.328 KBytes/sec)
3100000174 bytes received in 8.470 seconds (11625.782 KBytes/sec)
4100000174 bytes received in 8.470 seconds (11625.782 KBytes/sec)
5100000174 bytes received in 451.385 seconds (216.398 KBytes/sec)
6100000174 bytes received in 449.350 seconds (217.360 KBytes/sec)
7100000174 bytes received in 448.250 seconds (217.907 KBytes/sec)
8100000174 bytes sent in 19.305 seconds (5059.940 KBytes/sec)
9100000174 bytes sent in 19.030 seconds (5139.831 KBytes/sec)
10100000174 bytes sent in 19.415 seconds (5033.856 KBytes/sec)
11 �                      E100PKT 0.3b, packet driver for DOS                   �
12100000174 bytes received in 8.470 seconds (11625.782 KBytes/sec)
13100000174 bytes received in 8.470 seconds (11625.782 KBytes/sec)
14100000174 bytes received in 8.470 seconds (11625.782 KBytes/sec)
15100000174 bytes received in 449.570 seconds (217.261 KBytes/sec)
16100000174 bytes received in 452.045 seconds (216.055 KBytes/sec)
17100000174 bytes received in 453.585 seconds (215.347 KBytes/sec)
18100000174 bytes sent in 18.810 seconds (5194.502 KBytes/sec)
19100000174 bytes sent in 19.085 seconds (5139.831 KBytes/sec)
20100000174 bytes sent in 19.085 seconds (5139.831 KBytes/sec)

No, it still needs non-standard FTP_FILE_BUFFER.

Thanks for testing and benchmarking Grzyb!

Though it needs to be benchmarked on the slowest possible CPU to really be able to conclude whether it's an improvement or not. I hope someone with a 486 or Pentium is able to do some testing.

_Krille_ wrote on 2026-08-28, 10:33:

Though it needs to be benchmarked on the slowest possible CPU to really be able to conclude whether it's an improvement or not.

I can only disable L1 and L2 cache...

MTU 1500
FTP_FILE_BUFFER 2048

1 �                      E100PKT 0.3, packet driver for DOS                    �
2100000174 bytes received in 99.385 seconds (983.459 KBytes/sec)
3100000174 bytes received in 95.700 seconds (1020.453 KBytes/sec)
4100000174 bytes received in 96.855 seconds (1008.867 KBytes/sec)
5100000174 bytes received in 136.895 seconds (713.883 KBytes/sec)
6100000174 bytes received in 136.455 seconds (715.979 KBytes/sec)
7100000174 bytes received in 136.510 seconds (715.442 KBytes/sec)
8100000174 bytes sent in 118.470 seconds (824.820 KBytes/sec)
9100000174 bytes sent in 118.910 seconds (821.340 KBytes/sec)
10100000174 bytes sent in 116.820 seconds (836.101 KBytes/sec)
11 �                      E100PKT 0.3b, packet driver for DOS                   �
12100000174 bytes received in 88.110 seconds (1108.483 KBytes/sec)
13100000174 bytes received in 89.650 seconds (1089.937 KBytes/sec)
14100000174 bytes received in 89.210 seconds (1094.822 KBytes/sec)
15100000174 bytes received in 129.690 seconds (753.534 KBytes/sec)
16100000174 bytes received in 127.435 seconds (766.546 KBytes/sec)
17100000174 bytes received in 127.710 seconds (764.750 KBytes/sec)
18100000174 bytes sent in 118.965 seconds (821.340 KBytes/sec)
19100000174 bytes sent in 118.580 seconds (824.107 KBytes/sec)
20100000174 bytes sent in 118.305 seconds (825.510 KBytes/sec)

Receiving got slightly better.

Thanks for testing! It's nice to have confirmation that it is an improvement on slower machines where the CPU is the bottleneck. 😀