Larry Irwin wrote:
All i/o is either normal (i.e. almost immediate) or frozen for a while.
Frozen for a while could mean that the Debian box is busy doing other things, or an underlying network problem that's showing up as a loss of individual packets... then SSH (TCP actually) has to re-send... etc.
I'd look in the ifconfig stats for collisions, etc... and also on the upstream switches/routers. I'd look for collisions on the port on the upstream device the Debian boxes are plugged into or something similar... misconfigured duplex, CRC errors (bad cable), etc.
Additionally if you're coming in from the Internet, make sure your MTU sizes are all correct. Are you using a VPN? Many machines using VPN's are misconfigured to use larger packets than the VPN packet can actually hold... usually this is "okay" since the packets just get fragmented, but you could have a firewall or other device trying to unfragment the packets and it's running out of resources to do it. The SCO box *might* be using a smaller window size and/or MTU.
There's just so many possibilities to check with the symptoms you've described, it's mind-boggling.
Lack of enough RAM for whatever task the Debian boxes are doing is a common cause of "thrashing" and heavy I/O also. You could watch iostat output and see if I/O to the disks coincides with the "lock ups". Perhaps the SCO machine is doing less disk buffering and therefore feels always more interactive than the Debian machines do when they decide to swap out data to hard disk... hard to say.
But... if the Debian boxes are doing heavy I/O, they may just feel "slow". The 2.6 kernel is supposed to seem more "interactive" but never has felt that way to me... when my 2.6 boxes get busy, I know it... remote sessions get jerky.
But I have to get the boxes either maxed out on CPU (hard to do these days) or maxed out on I/O and/or lots of interrupts (I/O to an interrupt driven device like a serial USB cable, or well, really just about anything).
Ah well, hopefully that gives you some ideas. I'm stuck most days working on a customer's network over a dial-up modem and a telnet session (yeah, I'd rather use ssh for it too), so "slow-feeling" interactive sessions is as good as it gets for me... almost every day.
At least I can still get things done, just fine, that way. I can't imagine how the Windows admins deal with these remote issues... the box on the far end can have a load average of over 15, a bad network connection, and a modem between me and the box, and I can still work in it reasonably well... good luck doing that with VNC or Remote Admin GUI stuff! Yikes.
Good luck finding it. Nate