cdshaw@cs.UAlberta.CA (Chris Shaw) (12/31/90)
We've been confronting a problem with TCP/IP recently, and I'm wondering if any net people have any clues. We have a few machines ethernetted together that are sharing data back and forth using TCP. First, there are a few servers, each of which manage a device across a serial line. When a client connects to a server, the client requests data, and the server replies with the latest device info. Send-receive-reply protocol. There is a central master process which is a client of multiple servers. The master collects device data, and redraws the screen based on this data. The master does send-receive-reply with multiple servers. There is also a slave process which receives a data packet from the master, updates the slave screen, and sends back a synchronization packet to the master. In essence, two send-receive transactions, one in each direction. This works fine. The problem is that the update rate is abysmal -- 5 frames per second, and some digging has revealed that it's the synchronization step that causes the problems. In particular, the data packet that the master sends to the slave, and the sync packet that the slave sends to the master take far too long (on the order of 100 milliseconds). Now the crux of this is the unbalanced communication. In fact, we put together a little test program that just swapped packets, and the results are as follows: Case A Master | Slave write(slave) | read(master) write(slave) | read(master) read(slave) | write(master) Case B Master | Slave write(slave) | read(master) read(slave) | write(master) In Case A, where there's unequal reads and writes in the body of the loop, the loop executes at 5 iterations per second. Case B goes as much as 200 iterations per second (depending on machine speed, etc). Now, the obvious answer is "balance the packets", but it seems a waste to spend (at least) 2 packets per redraw just to fool TCP, especially since the slave machine is a 3130. So anyway, is there any way around this with TCP? What's going on? Is there an assumption of send-receive-reply within TCP that cannot be beaten? Is UDP the only way? Can anyone recommend a good book on the subject? -- Chris Shaw University of Alberta cdshaw@cs.UAlberta.ca Now with new, minty Internet flavour! CatchPhrase: Bogus as HELL !
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/01/91)
In article <1990Dec31.090634.20329@cs.UAlberta.CA>, cdshaw@cs.UAlberta.CA (Chris Shaw) writes > ... > So anyway, is there any way around this with TCP? What's going on? Is there > an assumption of send-receive-reply within TCP that cannot be beaten? > Is UDP the only way? Can anyone recommend a good book on the subject? Yes, there is an important speed hack called, I think, "the Nagle algorithm" in 4.3BSD derived TCP implementations. I think the Host Requirements RFC requires it. It can be turned off. If possible, it would be better to change your application to use more "balanced" exchanges. Check tcp(7p) and getsockopt(2) for TCP_NODELAY. Those man pages are in IRIX 3.3 on 4D's. I don't remember man pages what we shipped in 3.6 for the 3000, and I don't know how well the ioctl worked in those ancient days. Vernon Schryver, vjs@sgi.com