Telnet slower than rlogin for RF scanner

[Rob Marshall_2]

We have some scanner devices that are experiencing quite a performance impact now that we have moved from SCO to HP.

We had the guns telent to the HP and performance was "less than perfect", we have the ID's now doing a rlogin to the HP (even from the HP) and it is a fair bit better, but nowhere near what it was on the old SCO box.

ANY ideas are appreciated.

Thanks
Rob

[Chris Wilshaw · Accepted solution]

I'm guessing that his is on HP-UX 11.*

We had the same problem when we moved from 10.20 to 11.

The solution is to change /etc/inetd.conf so that the telnetd line reads;

telnet stream tcp nowait root /usr/lbin/telnetd telnetd -s400 -z5

Then run inetd -c

You should see a considerable improvement.

[harry d brown jr]

DNS issues ??

Are the "guns" telnet'ing over an ethernet network? Speed of network is? Network delay times?

live free or die
harry

[Jose Mosquera]

Hi,

Similar trouble in the past for us, we have solved modifying /etc/inetd.conf:
telnet stream tcp nowait root /usr/lbin/telnetd telnetd -z50 -TCP_DELAY

The run:
#inetd -c

Rgds.

[rick jones]

HP-UX 11 telnetd defaults to setting TCP_NODELAY on its sockets. This differes from 10.20 behaviour. It was done to give a perceived performance boost for mulit-byte character sequences that were being sent to the transport in separate sends. This would then run into interactions between the nagle algorithm and delayed ACKs (long story there).

With TCP_NODELAY set, instead of buffering-up data (first small send goes, out, the rest wait for the remote to ACK) the stuff goes-out as fast as it is given to the transport - regardless of size. So, if you had an application that was dumping data 1 byte at a time back out the telnet connection, that could become a fast stream of verysmall TCP segments that could easily overrun your RF scanners. TCP segments get dropped, things wait for retransmission timers (minimum of 500 milliseconds) slowness.

Setting -s400 on the telnetd line would tell telnetd to buffer up to 400 bytes before giving it to the transport - basically doing something somewhat like the nagle algorithm, but in the telnetd. The -z option then gives a timeout that telnetd will use for when it doesnt get up to -s bytes. (in units of 10 ms per the manpage)

The other option is to turn the Nagle algorithm back on with the (IMO) poorly named -TCP_DELAY option. In that case, if a stream of small sends happens, the first small send will go-out, the rest will buffer in TCP waiting for the remote ACK and then the remainder will be sent.

Depending on the behaviour of the stack in your RF scanners (their delayed ACK timers and ACK policies when sub-MSS (aka small) segments arrive) and the nature of the data being blasted down to them, one may be faster than the other. It will all depend.