Full duplex vs Half duplex

[Darrell Allen]

Hi all,

I had a discussion with a networking / WAN support engineer today. Basically he said full duplex doesn't provide the performance gain one might expect over half duplex. He continued that the application would have to be written to utilize full duplex to benefit from it and that ftp and telnet aren't.

Can anyone shed some light on this?

Thanks,
Darrell

[A. Clay Stephenson · Accepted solution]

Hi Darrell:

In a nutshell, he's right.

The gains of full duplex only really occur when several processes are reading and writing at the same time and for fairly long periods.

I suppose you could contrive a case by running two ftp's - one sending and the other receiving. In any case, the actual gains depend upon the design of the card and the driver overhead.

In the rare case where data is always going in both directions then full-duplex wins but even in that case a 25% increase in throughput is about the limit - in most cases full-duplex is not worth the extra CPU/driver overhead.

Bear in mind, that most (nearly all) applications send something then wait for a response and send some more stuff - 'half-duplex' at the software level. Very rarely does the application perform tasks that will benefit from full-duplex.

I suggest that you try some experiments yourself and measure the results. I think that you will find that (except for the contrived two FTP's outlined above) the half-duplex setting wins. The other case might be an NFS server when a great deal of simultaneous reading and writing is occurring.

Food for thought, Clay

[Sridhar Bhaskarla]

I guess he was incorrect. It's the card's ability to send and receive the data simultaneously and is part of tcp/ip stack working at the physical layer.

I did have a situation where our ftp transfers slowed down due AUTO_ON on the switch and on the server and both negotiated to half-duplex. The problem got fixed after we moved to full duplex.

-Sri

[Roger Baptiste]

hi,

Yeah, i have read about this somewhere. But, testing it practically, i found FTP on a Fullduplex faster than on Halfduplex.

-raj

[Sridhar Bhaskarla]

Well. Let's try to dig further to see why Full Duplex is faster practically. when the ftp session is started, the source fragments the data into frames and puts it on the wire (send). The receiver receives the frames and should "send" the acknowledgements. Depending on the Window size, the source may wait till it gets the acknowledgement before it can further transmit the data.

Now with full duplex, this is not an issue as the receive and send are done simultaneously so that the source doesn't have to wait for the acknowledgements as they are sent parallelly without "stopping" the receipt of the ftp datagrams. I see this as a continuous pipes of receive and send-ack at the receiver side rather than a receive-send_ack-receive-send_ack-receive fashion of a half-duplex.

I guess we can see the delay here how short the send_ack time delay is.

-Sri

[Bill Hassell]

As mentioned, to see a significant advantage in full duplex requires true simultaneous read/write on the LAN. For a simple workstation with one user, this is going to be hard to see any difference. But change this to a typical server with multiple users and LAN traffic now goes both ways a lot more. You won't see 100% increase in performance over half duplex, but the busier the LAN, the better the improvement.

One of the features of full duplex is that there are no collisions (if there are some, the duplex is mismatched) which removes some delays on a busy LAN connection.

For sanity's sake, I would keep all the connections fixed at 100 full duplex.

[Chris Vail]

This is really a question pertaining to your application. If your application does as much reading as writing, the full duplex is faster than half.

For example, my Oracle database is usually 99% read and 1% write. A half duplex connection to it is significantly faster than a full duplex one.

This is also true regardless of the protocol, whether RS-232, SCSI, TCP/IP or just about anything else. When I administered a Sun system that also had a 99/1 read/write ratio, Sun service recommended running the SCSI channels at half duplex, and drive throughput tripled when I did so.

If your system is close to 50/50 read/write ratio, then full duplex is a better option. The reason is simple: in half duplex, the sending machine has unfettered access to the communication channel. It sends the data across without waiting for acknowledgement.

Let me point out that rcp and remsh are faster than ftp and telnet. The reason is that these use UDP packets rather than TCP. These are smaller packets, and there is less error detection and correction in the protocol itself than with the TCP packets. Therefore they also use less system resources (clock cycles) than do the TCP. They also have the advantage of being able to be scripted much more easily.

I've occasionally been able to gracefully shutdown a hung/runaway system with remsh (rsh to Sun users) when logging into the console or telnetting in was impossible. This again is due to the half duplex/UDP nature of remsh. It uses few clock cycles, and hits the system more gently.


Chris