paulh@cimage.com (Paul Haas) (02/13/91)
Our application tends to spend too much time talking to the X server. We spend many minutes moving large images between the server and the client. A trace of the client reveals the following repeated thousands of times: ---------Cut here--------- writev (4, 0xf7ffead8, 1) = 4096 writev (4, 0xf7ffead8, 1) = -1 EWOULDBLOCK (Operation would block) select (5, 0xf7ffea68, 0xf7ffea60, 0, 0) = 1 ---------Cut here--------- On a Sun, Sparcstation 1+, running Sun OS 4.1.1 is it possible to increase the size of the IPC buffer? The client and server are on the same host, so shared memory would work, if anyone has implimented it. Our long term solution is to store the large images only on the client, and only send things to display to the server. So I'm looking for a quick and easy short term solution. Many thanks. --------------------------------------------------------- Paul Haas paulh@cimage.com +1-313-761-7478
randy@erik.UUCP (Randy Brown) (02/14/91)
From: uunet!cimage.com!paulh (Paul Haas) Organization: Cimage Corp, Ann Arbor, MI Our application tends to spend too much time talking to the X server. We spend many minutes moving large images between the server and the client. This is an ideal application for the MITSHM extension. You can put a pixmap (drawable) in shared memory, render on it with the server, operate on it with the client, and display it with a simple XCopyArea(), with no actual transmission of the image data required. Both the MIT X11R4 server for Sun and Sun's OpenWindows server include this extension. ... rb
jeffv@bisco.kodak.com (Jeff Van Epps) (02/19/91)
In article <1991Feb13.012043.1592@cimage.com> paulh@cimage.com (Paul Haas) writes: > On a Sun, Sparcstation 1+, running Sun OS 4.1.1 is it possible to > increase the size of the IPC buffer? The answer to this specific question is "yes". I don't know whether or not it will help you with X communications though. I work on exactly the same setup, and it was just last Friday that I found the answer in Stevens' _UNIX Network Programming_ (an excellent book!). It works on my setup and does increase performance somewhere around 10%. SendBufferSize = 32768; /* size in bytes */ if ( setsockopt( fd, SOL_SOCKET, SO_SNDBUF, (char *) &SendBufferSize, sizeof( SendBufferSize ) ) < 0 ) { error... } According to the book, the maximum buffer size is 52,000. I haven't tried more than 50,000. You can also change the size of the receive buffer. From the description of your application, I would guess that you would need a more effective solution than this. -- If the From: line says nobody@kodak.com, don't believe it. Jeff Van Epps jeffv@bisco.kodak.com rochester!kodak!bisco!jeffv
jg@crl.dec.com (Jim Gettys) (02/19/91)
There are a number of buffers involved. One of them is in Xlib, and is (currently) hardwired in size. It might make sense to make it the same size as the socket buffer. There is a compile time constant in Xlib currently that determines the buffer size. And there are socket buffers on either side of the connection (Xlib and X server). No one has looked into the performance tradeoffs of socket buffers vs. library buffers since X version 6 days (when I last did some...)! I encourage someone to do some careful performance work. Note there is a tradeoff here; you don't want to make all buffers arbitrarily large; otherwise bad things happen when you want to kill off applications, not to mention wasting memory. Basically, you want the buffers big enough that context switching, etc. is not a significant component of time used by both client and server. But I suspect somewhat larger buffers would probably be a win these days; X version 6 was before the Berkeley TCP implementation piggybacked ack's, and having more packets go out before an ack is necessary would probably be a win on the net. But I have no data to back this guesstimate up.... - Jim