seligman@polya.Stanford.EDU (Scott Seligman) (08/24/89)
We're been having a problem using rlogin from our HP9000/350's running HP/UX 6.5. It seems that our net is losing the occasional packet here and there. Shouldn't be any big deal since they get retransmitted, but the retransmission timeout is set unreasonably high -- somewhere on the order of 2 seconds. So I'll be typing along and suddenly the characters I'm typing stop echoing to the screen. I continue to type, and a couple of seconds later there's a quick burst of activity and the echoing catches up to where it should be. Everything works fine for another minute or so (depending on the load on the net), and then it happens again. Annoying. So, is there any way to correct this? Some parameter I can set somewhere? Isn't the timeout supposed to be set using an adaptive algorithm? The normal roundtrip time for a packet is on the order of milliseconds. tnx, Scott seligman@cs.stanford.edu ...!decwrl!polya.stanford.edu!seligman
accu@hpuepta.UUCP (Accugraph Corp) (08/25/89)
I am also experiencing this problem on my 340 using 6.5 running remote X Clients (e.g. hpterms on RS20 running an X Server). I was told by the developer of the PC X Server that it is typical for BSD based networking systems to timeout for approx. 2 seconds before retransmitting after an error. This is a REAL pain in an interactive application. Is there some technical reason why this parameter is not tuneable? (I know you ca'n't tune a fish). Philip Webster hplabs!hpuepta!acgrph!pw
timg@hpurvmc.HP.COM ( Tim Gill (NSE) ) (08/26/89)
The TCP timer is fixed at 3.0 seconds in pre-7.0 HP-UX. This will change to the adaptive mode in the 7.0 release. On the RS20, if you have the 3Com Lan card then the problem here is due to the 1-packet buffer limit on the card. If back-to-back packets arrive and the cpu is busy, the second gets dropped,and 3 seconds later the timer pops. New card in the works for thinlan & a new card for Starlan 10 exists that has more buffering. Tim Gill