OBSD Bridge Minimal Hardware Requirements - BSD

This is a discussion on OBSD Bridge Minimal Hardware Requirements - BSD ; I have a 2048k/2048k SHDSL connection with a few email servers, a web cache & www server behind it. I wish to deploy a OBSD3.9 packet filtering bridge. Im low on hardware resources, & wondering if a Pentium 133Mhz machine ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: OBSD Bridge Minimal Hardware Requirements

  1. OBSD Bridge Minimal Hardware Requirements

    I have a 2048k/2048k SHDSL connection with a few email servers, a web
    cache & www server behind it. I wish to deploy a OBSD3.9 packet
    filtering bridge.

    Im low on hardware resources, & wondering if a Pentium 133Mhz machine
    would cope. If not what would be the absolute minimum spec I could get
    away with.


    ---

  2. Re: OBSD Bridge Minimal Hardware Requirements

    darkmoo wrote:
    > I have a 2048k/2048k SHDSL connection with a few email servers, a web
    > cache & www server behind it. I wish to deploy a OBSD3.9 packet
    > filtering bridge.
    >
    > Im low on hardware resources, & wondering if a Pentium 133Mhz machine
    > would cope. If not what would be the absolute minimum spec I could get
    > away with.
    >

    Many folks here run similar systems with even lower-powered hardware.
    Unless I'm unaware of a specific requirement for bridging, I'd say you
    will be fine.

    Make sure you use some recommended and well-supported NICs. I've heard
    a rumour that gigabit NICs are often useful even in a 10/100 environment
    because of their larger frame caches.

    I've also used a trick where you put all the NICs on the same PCI
    interrupt but I did not measure to see if it actually helps. There were
    certainly fewer I/O interrupts on that box.

  3. Re: OBSD Bridge Minimal Hardware Requirements

    Begin <0lP5g.20265$43.5605@nnrp.ca.mci.com!nnrp1.uunet.ca>
    On 2006-05-02, void * clvrmnky() wrote:
    > darkmoo wrote:
    >> I have a 2048k/2048k SHDSL connection [...]


    Data lines are measured in bits/sec and the multipliers are
    powers of 10, not 2. You're likely to have something like a 2300 kbits/s
    SDSL, as that is apparently a common setup.


    > Many folks here run similar systems with even lower-powered hardware.
    > Unless I'm unaware of a specific requirement for bridging, I'd say you
    > will be fine.


    Depends a bit on the architecture, but indeed the speed of the cpu alone
    doesn't tell much. In fact, cisco uses fairly low-powered cpus, but has
    custom designed backplanes and all that, to push data around through the
    network ports as efficiently as they can make it.

    The problem with desktop-oriented hardware, of course, is that it is
    engineered for marketing, which means shiny numbers, not necessairily
    actual performance, let alone network io performance. Some boards will
    perform much better than others. Which does what is hard to tell without
    trying. Whether what you have for your packet filtering bridge is good
    enough for your needs, (well, the OP's, but anyway) depends heavily on
    the traffic, both amount and nature, and what you want to do to that
    traffic.

    I'd say, try, and keep an eye on things. If you can't get it to keep up
    you can always replace it with slightly less obsolete hardware.


    > Make sure you use some recommended and well-supported NICs. I've heard
    > a rumour that gigabit NICs are often useful even in a 10/100 environment
    > because of their larger frame caches.


    I've heard the reasons include that they are more likely to keep up when
    the line is filled with small frames. Getting close to the theoretical
    maximum linespeed is much harder in that case, so if you have a lot
    of small frames to cope with (eg the TCP ACKs going back to where the
    bulk data came from) even with `only' a 100Mbit switch on the other
    end, using a Gbit NIC might be helpful. Then again, for just 2Mbit of
    traffic, I'd expect a decent 100Mbit NIC to cope just fine.

    Good 100Mbit NICs include, in my opinion, digital-now-intel 21143 and
    intel 825xx chipset based cards. They *do not* include anything made by
    realtek.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  4. Re: OBSD Bridge Minimal Hardware Requirements

    On Wed, 03 May 2006 07:37:00 +0000, jpd wrote:

    > Good 100Mbit NICs include, in my opinion, digital-now-intel 21143 and
    > intel 825xx chipset based cards. They *do not* include anything made by
    > realtek.


    I've only got realtek cards. Since I've havent had any issues with them.
    I've found them to be a good all rounder generic card, after coming from
    Dlink cards which always had issues low level issues with my OBSD installs.
    Also got a old dlink switch which is slowly dying port by port. Yuck!


  5. Re: OBSD Bridge Minimal Hardware Requirements

    Begin
    On 2006-05-04, darkmoo wrote:
    > I've only got realtek cards.


    You might try and get a better card one day, put both in slow machines,
    and try to get some real performance out of them. Big packets, small
    packets, latency tests, the works. Compare.


    > Since I've havent had any issues with them. I've found them to be a
    > good all rounder generic card, [...]


    For simple desktop use, and/or when you've got the cycles to spare.
    Altough tempting because a lot of use is of that kind nowadays, I'd
    certainly not classify that as ``all rounder''. Dirt cheap, yes. Often
    used, yes. Widely spread, yes. ``All rounder'', no. Hell no, even.

    Other people have found that, for example, in a setup with fast desktop
    machines sporting 3com cards and a low end router sporting realteks,
    swapping the cards so the fast machines had the realteks and the old and
    slow router the 3coms, improved performance considerably. And that at no
    additional hardware costs.

    There are some *interesting* comments about realteks and their
    programming interface in the FreeBSD driver source, for example here:

    http://www.freebsd.org/cgi/cvsweb.cg...ys/pci/if_rl.c
    ?rev=1.163&content-type=text/x-cvsweb-markup

    [excuses for the split url]

    Basically, what this says means that because of its programming model,
    trying to put a lot of packets through the card is cpu-intensive. And,
    after all, we *were* talking using old hardware for network i/o.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  6. Re: OBSD Bridge Minimal Hardware Requirements

    darkmoo wrote:
    > On Wed, 03 May 2006 07:37:00 +0000, jpd wrote:
    >
    >> Good 100Mbit NICs include, in my opinion, digital-now-intel 21143 and
    >> intel 825xx chipset based cards. They *do not* include anything made by
    >> realtek.

    >
    > I've only got realtek cards. Since I've havent had any issues with them.
    > I've found them to be a good all rounder generic card, after coming from
    > Dlink cards which always had issues low level issues with my OBSD installs.
    > Also got a old dlink switch which is slowly dying port by port. Yuck!
    >

    It's funny. This Realtek argument among BSD users is quite active,
    still. I recall reading something from de Raadt recently where he made
    a quality statement about Realtek devices in terms of a before/after.
    As in, they suck less now, and may even be recommended. I'll try to dig
    up the details.

    They are also more forthcoming with documentation, which may explain why
    the positive comments lately.

    Personally, I only have direct experience with xl and vr devices. The
    vr(s) are only recent, and I have not tested them much. The xl(s) seem
    to choke on higher amounts of data (of course, this may be a function of
    the driver and link-layer code) and they do not respond to heat very
    well. At one point I swapped them so that the higher-speed link used
    the less flaky NIC. And turned the PS fan back on

  7. Re: OBSD Bridge Minimal Hardware Requirements

    On Thu, 04 May 2006 11:26:29 +1000, darkmoo wrote:

    > On Wed, 03 May 2006 07:37:00 +0000, jpd wrote:
    >
    >> Good 100Mbit NICs include, in my opinion, digital-now-intel 21143 and
    >> intel 825xx chipset based cards. They *do not* include anything made by
    >> realtek.

    >
    > I've only got realtek cards. Since I've havent had any issues with them.
    > I've found them to be a good all rounder generic card, after coming from
    > Dlink cards which always had issues low level issues with my OBSD
    > installs. Also got a old dlink switch which is slowly dying port by port.
    > Yuck!


    My personal experience with realtek:
    - one (or only) interface card is realtek --> NO problem
    - multiple realtek cards --> they don't talk to each other!
    I.E. no routing possible between realtek cards!
    --> no such problems with the "dc" kind of cards!
    (at about the same pricetag!)

  8. Re: OBSD Bridge Minimal Hardware Requirements

    Begin
    On 2006-05-04, void * clvrmnky() wrote:
    > It's funny. This Realtek argument among BSD users is quite active,


    Possibly because they're dirt cheap and consequently ubiquitous. Many
    people using current hardware won't notice the drawbacks because they
    have the cycles to spare. If you don't have those...

    Then again, realtek type hardware (also compare winmodems), has happened
    before, and will happen again:

    http://www.catb.org/~esr/jargon/html...carnation.html


    > still. I recall reading something from de Raadt recently where he made
    > a quality statement about Realtek devices in terms of a before/after.
    > As in, they suck less now, and may even be recommended. I'll try to dig
    > up the details.


    Please do. It doesn't surprise me though; no engineer worth his salt
    would be proud of being told his designs are the absolute bottom of the
    pile. The upside is that if you're there, improving isn't exactly hard.
    Just look at what the competition is doing.


    > Personally, I only have direct experience with xl and vr devices. The
    > vr(s) are only recent, and I have not tested them much. The xl(s) seem
    > to choke on higher amounts of data (of course, this may be a function of
    > the driver and link-layer code)


    Possibly, altough ISTR 3c905 pre C series had various nasty problems.
    My bad experiences with those devices are limited to the 3c920, which
    supports checksum offloading, and the linux driver that helpfully logs
    whenever the card reports a bad incoming TCP checksum (something the
    software checksummer does not do), and developer-also-deploying type
    persons that won't believe a failed checksum showing up in the logs
    isn't the end of the world.

    ``The driver wouldn't report it if it wasn't serious.'' And how long,
    exactly, have you been developing for and using linux AND windows now?
    And you still believe that? Thus showing that even generally clued guys
    aren't immune to the occasional wetware problem.


    > and they do not respond to heat very well. At one point I swapped them
    > so that the higher-speed link used the less flaky NIC. And turned the
    > PS fan back on


    Ah, yes. :-)


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  9. Re: OBSD Bridge Minimal Hardware Requirements

    jpd wrote:
    > Begin
    > On 2006-05-04, void * clvrmnky() wrote:
    >> It's funny. This Realtek argument among BSD users is quite active,

    >
    > Possibly because they're dirt cheap and consequently ubiquitous. Many
    > people using current hardware won't notice the drawbacks because they
    > have the cycles to spare. If you don't have those...
    >
    > Then again, realtek type hardware (also compare winmodems), has happened
    > before, and will happen again:
    >
    > http://www.catb.org/~esr/jargon/html...carnation.html
    >
    >
    >> still. I recall reading something from de Raadt recently where he made
    >> a quality statement about Realtek devices in terms of a before/after.
    >> As in, they suck less now, and may even be recommended. I'll try to dig
    >> up the details.

    >
    > Please do. It doesn't surprise me though; no engineer worth his salt
    > would be proud of being told his designs are the absolute bottom of the
    > pile. The upside is that if you're there, improving isn't exactly hard.
    > Just look at what the competition is doing.
    >

    The recent KernelTrap interview he
    praises Realtek for not providing docs and having firmware-free wireless
    chipsets. He has singled out Realtek in at least one other place.

    I'm thinking maybe he's just giving them kudos for being nice people and
    sharing docs and making generally acceptable wireless chipsets.

    Well, if this is the case for NICs as well, then I guess OBSD can more
    easily code around bugs. Here's hoping.

    >
    >> Personally, I only have direct experience with xl and vr devices. The
    >> vr(s) are only recent, and I have not tested them much. The xl(s) seem
    >> to choke on higher amounts of data (of course, this may be a function of
    >> the driver and link-layer code)

    >
    > Possibly, altough ISTR 3c905 pre C series had various nasty problems.
    > My bad experiences with those devices are limited to the 3c920, which
    > supports checksum offloading, and the linux driver that helpfully logs
    > whenever the card reports a bad incoming TCP checksum (something the
    > software checksummer does not do), and developer-also-deploying type
    > persons that won't believe a failed checksum showing up in the logs
    > isn't the end of the world.
    >

    It turns out, I have one of each: a 3c905 on the outside and a 3c905C on
    the inside. If memory serves, they used to be in opposite positions
    which would have made the internal one the 3c905.

    At any rate, since swapping them I have not had obvious problems, but I
    suspect the 3c905 on the outside is the source of the errors being
    logged under higher data rates (sorry, I do not have the logs handy, so
    this may be complete bull****).

+ Reply to Thread