Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jan 1998 14:35:11 -0600 (CST)
From:      Joe Greco <jgreco@solaria.sol.net>
To:        mountin.man@mixcom.com (Jeffrey J. Mountin)
Cc:        lukas@design.de, freebsd-isp@FreeBSD.ORG, jkh@time.cdrom.com
Subject:   Re: [fbsd-isp] Designing for a very large ISP
Message-ID:  <199801122035.OAA15650@aurora.sol.net>
In-Reply-To: <3.0.3.32.19980112140534.006e313c@mixcom.com> from "Jeffrey J. Mountin" at "Jan 12, 98 02:05:34 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> At 12:07 PM 1/12/98 +0100, Lukas Wunner wrote:
> >5 slots is beyond the PCI specification so the last slot is always
> >non-busmastering which makes it practically useless for any serious
> >use. So we can forget about the 5th PCI slot on these boards and
> >assume they also have 4 *usable* slots.
> 
> In simple terms, one of the 4 is used to add 2 more (1 replacing the 4th)
> and no you can't bus master, which is something I've forgot.  It's has been
> a long while since I read up on this, but you can get up to 7 I believe.

Your average 5-slot PCI board (incl the ones I've seen from ASUS) uses
a PPB to deal with the fifth slot (and generally PCI IDE/etc as well),
which means that you should be able to bus master on all slots.  This
is the same way that the Adaptec 3940/3985's work, as well as the SMC
9334BDT, Z314, and other multiport Ethernet adapters.

> Still, with 3 SCSI controllers and NIC isn't that enough?  Just how many
> feeds are you dealing with?

I've been sticking 3 ASUS SC-200 (NCR810)'s plus two SMC 9334BDT's in
my reader machines these days. Network traffic gets fun when you're
running five or six hundred simultaneous readers.  Current design is 
PII/233 plus 256MB RAM, 15 drives, but I may pop for 384MB RAM to 
squeeze more readers on.

newsfeeds.sol.net runs two Adaptec 3940's, an NCR810, and several
Ethernets...  evening network traffic peaks are measurable in terms
of megabytes per second.  Of course, the machine's doing a kajillion
things, including running a Quake server, Web services, Usenet news
analysis tools (see my Usenet Posting Summaries), and also tossing
about 200K/s to a bunch of AXIS NetEye cameras (see http://www.ispcam.com).

That, and of course, newsfeeds.sol.net is a Top 10 news server.

> >Sure. So how do you propose one should distribute an innd process among
> >several machines? Your suggestion does not work out in this case *at all*.
> 
> You could have one handle feeds and use slaves for readers.  

A typical master/slave setup works pretty well.  I'm shoveling about
four hundred readers onto my machines here, although I've gone higher
without noticeable degradation.

If you want distributed reading, it's probably The Thing To Do.  OTOH,
nntpcache might work for a much smaller installation.

> >Have you actually *tested* if this board will grok 1GB of memory or are
> >you just saying this out of the blue, based on the specs published by
> >Tyan? If the latter is the case, let me assure you that Tyan's specs
> >aren't worth a penny when it comes to accurateness. The Tomcat III board
> >is advertised to support 512MB of RAM, which would be sufficient for our
> >news machine. However, in contrast to the specs, it actually only supports
> >a maximum of 256MB of RAM which is not sufficient. I have tested this with
> >lots of different types of SIMMs and with several permutations of these
> >SIMMs to no avail. If the machine has been turned off for a while and is
> >cold, it will (unreliably) report either 256MB or 288MB. In all other
> >cases, it will report 256MB on bootup. Michael Beckmann has reported
> >a similar problem: he didn't even manage to get the Tomcat III to work
> >with 256MB of RAM (the system didn't run too stable). Downgrading to 192MB
> >would solve the problem.
> 
> No, sorry.  This seems to be a problem with Tyan, but then we only have 2
> examples.  Anyone else out there with 512 or more?

256 works fine on the ASUS P/I-P55T2P4; 384 works well on the P55T2P4D,
and I haven't had a real need to push 512 yet, but I do have a P55T2P4D
running 512 (but not running FreeBSD).  As always, work with a reputable
memory dealer, not all SIMM's are created equal.

Dunno about that second rate Tyan stuff :-)

> >As a general rule of thumb, with PCs you will almost always be able to get
> >128MB to work reliable, more than 128MB is a matter of luck, more than
> >256MB is practically impossible. I had to learn this the hard way.
> 
> Surely all boards do not have this problem and I personally don't know
> anyone with over 512 Mb.  Possible BIOS problem?
> 
> Kevin mentions chip density.  I was burned by this a couple times to I
> always use the lowest possible density.

Not always.  I've seen lower density units freak a board that had SIMM's
in it that were denser than mfr. spec.  -- it's still working fine after
a year and a half, too.

See advice about reputable memory dealer, above.  :-)

> Another thing to consider is the number of available sides ie RAS#.  If you
> only have 6 (or 4 like some boards), then you need to consider if the SIMMs
> are single or double sided (thankfully an literal in most cases), but since
> you mention having 4 - 64 SIMMs, I'll assume you have 8 RAS#s and the
> memory is most likely double sided (common above 8 Mb).  Have you tried 4
> 128 Mb SIMMs.
> 
> Frankly I have no clue if you can get 64 Mb, let alone 128 Mb, SIMMs that
> are only single sided.
> 
> Sadly most manuals are not clear on this point or do a good job of
> confusing the issue by not elaborating.
> 
> This also makes me wonder how wuarchive has 8 - 128 Mb SIMMS.  Jordan?
>
> >Of the three German news boxes in the upper 50 ranks in Top1000 12/97
> >(www.freenix.fr/top1000), two are SGI-based systems (fu-berlin.de and
> >newsfeed.ecrc.net). No comment.
> 
> Isn't there a site that also lists the server/OS used?

No.

> ... and sol.net has 4 in the top 20 and 2 in the top 10.  Not sure if they
> are all FBSD, Joe?

That #20 is a Solaris box...  this month.  (Cyclone).  As much as I hated
to run Solaris, I needed a box to develop some Cyclone based filtering
software.  It'll be FreeBSD as soon as I can convince Highwind that
FreeBSD rules.  :-)

Everything else is FreeBSD.

> >> If the board can handle 128 Mb SIMMs, the Titan pro must since 8 * 128 = 1
> >> Gb and either EDO or EDO/ECC are comparable in price.
> >
> >Sure, go ahead and test it.
> 
> I'd love to, but my budget won't allow for it.  Checking the manual gives
> no mention of the total RAS#s or if 8 - 128 Mb _double_ sided SIMMs can be
> used.  And there is a discrepency between their table and prior text, which
> makes me wonder it it really can use even 2 - 128 Mb SIMMs.
> 
> -The mainboard supports 1, 2, 4, 8 and 16MBx32 SIMMS.
> 
> -Bank0    Bank1    Bank2    Bank3    Total
> -128MB x2 128MB x2 128MB x2 128MB x2 1024MB
> 
> Sorry to say that 16 x 32 is a 64Mb SIMM.  A 128 Mb should be 16 X 64.
> Makes me wonder.

Huh?  I'm confused about what's being discussed.

16 x 32 is a 64MB nonparity 72 pin SIMM.
16 x 64 is a 128MB nonparity DIMM.

Anyone who gets x64 memory at those densities get what they deserve, though.
I'm happily getting 16 x 72 - 60 EDO's, which I can do ECC on.  :-)

> >> Plenty of alternatives to the SGI.
> >
> >Probably not.
> 
> If you are talking dozens of feeds, maybe not.

What?  Why?  I do dozens of feeds.  And other stuff for fun.  All in
384MB.  On a single Pentium Pro 200.  :-)

> Considering the small investment, why not try the SuperMicro that wuarchive
> uses?  I merely point out the fact that the small price of a motherboard
> would be worth trying before spending big bucks.  If it works, great.  If
> not you still can use it for another system.
> 
> I'll rectract my Tyan recommendation, as they don't inspire any confidence.
>  Never used one, but friends have.
> 
> 
> Jeff Mountin - Unix Systems TCP/IP networking
> mountin.man@mixcom.com


... Joe

-------------------------------------------------------------------------------
Joe Greco - Systems Administrator			      jgreco@ns.sol.net
Solaria Public Access UNIX - Milwaukee, WI			   414/342-4847



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801122035.OAA15650>