Geof Cooper (imagen!geof@decwrl.DEC.COM)
Mon, 28 Jul 86 09:39:11 pdt
There is a bug that affects throughput in IMAGEN's V2.1 and V2.2
TCP software. For people who are familiar with TCP-IP, the bug is
explained below. The bug limits throughput to 32 Kbits/s when the
sending TCP's buffer space is less than 6144 bytes. This is the case,
by default, for BSD 4.2 UNIX systems (including SUN's). The bug
is fixed in IMAGEN's release V3.3 software, which is now in beta
32 Kbits/s is sufficient throughput for most documents, since the printer
processes most data no faster than this. Bitmap data is the exception
(especially when using language bitarray but also when using IMPRESS),
since the image processor would process this data faster if it were
received faster. TCP sites may improve throughput for bitmap data by
increasing the amount of "send" buffer space to be >= 6144 bytes.
UNIX sites can accomplish this without resort to sources, by patching
the UNIX kernel to set the variable "tcp_sendspace" to be 6144:
# adb -w /vmunix /dev/kmem
tcp_sendspace: 0x800 = 0x1800
This patches the in-memory copy of UNIX (the one that is running now).
The same patch, with a question mark instead of a slash (tcp_sendspace?W)
will alter the bootable binary, causing the patch to be automatically
installed every time the system is rebooted.
The effect of the patch is to increase the buffer space reserved
for outgoing data for every TCP connection to be 6144 bytes. It
is not possible to change this parameter for specific connections,
so the global limit must be changed. The impact on the system is to
reserve 4KB more memory per connection, so the memory requirements
of the UNIX kernel will rise slightly. [Somewhat improved throughput
between UNIX systems can be achieved by also setting the kernel
variable tcp_recvspace to be 6144 for both cooperating systems. I
have not measured the speed improvement in this case].
Explanation of bug:
The IMAGEN TCP software is an "upcall" implementation, such that there are
no per-connection packet queues. Each packet is individually and
fully processed as it is received. When a packet containing data is
received, the software sets a flag to generate an ACK. If the packet
consumes more than a particular percentage of the offered window,
the ACK is sent immediately. Otherwise, there might be another packet
waiting to be processed at the network interface, so the ACK is withheld
to allow additional packets to share the same ACK. A timer is set for a
short delay (1/2 a second), after which the ACK is sent anyway.
The bug occurs when the amount of buffer space for that the sending
TCP has reserved for outgoing data, say N bytes, is much less than
the offered window, say M bytes. In this case the "short delay" lasts
its full duration after each burst of N bytes. The throughput of the
connection is thus very close to N/.5 or 2N bytes per second, since
the time to actually transmit the data is dominated by the "pregnant pause"
waiting for the printer's timer to expire. In the case of a BSD4.2 system,
the default for tcp_sendspace is N=2048, so the throughput is close to
4 Kbytes or 32 Kbits/second.
The fix is to increase the sender's buffer space such that the send buffer
space is as great as the offered window (N >= M). This ensures that the
printer will send an ACK when it receives all the data the host is able to
As mentioned above, the bug is fixed in IMAGEN's V3.3 software.
- Geof Cooper
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:34 GMT