Messages in this thread | | | From | Tony Scholes <> | Subject | RE: 2.2.5 kernel & TCP/IP Terminal Server problem | Date | Fri, 24 Sep 1999 20:37:18 +0200 |
| |
On Friday, September 17, 1999 5:11 PM, Alan Cox [SMTP:alan@lxorguk.ukuu.org.uk] wrote:
Alan
Sorry for the delay in responding, been out and about and its taken a while to speak to a user on a site where the problem is evident, please excuse me..
> > When the users telnet to a RH 6.0 system (2.2.5 kernel out of the box) the > > screens refresh poorly, i.e. sluggish and pausy, may take 3-5 secs to draw > > one > > 80x25 screen (terminals run at 19200 generally, and are up to it, so little > > > > more than a second is normal.... > > I need a tcpdump of a session to judge this. There are two probable causes > since 2.0 is ok >
I have attached a tcpdump, but it's not a sophisticated one, it's produced by 'tcpdump host thames and host spider1', 'thames' being the RH 6.0 server and 'spider1' the Shiva Terminal Server.... I've looked at it but not being a TCP/IP expert (yet :^)) can't see much.... I guess you would like something more specfic and/or detailed, please let me know what and I'll happily do it...
> 1. The spiderports don't handle SACK and are confused by the offers
I Tried disabling SACK by 'echo "0" > /proc/sys/net/ipv4/tcp_sack', seemed to make no difference... I say 'seemed' because I was remote to the site and the way I tested was to have a guy on site sit there on a terminal doing his stuff, and tell me what it felt like, his feedback was 'vague' shall we say (well it seems faster but I'm sure it's not, oh yes, maybe it isn't now etc. etc wibbble, wibble....) Also, I'm not sure whether changing this is dynamic i.e. should the above have an imediate effect, or is it necessary to establish a connection after the mod, or (surely not) reboot.... I tried getting the guy to relogin after each change and note the differences, still too vague to be of much use
Tried a variety of other stuff too, including disabling tcp_timestamps, did it in the usual methodical fashion, one change at a time, see what's different, but nothing seemed to be the magic bullet. Tempering all this is the lack of useful feedback obtained from Mr Vague...
> 2. The spiderports don't handle the way Linux deals with small window > offers and retransmits. PC/TCP has a horrible bug there and the > results sound similar. >
Flicking through the tcpdump, this looks to me like it's possible, but then again, I know nothing and I'm about to sit down with a nice cup of tea, a printout of the tcpdump man page, and see if I can learn something...
> Alan >
In order to circumvent vagueness, I'll be at one of the ofending sites Mon, Tue, Wed and will hopefully be able to be more objective about results then
Ta
-- Tony Scholes Technical Manager ================================================= Beacon Computer Services Tel: +44 (0)1582 478888 The Friars, 82 High Street South Fax: +44 (0)1582 478810 Dunstable, Beds. UK Email: tonys@beacon.co.uk LU6 3HD Compuserve: 72660,207 =================================================
[unhandled content-type:application/octet-stream] | |