chris@Solbourne.COM (Chris Horne) (01/23/91)
A customer of ours noticed something curious with rcp (tcp) performance using OS/MP4.1, our derivative of SunOS 4.1. He was monitoring the ethernet with a sniffer. If the same rcp was repeated twice in a row (quickly) he noticed that the first rcp used large packets, and subsequent ones used small packets. We were able to reproduce the problem between two sun machines running SunOS 4.1. We have traced the problem down to the way the kernel routine netinet/tcp_input.c<tcp_input> deals with "options" when a new connection request is received in TCPS_TIME_WAIT state. What happens is that the "options" get applied to the old connection and freed, the need for a new connection is recognized, the old connection is closed, the new connection is established but the options have been freed and don't get applied. As a result we end up using the default t_maxseg that was assigned in tcp_newtcpcb (512). For those of you with SunOS source (or BSD 4.3 source) look at the handling of the variable "om" in tcp_input, with particular attention to what happens when "goto findpcb" occurs when the packet had options (to set maxseg). My inclination is to resolve this by: o removing the "om = 0" after all calls to tcp_dooptions. o removing the "(void) m_free(om);" from tcp_dooptions to leave the mbuf containing the options around for further processing. and making sure that all returns from tcp_input have a "if (om) m_free(om);". I am not a tcp guru... Is this a well understood problem? Is the problem really on the input side? Is there another patch that is available? Thank you very much for your support.. -- | Christopher Horne, MTS OS Group | UUNET: chris@Solbourne.COM | DDD: (303)678-4320 or (303)772-3400 x320 | FAX: (303)678-4716 | USPS: Solbourne Computer, Inc., 1900 Pike Rd, Longmont Co, 80501 -- -- | Christopher Horne, MTS OS Group | UUNET: chris@Solbourne.COM | DDD: (303)678-4320 or (303)772-3400 x320