Return to BSD News archive
Xref: sserve comp.os.linux.development:22899 comp.os.386bsd.development:3084
Newsgroups: comp.os.linux.development,comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!news.provo.novell.com!park.uvsc.edu!news
From: Terry Lambert <terry@cs.weber.edu>
Subject: Re: SAMBA and NETWARE mounting
Organization: Utah Valley State College, Orem, Utah
Date: Fri, 27 Jan 1995 19:09:20 GMT
Message-ID: <D32vvM.5ro@park.uvsc.edu>
X-Nntp-Posting-Host: hecate.artisoft.com
References: <3eo2j1$l5o@uqcspe.cs.uq.oz.au> <D267uw.Grq@park.uvsc.edu> <D2JnoD.1DD@pe1chl.ampr.org> <D2KG6E.CMp@park.uvsc.edu> <D2LH48.3IF@pe1chl.ampr.org> <D2qACr.A46@park.uvsc.edu> <D2s16r.428@pe1chl.ampr.org> <D2vrE0.D8M@park.uvsc.edu> <D2x440.1J1@pe1chl.ampr.org> <D2z554.K4F@park.uvsc.edu> <1995Jan26.162507.26091@rhrk.uni-kl.de>
Sender: news@park.uvsc.edu (System Account)
Lines: 204
weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) wrote:
] >OK, neutrally speaking, what would you point to as the main
] >advantage of IPX?
]
] He already said so. Larger address space. I would like to add:
] Automatic configuration of network and station adresses at ordinary
] (non routing) systems.
Excuse me, but address space is only an applicable argument if you
have that many hosts on a single network.
Autoconfiguration is a function of your client software if the
servers on your net are properly configured.
And we all know that there is no such thing as an IPX Internet so
far, and God willing, there never will be.
] >Please be sure to include NetWare/IP (NCP over IP instead of IPX)
] >in your analysis before you answer.
]
] See above.
Not an answer.
[ ... NetWare/IP as an argument that NCP does not imply IPX ... ]
] You simply won't get what you describe here. Netware/IP effectively
] doubles the system cost, simply for using NCP on top of IP instead of IPX.
Of course it does. Novell has a vested interest called their
installed user base, which encourages them to make IPX cheaper
than IP. Mostly this interest is based on the fact that without
their installed base, Microsoft has already eaten their lunch.
One could also argue that you get what you pay for, and that Novell
is recognizing the relative worth of the protocols in their pricing,
if one didn't want to be cynical about Novell's motives in trapping
users in the IPX dead-end.
8-).
]] >You want a technical attack on IPX? OK, how about the lack of
] >packet checksums?
]
] As long as you have them on the media level, one might argue that you
] don't need them at the protocol level. Moreover, AFAIK they _are_ in the
] IPX spec anyway, but not implemented on the usual media.
PPP.
SLIP.
Async bridging.
Lots of media doesn't support hardware correction. For instance,
bridging to Frame Relay from a Novell supplied MPR using an NE3200
card.
] > How about the misimplementation of the 802.3
] >protocol encapsulation header?
]
] You refer to a specific IPX implementation, which is obsolete for a number of
] years now (though still widely used) ?
I refer to the only 802.3 IPX implementation. And the reason it is
widely used is that it is the default configuration for Novell
supplied client software.
] >] Also, there is a MODEM pool which is to be accessed from the PCs, and
] >] of course there are some printers.
]
] >Much of the NetWare print model is a joke. The lpr protocol at
] >least does not use timeouts to indicate end-of-job!
]
] Netware doesn't either, but has a clear well defined print job concept.
] The mere fact that utilities that try to emulate a locally attached printer port
] must use timeouts, simply because braindead DOS software insists in using
] these ports doesn't mean there aren't more clean ways to send data to a Netware
] printing queue.
This is BS. This is as wrong as the argument that because DOS
does not support a "search end" mechanism that the file searches
should be pushed into the network API's.
And it's plain false. NetWare does NOT support end of job
notification in rprinter protocol. Internally, it uses timeouts,
with a certain amount of line silence indicating end of job. You
are confusing the print redirection in DOS machines (the CAPTURE
command *does* support timeouts in notification to the enqueuing
mechanism) with the rprinter IPC mechanism used between the program
that dequeues the job from the print queue and the program that
shoves it out a printer somewhere (the second part being the piece
that uses the timeouts to indicate end of job).
] >How about NCP clients over an IP transport to NetWare for UNIX?
]
] >That buys me both the ability to throw away all of the IPX issues
] >and concentrate on a single network transport protocol framework.
]
] This buys you in the first place a nice red box that enables you to use
] all the things you've already bought before, and nothing more. It buys you,
] at best, about 20k of free memory in every PC using it, provided you have
] already used Lan Workplace or PC/TCP before. Else ? Well, in small and
] medium sized installation using and routing IPX is as painless as it could
] be. In large installations, you probably already have equipmant that can
] handle IPX as well as IP, so why bother ?
You're back to discussing legacy systems ("things you've already
bought before") here. This is the reason I already admitted that
one would install IPX -- the *only* sane reason.
In small to medium installations, the routing of IPX may not be a
real issue (remember that we started out talking about internet
systems!), but price-point becomes one. As a small business, I am
much better served using the default peer networking that comes
on my machine that comes installed with a Microsoft OS, which will
be Windows 95 in the very near future.
If administration is an issue (as you imply in the next paragraph),
I am much better served going with Lantastic than either Microsoft
OR Novell.
] On the downside, you are now the proud owner of a number of hassles you
] possibly didn't have before - you suddenly start administrating IP numbers
] for every f* PC you have on the net, you have to worry about subnet numbers,
] correct (default) router entries, nameserver configurations ect etc.
You must be referring to an IP stack that doesn't support DHCP. Talk
about legacy systems!
Default routing in a large network is already a problem with IPX,
which requires SAP restriction to make it work, which requires
routers with more knowledge of protocol decoding than they should
be required to have.
] >Admittedly the self-tunneled IPX in the NetWare/IP product is a
] >kludge, but it's less of a kludge than replacing all of the Cisco
] >and Kalpana boxes on the planet with Novell Servers running the
] >multiprotocol router NLM.
]
] Why the hell do you want to replace CISCo routers ? They route IPX quite
] well. (I associate Kalpana primarily with Ethernet switches, so I don't know
] where the problem should be in this case).
Because the internet is IP. Because cisco routing tables overflow
unless you SAP-restrict the broadcasts the cisco sees. Because
most installations by Universities (and again, recently demonstrated
by the State of Utah on their ATM network), most people don't know
how to set up a heirarchical map of NetWare servers to optimally
reduce the SAP traffic to manageable levels.
As was demonstrated when USL was brought on the Novell corporate
network without initial protection from SAP. Adding the SAP
traffic for 1200 machines which bitch about who they are every 55
seconds is a quick way to drop a net to its knees.
] >This assumes that you are willing to make the latency trade off
] >inherent in NCP's request/response architecture
]
] ....which is not correct for current implementations...
If you are talking about packet-burst, think again. All packet burst
is good for is a wire where there is sufficiently little traffic
that statistically multiplexing huge packet chains onto the wire
doesn't result in too many collisions.
Yes, this will vastly improve performance by substituting a fixed
non-sliding window for where the protocol really ought to have a
sliding window. This is extremely on/off as the packet burst
engine waits for an ack on each burst sequence, especially over
long delay links.
Say you have a 16k window and a line latency of 100ms. To make
the math easy, we download a 1.6M binary for a cad program (packet
burst is limited to sequential reads, so we are favoring it here).
This is 100 acks assuming no retries. Remember that ethernet is
a CSMA/CD, not a CSMA/CA medium, so we assume no more than 20% of
the bandwidth is being utilized so we don't have to take retries
into our picture -- again, favoring it. This is ~100 request
response pairs, even for packet burst, or 20 seconds additional
download time for a typical program (latency is bidirectionally
additive).
Now for a sliding window protocol instead of a a fixed 16k window
protocol, we have an additional 200ms (we have to count the start
and ending packets latency). 200ms << 20000ms.
This is precisely why using a TCP based measurement (TCP is sliding
window) is a critically stupid metric of expectable performance for
ack/nak protocols. Like those used by DOS workstations to talk
to servers. Like SMB and NCP.
The Novell dinosaur needs to change with the times.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.