A.P. Lawrence

bandwidth vs. servers

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Sat Oct 16 15:01:14 1999
Xref: world comp.unix.sco.misc:107667
Path: world!newsfeed.mathworks.com!remarQ-easT!rQdQ!supernews.com!remarQ.com!corp.supernews.com!not-for-mail
From: Jeff Liebermann <jeffl@comix.santa-cruz.ca.us>
Newsgroups: comp.unix.sco.misc
Subject: Re: Print servers + ip printing + scoadmin = brain haemorrage
Date: Sat, 16 Oct 1999 10:19:08 -0700
Organization: Committee To Maintain an Independent Xenix
Lines: 142 Message-ID: <7aYIOHRm3=vSTw7qCNWt3Ge45DCc@4ax.com> References: <37FB11CD.89F2FECA@mtgl.com.au> <37FC6FD7.25B26301@mtgl.com.au> <Grf8N2MV=8wg1Ey7+XMe77vYNzAH@4ax.com> <380138C4.F8A1BCC2@mtgl.com.au> <ylUBOJGykNrG7hlzE3iYJy+oy+=F@4ax.com> <38051EB9.A557BDA9@mtgl.com.au> <380598AA.5B73BBAB@aplawrence.com> <38066C77.C6FCBD84@mtgl.com.au> <3806FDF5.5EE5CAFC@aplawrence.com> <HFIHOJp=xmM9rANLCvVo=GiHwKNt@4ax.com> <38083FC7.B84CB315@dragnet.com.au>
Reply-To: jeffl@comix.santa-cruz.ca.us
X-Complaints-To: newsabuse@supernews.com
X-Newsreader: Forte Agent 1.6/32.525
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011

On Sat, 16 Oct 1999 19:05:12 +1000, Clint Zikesch
<czikesch@dragnet.com.au> wrote:

>We use a 5 character code.. 3 letters per dept. and 2 digits for numbers..

Significant numbering systems *ALWAYS* run out of digits.  The worst are
geographic numbering schemes.  I names one network printer HP4RM110 which
was originally an HP4 laserjet in room 110.  It's now a Lexmark something
in a different building.  Changing the name would involve a major
detective session trying to find all the configurations and scripts that
use the old name.  I don't wanna talk about the mess I had cleaning up
the mess when two companies merged.

>Ghost32 is a nice program that takes a disk image of
>a pc.

I used Powerquests DiskCopy.

>Only problem with cloning is that NT workstations have a Unique
>identifier that must be unique and a workstation identifier all through the
>registry that also must be unique.

The big problem is duplicated system ID's.  See:
        http://www.sysinternals.com/newsid.htm
for a fix.  Actually, the biggest problem I have are users that "clone"
their old machine to a new machine putting both machines on the network
at the same time.  Instant duplicated everything.  I can usually detect
this using arpwatch (the arp table will show a changing entry for a given
IP address).  DHCP helps for this, but doesn't do much for duplicated
names, sysID's, ident, etc.

>We have a sticker with the 5 char code on every item that goes with that pc.

I printed several sheets of unique IP numbers on my laser printer.  I
hung one sheet on the bulletin board that was inscribed "If you need an
IP number, take one."  I then sniff the network with NT4's Netmon
(borrowed from SMS server) to build the list.  Administrative overhead is
essentially zero.

>Put everything from the pc into a labelled box.  Put the records into an
>access db that I wrote which can track maintenance, ip addresses (including
>display of free addresses). for all equipment (pc's, users, printers,
>fax/photocopier, consumables, etc.). Register in DNS & DHCP tables.  Register
>in Novell tree for remote control.  Don't touch till we change the pc.

Nice.  A team of IS clerks and specialists should find job security in
such an arrangement.  However, it will work.  I can fabricate about a
dozen inventory control schemes that will work.  They all depend upon how
much work you're willing to put into them.  None of them run themselves.

>Our helpdesk sw uses the code to track problems encountered on an item
>level.  A little hard to setup but great once it gets going to quickly
>resolve problems.  I just wish help sheets were issued to users.
>I'm sure Jeff will say this is too much! :)

This is way too much.  Methinks Mongo the bouncer could do better.
However, if the cost of this administrative staff is justifiable and
functional, I'll conceed that the most efficient solution is not always
worth the effort finding.  If you need entertainment, calculate the cost
of a help desk call and see if it might not be cheaper handing the user a
new hard disk and starting over.

>If I could convince someone that the extra
>time I spend on admin saves us days/weeks/months of needless support work I
>would be happy.. of course they all agree at first.. but then it's like - Are
>we there yet? Are we there yet? Are we there yet? lol

Question:  What's the ratio of IS personnel (including consultants) to
productive staff (including contractors)?  That's the easiest measure of
whether the overhead is justifiable.

>When considering whether to go fat or thin client it was suggested (by our
>product vendor of course) that there wouldn't be a problem running thin
>clients over our Frame relay network.  At 32Kb effective bandwidth I smiled
>disbelievingly.. with a ping time ranging from 150ms -> 500>ms!?  Do you have
>an opinion on that Jeff?  Just interested in a veterans opinion. :)

I don't have any frammis-relay connections.  Everything is either direct
or VPN.  However, I do tinker with one satellite link which has a
guaranteed 600ms minimum latency.  It's a problem because of the 64KByte
maximum window size in TCP/IP which limits performance to about
1.2Mbits/sec.  You won't have any serious effects from 150-500ms latency.
Incidentally, I'm currently on a Metricom RF link running at a fabulous
1.7Kbits/sec with an average latency of about 1000-3000 msec (I'm in a
really rotten location).

Trace www.ricochet.net (204.179.107.3) ...
 1 168.253.32.161 1035ms 1245ms 1398ms  TTL:  0  (mg-sj3v.mcdn.net ok)
 2 204.179.141.1  1296ms 1101ms 1112ms  TTL:  0  (mg141-001.ricochet.net
ok)
 3 168.253.7.17   1259ms 1168ms 1075ms  TTL:  0  (No rDNS)
 4 168.253.11.242  989ms  838ms  919ms  TTL:  0  (No rDNS)
 5 168.253.3.145  1007ms 1003ms 1083ms  TTL:  0  (No rDNS)
 6   No Response      *      *      *                 
 7 204.179.107.3   861ms 1214ms 1064ms  TTL:248  (www.metricom.com ok)

It works, but I loose some packets and sometimes constipate the
connection with retries.  If you have a decent client server
architecture, this should not be a problem.

>I'm more inclined to believe we would be forced to buy the server for each
>site.. This would have eliminated any savings well and truly.. and been a
>support problem as we have 0 IT staff on remote sites.

The cost of a remote server is much cheaper than the bandwidth it
replaces.  Do the math.  I have a Lotus Notes customers (running on NT4)
with 6 remote locations.  5 of the remote sites have local *REPLICATING*
servers.  It's the replication that makes this work.  One customer user a
mix of DS0 (56Kbit/sec) and ISDN BRI lines to connect servers.  Direct
logins with PC Anywhere are acceptable over these connections.  RAS is
barely tolerable.  However, the main Lotus applications run blindingly
fast because they are running from a local server sitting on an all
100base-TX full duplex switched network.

The largest traffic connection has a 14.4 modem dialup backup in case the
ISDN BRI goes down.  It went down for about a week and nobody even
noticed until someone tried to use PCAnywhere to do some remote
maintenance.

If your application is not client server, if you're trying to dispense
applications over the network, or if you simply have a gross and
disgustingly inefficient application (usually COBOL), then they will
become a bandwidth hog.  Topology issues such as central print spooling
vs spooling on the client make a big difference in network traffic.
However, all the planning in the world does not replace sniffing the
network to see what's moving.  I try to have the router connected to its
own switched port.  That's the connection that I sniff.  Often, I find
that some bizarre application or configuration has increased traffic
beyond acceptable limits.  Planning is a good starting point, but
monitoring lets me sleep nights.

I make the big bucks designing networks like this and I won't do this one
in public.  It's also a bit too messy for my casual pontifications to be
100% correct.  Just one piece of advice:  Do the math.  You'll probably
find that server boxes are cheaper than bandwidth.

-- 
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl   WB6SSY
jeffl@comix.santa-cruz.ca.us   jeffl@cruzio.com

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/122.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here