Subject: Re: NetBSD -current, super lags with ssh
To: Brian McEwen <bmcewen@comcast.net>
From: Andy Ruhl <acruhl@gmail.com>
List: netbsd-users
Date: 07/08/2005 06:32:10
On 7/6/05, Brian McEwen <bmcewen@comcast.net> wrote:
>=20
>=20
> Hi all;
>=20
> I just put -current  (July 3) on my Cobalt Qube 2 using a netboot CD
> (these boxes have no CD drive).
>=20
> Everything went great, it was a clean install onto a new HD, I have
> my old 1.6.1 that's a tiny bit mangled to fall back upon if need be.
>=20
> I have one issue so far, that is just killing the box- I can telnet
> in fine and the system is super responsive, but any ssh connections
> are lagged to the point of being unuseable.  for exmaple, 45 seconds
> to ls /usr/pkgsrc/www.  Same with sftp file transfers.
>=20
> I've updated sshd and openssl to the latest versions.
>=20
> telnet through LAN or WAN is snappy.  ssh thru LAN side is fine.
>=20
> file downloads from netbsd.org go super fast (thru WAN of course).
>=20
> file transfers within the LAN (sftp user@192.168.0.5) go super fast.
>=20
> file transfers from the WAN side (sftp user@host.domain) go at 2kb/
> second (that's lower case b) or less.  The qube is a headless box,
> all transfers are coming from other CPUs in the LAN.
>=20
> I've swapped cables but that doesn't help, and if it were a bad cable
> I'd expect slow transfers everywhere, and telnet not to work well,
> since telnet doesn't do well with packet loss at all.
>=20
> I've got UseDNS no    set.
>=20
> I've turned PAM off just in case, it was performing strangely for me
> under 1.6.1.
>=20
> I'm connecting from OS/X terminal, and have tried setting my termcap
> to xterm, xterm-color, and vt100, in case it was something with the
> term choice.
>=20
> I'm stumped!
>=20
> This is using a Netgear MR814v2 router, I've changed from my old
> Netgear MR314 as the MR314 could not disable remote admin, people
> were always trying to telnet into it.    Throughput for everything
> else and other CPUs in the house  is super fast; it seems unlikely to
> be the router or cabling to me.
>=20
> I guess I can download all the 2.0.2 release stuff and try that.
> But, others are using -current on this CPU family just fine, apparently.
>=20
> I haven't tried building my own kernel, but I don't have any constant
> messages about my SCSI card as I did in 1.6.1.
>=20
> Thoughts welcome.  I would especially appreciate ideas on system
> stats to look at, to tell me WHERE the lag is coming from.
>=20
> thanks,
>=20
> Brian
>=20
> ----------------------------------
> qube# uname -r
> 3.99.7
> qube#
>=20
>=20
> ----------------------------------
> qube# dmesg
> aide0 channel 0
> viaide0: secondary channel configured to compatibility mode
> viaide0: secondary channel interrupting at irq 15
> atabus1 at viaide0 channel 1
> VIA Technologies VT83C572 USB Controller (USB serial bus, revision
> 0x02) at pci0 dev 9 function 2 not configured
> ahc0 at pci0 dev 10 function 0: Adaptec 2940 Ultra SCSI adapter
> ahc0: interrupting at irq 9
> ahc0: aic7880: Ultra Single Channel A, SCSI Id=3D7, 16/253 SCBs
> scsibus0 at ahc0: 8 targets, 8 luns per target
> tlp1 at pci0 dev 12 function 0: DECchip 21143 Ethernet, pass 4.1
> tlp1: interrupting at level 2
> tlp1: Ethernet address 00:10:e0:01:36:d1
> lxtphy1 at tlp1 phy 1: LXT970 10/100 media interface, rev. 3
> lxtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> Kernelized RAIDframe activated
> scsibus0: waiting 2 seconds for devices to settle...
> wd0 at atabus0 drive 0: <Maxtor 6Y060L0>
> wd0: drive supports 16-sector PIO transfers, LBA addressing
> wd0: 58644 MB, 119150 cyl, 16 head, 63 sec, 512 bytes/sect x
> 120103200 sectors
> wd0: 32-bit data port
> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33)
> (using DMA)
> boot device: wd0
> root on wd0a dumps on wd0b
> root file system type: ffs
> syncing disks... done
> unmounting file systems... done
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
>      The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>      The Regents of the University of California.  All rights reserved.
>=20
> NetBSD 3.99.7 (GENERIC) #0: Sun Jul  3 11:00:03 CEST 2005
>          root@netbsd20.diskless.s-zone.org:/Data/NetBSD/cobalt/obj/
> sys/arch/cobalt/compile/GENERIC
> total memory =3D 128 MB
> avail memory =3D 122 MB
> mainbus0 (root)
> com0 at mainbus0 addr 0x1c800000 level 3: st16650a, working fifo
> com0: console
> cpu0 at mainbus0: QED RM5200 CPU (0x28a0) Rev. 10.0 with built-in FPU
> Rev. 10.0
> cpu0: 32KB/32B 2-way set-associative L1 Instruction cache, 48 TLB
> entries
> cpu0: 32KB/32B 2-way set-associative write-back L1 Data cache
> panel0 at mainbus0 addr 0x1f000000
> gt0 at mainbus0 addr 0x14000000
> pci0 at gt0
> pci0: i/o space, memory space enabled, rd/line, wr/inv ok
> pchb0 at pci0 dev 0 function 0: Galileo GT-64111 System Controller,
> rev 1
> tlp0 at pci0 dev 7 function 0: DECchip 21143 Ethernet, pass 4.1
> tlp0: interrupting at level 1
> tlp0: Ethernet address 00:10:e0:01:36:ca
> lxtphy0 at tlp0 phy 1: LXT970 10/100 media interface, rev. 3
> lxtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> pcib0 at pci0 dev 9 function 0
> pcib0: VIA Technologies VT82C586 PCI-ISA Bridge, rev 39
> viaide0 at pci0 dev 9 function 1
> viaide0: VIA Technologies VT82C586 (Apollo VP) ATA33 controller
> viaide0: bus-master DMA support present
> viaide0: primary channel configured to compatibility mode
> viaide0: primary channel interrupting at irq 14
> atabus0 at viaide0 channel 0
> viaide0: secondary channel configured to compatibility mode
> viaide0: secondary channel interrupting at irq 15
> atabus1 at viaide0 channel 1
> VIA Technologies VT83C572 USB Controller (USB serial bus, revision
> 0x02) at pci0 dev 9 function 2 not configured
> ahc0 at pci0 dev 10 function 0: Adaptec 2940 Ultra SCSI adapter
> ahc0: interrupting at irq 9
> ahc0: aic7880: Ultra Single Channel A, SCSI Id=3D7, 16/253 SCBs
> scsibus0 at ahc0: 8 targets, 8 luns per target
> tlp1 at pci0 dev 12 function 0: DECchip 21143 Ethernet, pass 4.1
> tlp1: interrupting at level 2
> tlp1: Ethernet address 00:10:e0:01:36:d1
> lxtphy1 at tlp1 phy 1: LXT970 10/100 media interface, rev. 3
> lxtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> Kernelized RAIDframe activated
> scsibus0: waiting 2 seconds for devices to settle...
> wd0 at atabus0 drive 0: <Maxtor 6Y060L0>
> wd0: drive supports 16-sector PIO transfers, LBA addressing
> wd0: 58644 MB, 119150 cyl, 16 head, 63 sec, 512 bytes/sect x
> 120103200 sectors
> wd0: 32-bit data port
> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33)
> (using DMA)
> boot device: wd0
> root on wd0a dumps on wd0b
> root file system type: ffs
> qube#
> ------------------------------------------------

The only reasonable explanation is some sort of network problem, like
maybe your DNS isn't set like you believe it is? Did you try adding
hosts entries for the heck of it?

If possible, I'd watch tcpdump or a system call trace from another
window while that bad stuff is going on.

Andy