[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9348.0. "fddi performance" by NETRIX::"[email protected]" (Robert Lange) Tue Apr 01 1997 17:10

I have a customer tunning dunix 3.2g and have a defpa-da fddi/pci adapter
installed and configured. THe system is a client axp4100 which does a netword
backup to an 8200 also running dunix 3.2g. At first the issue was that they
were getting no more than ~800kb/sec transfers from one box to the other. 
It was observed that the cards were running in half-duplex mode only. They
could not be set to full duplex untill osf350-145 patch was installed. This
was recommended from STARS. Following that there was no increase in
performace.
The two systems are directly connected and routing is via static 
interface/host routing. IS there any reaon why there cannot be greater 
performance realize from off the shelf setup. Is there something that need
tweeking as far as varibles are concerned. BTW mtu = 4352.
Could someone give some recommendations here...

Thanks and regards
Robert
[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name
DateLines
9348.1netrix.lkg.dec.com::thomasThe Code WarriorTue Apr 01 1997 19:383
Are you sure the two systems are using FDDI (and not Ethernet)?


9348.2NETRIX::"[email protected]"Robert LangeWed Apr 02 1997 14:058
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.3Sure it's not the backup software?NETRIX::"[email protected]"Brian HaleyWed Apr 02 1997 19:1412
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.4TCP_NODELAY ?SAPEC3::WALLMEROTHThu Apr 03 1997 14:158
    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.5which subsystemNETRIX::"[email protected]"Robert LAngeWed Apr 09 1997 14:509
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.6dbx -k /vmunixSMURF::DUSTINWed Apr 09 1997 16:4710
    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.7V3.2G has subsys inetSAPEC3::WALLMEROTHThu Apr 10 1997 05:0810
    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.8v3.2f and v3.2gKAOFS::R_LANGEReally?...no not really!..Mon Apr 14 1997 14:486
    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