FTP Bandwidth

[Trace Trembath]

Is there a way to limit the bandwidth consumed by FTP file transfers using TCPIP Services for OpenVMS V5.1? (OpenVMS 7.2-1). If so, how would I do it? Thanks.

[Martin P.J. Zinser]

Hi,

none that I am aware of on the host. This is a feature that can be implemented in the network though (traffic shaping or CBFWQ seem to be concepts I hear from our networkers about this).

Greetings, Martin

[Craig A Berry]

What specific problem are the FTP transfers causing you? Is the negative impact experienced by other processes on the VMS host, or other systems on the network? Which system initiates the transfers?

You can change process priorities on either the ftp client processes or the ftp server process, but that would only help if the surge in network traffic coincided with surge in CPU activity on the VMS host, and it wouldn't be very robust even if it more or less worked.

You can ratchet down the size of the ftp send and receive buffers with

$ DEFINE /SYSTEM /EXEC TCPIP$FTP_WNDSIZ nnnn

where nnnn is a size in bytes. I don't know what the default is, but try something really tiny like 256 and see if that throttles down the traffic to an acceptable level. I suppose that could actually make things worse by sending a greater number of packets even though they'd be smaller. But worth a try I'd think.

[Antoniov.]

Hi,
every change on TCP/IP suite has effect on other service too, so you can't limit ftp without limit telnet, etc.
You can indirectly set low priority level, addind $ SET PROC/PRIO=1 in LOGIN.COM of your FTP dir (usually
SYS$SYSDEVICE:[TCPIP$FTP]); but this mode hasn't a big impact.
If you server is only ftp server you can limit TCP/IP.

Bye
Antoniov

[Wim Van den Wyngaert]

TCPIP$FTP_WNDSIZ is working.

Default is 64K windows and thus the sender will transmit at high rate, the receiver will ack e.g. every 100 packets.

With 1.5K windows, speed is reduced to 50% but overhead is higher because every packet is acked.

With 0.5 windows, speed is reduced to 30% but still more overhead.

(btw : I also tested the service param /sock=(rec=xx,send=yy) with 1500 bytes and this gave no results)

[Antoniov.]

Hello Wim
good news!
Antoniov

[Wim Van den Wyngaert]

Tested with VMS 7.3 using TCP 5.3 ECO 2.

[Wim Van den Wyngaert]

Another possibility in 7.3+.

$ mc sysman class add ftp /cpu=0-23=1%
$ set proc /id=xxx /class=ftp
where xxx is the id of TCP$FTP_1
then start ftp session (make sure old ftp processes are gone)

I tried this on a Alpha station 500 and thruput was ony 25% of the normal thruput.

Of course, with (future) fast cpu's it will be difficult to implement because the cpu usage without limits I saw was about 5% (10Mbit).

[Trace Trembath]

Thanks to all who replied to my message!

The specific problem I'm trying to resolve is an FTP transfer of a large file (~225MB). Once the transfer is initiated we start getting failures to communicate between various of our OpenVMS systems. We used to transer these files using DECnet, but now we are using FTP instead. The DECnet transfers didn't cause us any problems.

Does the tcpip$ftp_wndsiz logical have to be defined on the initiating or receiving end (or both) of the FTP connection?

I have to stay with OpenVMS 7.2-1 and TCPIP V5.1 ECO 3 only.

Thank you for your help!

[Willem Grooters]

...
Once the transfer is initiated we start getting failures to communicate between various of our OpenVMS systems. We used to transer these files using DECnet, but now we are using FTP instead. The DECnet transfers didn't cause us any problems.
...

If you're tansferring files between VM Ssystems AND DECNet didn't cause problems, where TCPIPO does, my advise would be: Stick to Decnet.

Another cause of your problem might be the NIC setting. We did have severe problems with FTP only due to the fact the NIC was set to "Auto-negotiate". It isn't, you'd better avoid it (I've never seen the use for it for non-chnaging network connections). Set NIC and switch to 100Mb, Full duplex, switch to half-duplex if that causes problems as well.

[Wim Van den Wyngaert]

Could you communicate the error message FTP gave ? If possible, also a tcptrace (at least the 20 last packets exchanged).

Is there a firewall in place ?

There is no reason why FTP shouldn't work, whatever the window size.

We are using ftp to transfer files of 1GB and more.

[Martin P.J. Zinser]

I do assume here that the failiures you see are with other protocols (like cluster communication) while the FTP transfer runs. One way to secure these is to add an additional network interface to the systems in question and bind IP to one of the interfaces and the other protocols to the other one.

Greetings, Martin

[Trace Trembath]

Thanks again to everyone for their responses.
After more research, I think the problem we are having lies with the CISCO routers. We should be using the "Weighted Fair Queueing" option, but I don't think we are.
Anyway, I will be pursuing the problem through router settings.
Thanks to all!

[Martin P.J. Zinser · Accepted solution]

Hello Trace,

this is certainly the best. We use CBWFQ (Class based weighted fair queing) on WAN lines to make sure FTP transfers do no bog down our transactional workload.. It does take some effort to setup from what I've gathered, but seems to work fine once in place.

Greetings, Martin