wireless devices slow after upgrade to 11.00

[tm25]

Hi

To upgrade our 10.20 servers, we have performed a clean install of 11.00

We use wireless hand-held devices, and the users have noticed there is now a 4-5 second delay after each transmission.

It is just these hand-held devices which are affected. All other users eg. va hummingbird terminals, are all OK.

Would anybody have any idea if I have missed some network setting which would cause this?

Thanks

[Bill Hassell]

11.0 has a number of new network settings but you'll need to provide more details. Are the wireless devices connected via LAN or serial connections? Does the delay occurinside HP=UX or is it occurring in routers or firewalls (you'll need a network sniffer to identify this). You may need to review the source code for constructs in handling sockets that are not recommended.

[tm25]

Hi

Thanks for the reply.

The devices connect using the lan via IP.
They worked fine under 10.20.
I'll get the network guys to see if they can see anything from their side.

Also, I'm not sure what you mean in your last sentence. What source code would I need to look at?

[Bill Hassell]

Unless the wireless devices are terminal lookalikes and users login via the devices using telnet, there is likely some application program that talks to the devices using socket programming and this is likely the source of the delays.

[TMcB]

Yep - they are used via telnet like a terminal.

[Bill Hassell]

How about 'real' telnet sessions? Hummingbird is an Xwindows systems and there are a number of ways to connect. Starting an xterm or dtterm window is not a telnet session at all, it is an application program running on the target machine with the fonts and decorations sent over the network using Xwindows protocol.

Login using telnet from another machine using the the same user ID and protocol as the wireless devices and see if normal commands are responding correctly. Then try the wireless programs (I am assuming that these wireless devices are not laptops but specialized handlheld data capture devices) to see where the delays creep in.

[Duncan Edmonstone · Accepted solution]

IIRC some issues with wireless devices could be resolved by changing the default behaviour of telnetd from TCP_NODELAY to TCP_DELAY.

The problem with TCP_NODELAY is that this can generate large amounts of small packets (not particularly good with wireless). TCP_DELAY loads up the packets before sending them out... anyway give it a try, change the telnetd line in /etc/inetd.conf from:

telnet stream tcp nowait root /etc/telnetd telnetd

to

telnet stream tcp nowait root /etc/telnetd telnetd -TCP_DELAY

and then issue inetd -c to reread the config.

HTH

Duncan

[rick jones]

If the wireless devices are now being overrun with small packets thanks to the default in HP-UX 11 telnetd to set TCP_NODELAY then the netstat -p tcp statistics should show a number of TCP retransmissions - and if the delays are on the order of 4-5 seconds, most of those retransmissions would likely be timeout based.

Now, one might also want to consider the applications being run to see why they would be spitting-out their output in such aparantly small parts.

Another thing to consider checking for the networking would be a tcpdump trace. For the application behaviour, perhaps a tusc trace.

[tm25]

Duncan

I can't thank you enough for your reply.

I was just about to restore back to 10.20 when I seen your post about tcp_delay.
Configuring this in inetd.conf immediately resolved our problem, so thank you for taking the time to reply.

I had a look at this file on 10.20 and this parameter was not used in our old inetd.conf file. Is is particular to 11.00?

[Duncan Edmonstone]

The TCP/IP stack was completely re-engineered in 11.00, so its not surprising that you had no problem in 10.20.

Glad your problem is solved!

Regards

Duncan

[rick jones]

IIRC (and this goes back a long way - 11.0 is now 6 years old...hint hint...) these "sense" of the default used by telnet changed between 10.20 and 11.0. By default 10.20 telnetd didn't set TCP_NODELAY (at least not unpatched), but for a reason that is lost to me now, 11.0 telnetd did start setting TCP_NODELAY. I guess someone had some poorly written apps that it was thought would be "fixed" by disabling Nagle. Alas...