Re: Setting a reliable MINIMUM connectivity latency?
On Fri, Apr 18, 2008 at 11:19 PM, Mike Walter [EMAIL PROTECTED] wrote: We've determined an average workstation latency (simply using PING) for a workstation far, far away as being about 380-400ms. But we don't know what it would be like to actually WORK on that workstation day-in and day-out. Most of the work would be in support of Linux for System z servers. Most likely via SSH (using SecureCRT from VanDyke Software), but also some 3270 usage, net surfing, and Lotus Notes. 400 ms is rather long indeed. I work a lot on remote systems where ping times are in 100-200 ms range. Obviously for 3270 it is mostly a non-issue and people with VTAM terminals have done much worse forever. But even for ssh connections I have no problem working on the other side of the big pond. You can do quite some type-ahead on the average Linux session. I don't think my sustained typing rate with think time goes beyond 5 cps. If the system feels too slow to work with, it's almost always performance issues on the other end or network problems that cause re-transmits. Rob -- Rob van der Heij Velocity Software GmbH http://velocitysoftware.com/
Re: Setting a reliable MINIMUM connectivity latency?
On Apr 19, 2008, at 3:03 AM, Rob van der Heij wrote: On Fri, Apr 18, 2008 at 11:19 PM, Mike Walter [EMAIL PROTECTED] wrote: We've determined an average workstation latency (simply using PING) for a workstation far, far away as being about 380-400ms. But we don't know what it would be like to actually WORK on that workstation day-in and day-out. Most of the work would be in support of Linux for System z servers. Most likely via SSH (using SecureCRT from VanDyke Software), but also some 3270 usage, net surfing, and Lotus Notes. 400 ms is rather long indeed. I work a lot on remote systems where ping times are in 100-200 ms range. Obviously for 3270 it is mostly a non-issue and people with VTAM terminals have done much worse forever. But even for ssh connections I have no problem working on the other side of the big pond. You can do quite some type-ahead on the average Linux session. I don't think my sustained typing rate with think time goes beyond 5 cps. If the system feels too slow to work with, it's almost always performance issues on the other end or network problems that cause re-transmits. During some portion of the year, I work over a satellite link. Best case is about 700ms, often much worse. It's tolerable but annoying for ssh. tn3270 is essentially unaffected, as are, of course, web and email (except that pages take a long time to start to load). It's not reasonably usable for remote desktop stuff. Adam
Re: Setting a reliable MINIMUM connectivity latency?
For 3270 you may find bandwidth sooner to be an issue. Long time ago I worked on 300 bps. When someone then put a 'FULLREAD ON' in some shared XEDIT profile (because IBM recommended it) I had plenty of time to think about adequate punishment... Jim is very right about expectations. Many performance problems are in fact expectation problems (created by IBM Sales) Back in those days I expected to do productive work with 300 bps. These days I don't even plan to do email with 3 orders of magnitude more bandwidth. Rob
Re: Setting a reliable MINIMUM connectivity latency?
Mike Walter writes: We've determined an average workstation latency (simply using PING) for a workstation far, far away as being about 380-400ms. But we don't know what it would be like to actually WORK on that workstation day-in and day-out. Most of the work would be in support of Linux for System z servers. Most likely via SSH (using SecureCRT from VanDyke Software), but also some 3270 usage, net surfing, and Lotus Notes. Does anyone know of a way to set a reliable minimum or min-max range latency on a given workstation so that effects on productivity can be measured? Yes, Linux has plenty of fancy traffic control functionality configurable with the tc userland utility that's part of the iproute2 package that will have come with your distro. What you probably want is the netem (Network Emulation) queue discipline. Simulating real networks is rather complex but you can start by doing things like imposing packet delays based on a chosen probability distribution. My PC here has ping times of about 45ms to google: [~]pc# ping -n www.google.co.uk PING www.l.google.com (216.239.59.99) 56(84) bytes of data. 64 bytes from 216.239.59.99: icmp_seq=1 ttl=241 time=44.0 ms 64 bytes from 216.239.59.99: icmp_seq=2 ttl=241 time=47.1 ms 64 bytes from 216.239.59.99: icmp_seq=3 ttl=241 time=45.7 ms so if I do # tc qdisc del dev eth0 root netem delay 345ms 10ms then it imposes a(n outgoing) additional packet delay of average 345ms plus/minus 10ms (uniform distribution) giving me: [~]pc# ping -n www.google.co.uk PING www.l.google.com (216.239.59.147) 56(84) bytes of data. 64 bytes from 216.239.59.147: icmp_seq=1 ttl=241 time=383 ms 64 bytes from 216.239.59.147: icmp_seq=2 ttl=241 time=395 ms 64 bytes from 216.239.59.147: icmp_seq=3 ttl=241 time=390 ms You can do more complex things with netem: e.g. choose different probably distributions either built-in or read from a text file you've lovingly constructed to emulate a given real network), impose packet loss, duplication, corruption re-ordering and so on. You can then filter and/or send those through other queue disciplines to do other packet shaping, bandwidth limiting etc. I've just found http://www.linux-foundation.org/en/Net:Netem which is a good introduction to using netem. At the bottom of that page in the Links section is a link to a paper of Stephen Hemminger http://developer.osdl.org/shemminger/LCA2005_paper.pdf which goes into great detail about simulating the characteristics of a particular network. The main thing is that, since you can only directly control outgoing packets (unless you have similar traffic shaping at the remote end) you probably want to do the tc stuff on a Linux guest router sitting in between the far end and your target host so use tc in combination with your routing tables and maybe qdisc filters to pick out the traffic you want slowing down (if not all of it). --Malcolm Malcolm Beattie [EMAIL PROTECTED] System z SWG/STG, Europe IBM UK
Re: Setting a reliable MINIMUM connectivity latency?
Mike ... Maybe you need to re-think the problem. What if the interactive part could be handled locally with file synchronization carried out in the background? If you need the remote also for execution, that could be driven over SSH with commands stacked onto the session(s). Something like this: rsync farhost:remotedir nearhost:localdir vi localfile rsync nearhost:localdir farhost:remotedir and then to crunch the files on the remote system: ssh farhost buildcommand Byte-at-a-time interaction across that many miles does seem absurd and sometimes is not effective. Oh: Also, the EMACS crowd will probably point out that EMACS has a remote function where your interaction is driven by a local client though the file itself is stored remotely. But it requires that you standardize on the one editor. (Thus a systemic solution is more palatable to most of us.) -- R;
Re: Setting a reliable MINIMUM connectivity latency?
RSYNC is nice because it (normally) only copies what has changed. -- R;
Jeff Beck is out of the office.
I will be out of the office starting 04/15/2008 and will not return until 04/21/2008. I will be out of the office Wednesday 4/16 and will return Monday 4/21. For urgent matters, please contact the Federal Information Call Center at 1-800-333-6705. Thank you.
