T.R | Title | User | Personal Name | Date | Lines |
---|
9348.1 | | netrix.lkg.dec.com::thomas | The Code Warrior | Tue Apr 01 1997 19:38 | 3 |
| Are you sure the two systems are using FDDI (and not Ethernet)?
|
9348.2 | | NETRIX::"[email protected]" | Robert Lange | Wed Apr 02 1997 14:05 | 8 |
| Absolutely sure. ALthough there are ethernet cards on the systems, they
were disconnected from the lan and the tests were again performed.
ANd yet, 800 kb/sec at best. This seems somewhat shy and I would expect
~75Mb/sec or so.
Regards
Robert
[Posted by WWW Notes gateway]
|
9348.3 | Sure it's not the backup software? | NETRIX::"[email protected]" | Brian Haley | Wed Apr 02 1997 19:14 | 12 |
| Hi,
Are you sure the backup software isn't the problem here, it might
be so slow it can only get 800K/sec. Try and benchmark the link
with something else, even something like ftp (tried repeatedly)
could give a real ballpark figure. I tried three times here and
got between 2151.26 Kbytes/s and 8162.71 Kbytes/s. The first try
was always the slowest, probably filesystem cache related? Notice
ftp's numbers are in bytes, not bits.
-Brian
[Posted by WWW Notes gateway]
|
9348.4 | TCP_NODELAY ? | SAPEC3::WALLMEROTH | | Thu Apr 03 1997 14:15 | 8 |
| Does your backup software use TCP connections ? Then you might want
to try: sysconfig -r inet "tcpnodelack=1"
Set it on both machines, to be sure to hit the right one.
If this gives you a significant performance win, tcpnodelack again
has proven as a nice WORKAROUND. The real solution is to use the
socket option TCP_NODELAY (on both ends of the connection).
See manpages: setsockopt and tcp
|
9348.5 | which subsystem | NETRIX::"[email protected]" | Robert LAnge | Wed Apr 09 1997 14:50 | 9 |
| Thanks for your suggestions, however this is a v3.2g system and there is
no such subsystem as inet. Hence, where can I find this parameter to change
if at all possible. Also, the only software being used for benchmark testing
here is ftp.
Keep those suggestions coming.....
Thanks
Rob
[Posted by WWW Notes gateway]
|
9348.6 | dbx -k /vmunix | SMURF::DUSTIN | | Wed Apr 09 1997 16:47 | 10 |
| You can dbx -k /vmunix and 'assign tcpnodelack=1' and try
the test again (no need to reboot here).
If this works, you'll need to get a tcpdump trace of the
problem to see what is going on, so we can evaluate it here
and fix it if there's a bug lurking in there. We've found
those from time to time, you know... ;-)
John
|
9348.7 | V3.2G has subsys inet | SAPEC3::WALLMEROTH | | Thu Apr 10 1997 05:08 | 10 |
| subsystem inet exists in V3.2G:
root@deccc31# uname -a
OSF1 deccc31 V3.2 62 alpha
root@deccc31# sysconfig -r inet "tcpnodelack=1"
tcpnodelack: reconfigured
root@deccc31# set -o vi
root@deccc31# sysconfig -r inet "tcpnodelack=0"
tcpnodelack: reconfigured
|
9348.8 | v3.2f and v3.2g | KAOFS::R_LANGE | Really?...no not really!.. | Mon Apr 14 1997 14:48 | 6 |
| Oh yes.... one caveat here. One system is apparently running 3.2f, and
so according to the customer they were both 3.2g. Doh!
I have instructed him via dbx to modify tcpnodelack to 1 and I am
awaiting word...
Thanks again folks...
Rob
|