OpenBSD Journal

OpenBSD runs great on Soekris 5501

Contributed by deanna on from the just-works(TM) dept.

Henrik Kramsh°j writes:

I got my Soekris net5501 today and immediately started checking it out and installing OpenBSD on it. The short story is that they couldn't deliver the hard disc mounting kit until next week, but it works flawlessly so far.

I wrote some things about it on my blog - in Danish! but I guess you can recognize the dmesg output and the openssl speed readings anyway.

Permalink to danish blog entry

(Comments are closed)


  1. By Anonymous Coward (81.165.220.56) on

    By the way, any news about Jacec's book?

    1. By Anonymous Coward (64.132.1.80) on

      > By the way, any news about Jacec's book?

      I got an email earlier this week saying the money will be refunded.

  2. By Marc Balmer (213.189.152.34) on www.vnode.ch

    Two other boards that I happen to have here using the same AMD Geode LX-800 / CS5546 combo work fine as well: The WebDT 186 and the PC-Engines ALIX.1B board.

    Not all devices are supported, though, on AMD Geode LX systems, eg. the wathdog timer.

    AMD Geode LX is supported since OpenBSD 4.0-stable (4.0-release will not boot).

    1. By Anonymous Coward (24.201.102.185) on

      > soekris-5501-dmesg-GENERIC.txt

      glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES

      Is this what it looks like? on-die RNG & AES acceleration?

      1. By sthen (85.158.44.149) on

        > glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
        >
        > Is this what it looks like? on-die RNG

        Yes, and also AES acceleration. Wim was kind enough to run openssl speed on a 5501 for me:

        # openssl speed -elapsed -evp aes128
        [...]
        The 'numbers' are in 1000s of bytes per second processed.
        type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
        aes-128-cbc        791.10k     2922.25k     9091.10k    19639.68k    29278.20k
        By way of comparison I have a WRAP.1E (Geode sc1100 system, similar to 4801), which looks like this for the same benchmark:
        aes-128-cbc       2078.39k     2536.35k     2700.04k     2752.63k     2740.29k

        1. By sthen (85.158.44.149) on

          > > Is this what it looks like? on-die RNG & AES acceleration?
          ...
          > > Is this what it looks like? on-die RNG
          >
          > Yes, and also AES acceleration.

          ahh, undeadly.org quoting of comments containing '&' strikes again! (-:

      2. By Greg Mortensen (TheVision) thevision@pobox.com on http://pobox.com/~thevision

        > Is this what it looks like? on-die RNG & AES acceleration?

        Just a minor nit: it's not on-die (like VIA CPUs), but a PCI device that requires a lot more than just a couple of CPU instructions to make it work (read: it's much slower).

  3. By Anonymous Coward (75.85.80.55) on

    Would these be able to saturate a 1Gbit ethernet connection if acting as a simple home router?

    1. By Anonymous Coward (69.3.44.234) on

      > Would these be able to saturate a 1Gbit ethernet connection if acting as a simple home router?

      It has 4 10/100 Mbit nics. How the hell is it supposed to saturate a 1Gbit connection?

      In short: Duh, NO.

      1. By Darren Tucker (dtucker) on

        > > Would these be able to saturate a 1Gbit ethernet connection if acting as a simple home router?
        >
        > It has 4 10/100 Mbit nics. How the hell is it supposed to saturate a 1Gbit connection?

        Well it does have a PCI slot that you could plug a gigabit card into.

        1. By Brad (brad) on

          > > > Would these be able to saturate a 1Gbit ethernet connection if acting as a simple home router?
          > >
          > > It has 4 10/100 Mbit nics. How the hell is it supposed to saturate a 1Gbit connection?
          >
          > Well it does have a PCI slot that you could plug a gigabit card into.

          You could attain greater than 100 Mbps throughput but would still be limited by the 32-bit PCI bus and the limited CPU power.

        2. By Anonymous Coward (71.234.149.35) on

          > Well it does have a PCI slot that you could plug a gigabit card into.


          That is true, but then the throughput is limited by the capability of the PCI bus, and the gigabit card will gobble up the bandwidth of the PCI bus.

          Why can't there be a gigbit NIC (with jumbo frame capability) closer to the main internal bus on these boxes? I mean, really, how many people are really going to assemble their own 4-port router with a max capability of 100mbps per port?



          1. By Anonymous Coward (64.81.82.25) on

            > Why can't there be a gigbit NIC (with jumbo frame capability) closer to the main internal bus on these boxes? I mean, really, how many people are really going to assemble their own 4-port router with a max capability of 100mbps per port?

            It's a small, low power, embedded system, made primarily for edge routing where a small low power box is desired. I never heard them advertising these to replace pc's or high power routers. Just like OpenBSD, a lot of its success is because it doesn't try to do everything for everybody.

          2. By sthen (85.158.44.148) on

            > I mean, really, how many people are really going to assemble their own 4-port router with a max capability of 100mbps per port?

            Plenty. In most places, if you can afford 100Mb/s, you can afford a faster router.

            1. By Anonymous Coward (71.234.149.35) on

              > > I mean, really, how many people are really going to assemble their own 4-port router with a max capability of 100mbps per port?
              >
              > Plenty. In most places, if you can afford 100Mb/s, you can afford a faster router.

              Not sure I understand the concept you are trying to convey.

          3. By Anonymous Coward (74.115.21.120) on

            > Why can't there be a gigbit NIC (with jumbo frame capability) closer to the main internal bus on these boxes? I mean, really, how many people are really going to assemble their own 4-port router with a max capability of 100mbps per port?

            Lots. Guess how many small/medium businesses have > 100Mbps connectivity? Not a whole hell of a lot. Yet they still need to have firewalls. These are ideal for this:

            1 port -> internet
            1 port -> LAN
            1 port -> DMZ
            1 port -> pfsync

    2. By Henrik Kramshoej (85.81.149.98) on

      > Would these be able to saturate a 1Gbit ethernet connection if acting as a simple home router?

      No, as said it has 100Mbit interfaces :-)
      But running iperf -s on the default snapshots install said this:
      $ iperf -s
      ------------------------------------------------------------
      Server listening on TCP port 5001
      TCP window size: 16.0 KByte (default)
      ------------------------------------------------------------
      [ 4] local 10.0.47.2 port 5001 connected with 10.0.47.1 port 30988
      [ 4] 0.0-10.1 sec 112 MBytes 93.8 Mbits/sec
      [ 4] local 10.0.47.2 port 5001 connected with 10.0.47.1 port 37776
      [ 4] 0.0-10.1 sec 112 MBytes 93.7 Mbits/sec
      [ 4] local 10.0.47.2 port 5001 connected with 10.0.47.1 port 4316
      [ 4] 0.0-10.1 sec 112 MBytes 93.7 Mbits/sec

      Network:
      Athlon64 X2 2GHz nfe1 10.0.47.1 to Soekris net5501-70 vr2 10.0.47.2

      will do some more tests with bridging and routing while having a beer :-)

      Great thanks to the OpenBSD developers, the network performance improvements really makes a difference for me!

      1. By gixxer john (70.196.124.80) on

        nice to know it soekris can fill a 100mbit pipe now. :)

  4. By Anonymous Coward (204.249.220.101) on

    Does the onboard nic support jumbo frames?

    1. By Anonymous Coward (199.250.8.220) on

      > Does the onboard nic support jumbo frames?

      That would require Gigabit interfaces, which as previous posters pointed out, the 5501 does not have.

      1. By Anonymous Coward (198.175.14.193) on

        > > Does the onboard nic support jumbo frames?
        >
        > That would require Gigabit interfaces, which as previous posters pointed out, the 5501 does not have.

        Jumbo does not necessarily require gigabit. It simply requires a chip with jumbo frame capability. The newer revisions of the via chips (like the 6105m used in the soekris 5501) may have some jumbo capability (maybe not 9k frames, but 4k? for instance)

        1. By Brad (brad) on

          > > > Does the onboard nic support jumbo frames?
          > >
          > > That would require Gigabit interfaces, which as previous posters pointed out, the 5501 does not have.
          >
          > Jumbo does not necessarily require gigabit. It simply requires a chip with jumbo frame capability. The newer revisions of the via chips (like the 6105m used in the soekris 5501) may have some jumbo capability (maybe not 9k frames, but 4k? for instance)

          In the real world it DOES require Gigabit. Even if some vendor was stupid enough to make such a non standard 100 Mbps chipset, what good would it do you when you go to plug it into your 100 Mbps switch and the switch drops all of your oversized frames?

          1. By henning (213.39.157.138) on

            > In the real world it DOES require Gigabit. Even if some vendor was stupid enough to make such a non standard 100 Mbps chipset, what good would it do you when you go to plug it into your 100 Mbps switch and the switch drops all of your oversized frames?

            several switch vendors support jumbos on fast ethernet ports. I am certain about the Extreme Networks Black Diamond and Summit i-series (1/5/7/48i).

            that said, jumbos are completely useless until there is some kind of link-layer mtu discovery.

            1. By Brad (brad) on

              > > In the real world it DOES require Gigabit. Even if some vendor was stupid enough to make such a non standard 100 Mbps chipset, what good would it do you when you go to plug it into your 100 Mbps switch and the switch drops all of your oversized frames?
              >
              > several switch vendors support jumbos on fast ethernet ports. I am certain about the Extreme Networks Black Diamond and Summit i-series (1/5/7/48i).
              >
              > that said, jumbos are completely useless until there is some kind of link-layer mtu discovery.

              All of those switches have Gig ports. Can you point out a switch with ONLY 100 Mbps port which supports Jumbos?

              1. By Brad (brad) on

                > > > In the real world it DOES require Gigabit. Even if some vendor was stupid enough to make such a non standard 100 Mbps chipset, what good would it do you when you go to plug it into your 100 Mbps switch and the switch drops all of your oversized frames?
                > >
                > > several switch vendors support jumbos on fast ethernet ports. I am certain about the Extreme Networks Black Diamond and Summit i-series (1/5/7/48i).
                > >
                > > that said, jumbos are completely useless until there is some kind of link-layer mtu discovery.
                >
                > All of those switches have Gig ports. Can you point out a switch with ONLY 100 Mbps port which supports Jumbos?

                I should also point out you can do Jumbos with most Gig NICs in 100 Mbps mode as well, where Jumbos are supported. I haven't seen a 100 Mbps chipset which can do Jumbos (so far)

              2. By henning (80.171.10.47) on

                > > > In the real world it DOES require Gigabit. Even if some vendor was stupid enough to make such a non standard 100 Mbps chipset, what good would it do you when you go to plug it into your 100 Mbps switch and the switch drops all of your oversized frames?
                > >
                > > several switch vendors support jumbos on fast ethernet ports. I am certain about the Extreme Networks Black Diamond and Summit i-series (1/5/7/48i).
                > >
                > > that said, jumbos are completely useless until there is some kind of link-layer mtu discovery.
                >
                > All of those switches have Gig ports. Can you point out a switch with ONLY 100 Mbps port which supports Jumbos?

                that is not the point. they DO support jumbos on 100MBit/s ports.

  5. By Anonymous Coward (12.158.188.186) on

    Any reason soekris 4801 is way faster compared to 5501 on openssl speed benchmark?
    I get almost identical to 4801 results on my WRAP, so hifn is not the reason.

    1. By Anonymous Coward (198.175.14.193) on

      > Any reason soekris 4801 is way faster compared to 5501 on openssl speed benchmark?
      > I get almost identical to 4801 results on my WRAP, so hifn is not the reason.

      You are misreading the results. The 5501 is "way" faster for larger size chunks on the hardware accelerator (which is ALWAYS used unless you turn it off by sysctl or UKC). The 4801 is faster for smaller chunks on the host cpu. If you've been paying attention, you would realize that NONE of the crypto accelerators are any faster than the host CPU for small chunk crypto, and they are usually slower. That may be a software/driver problem, or it may simply be that the setup time is too expensive for small chunk operations on most accelerators no matter how you do it. The NetBSD guys seem to think there is some room for optimization in the glxsb driver that they recently ported over, but "the proof is in the pudding"

      It would be nice if openssl could be "optimized" to keep small chunk operations on the host CPU and only offload larger chunk operations.

      1. By Anonymous Coward (12.158.188.186) on

        > > Any reason soekris 4801 is way faster compared to 5501 on openssl speed benchmark?
        > > I get almost identical to 4801 results on my WRAP, so hifn is not the reason.
        >
        > You are misreading the results. The 5501 is "way" faster for larger size chunks on the hardware accelerator (which is ALWAYS used unless you turn it off by sysctl or UKC). The 4801 is faster for smaller chunks on the host cpu. If you've been paying attention, you would realize that NONE of the crypto accelerators are any faster than the host CPU for small chunk crypto, and they are usually slower. That may be a software/driver problem, or it may simply be that the setup time is too expensive for small chunk operations on most accelerators no matter how you do it. The NetBSD guys seem to think there is some room for optimization in the glxsb driver that they recently ported over, but "the proof is in the pudding"
        >
        > It would be nice if openssl could be "optimized" to keep small chunk operations on the host CPU and only offload larger chunk operations.

        What caught my attention is that my pc-engines WRAP that has almost exact hardware as soekris 4801, but without hifn, produces same results, which are way higher than 5501s. see http://pastebin.com/934757
        It would make sense to me if 5501 with its faster cpu and on die glxsb would show higher numbers. On the other hand, if you're saying that 8192 byte chunks aren't large enough, I'd love to see benchmark results with glxsb turned off then.

        1. By Anonymous Coward (213.189.152.34) on

          the soekris 4801 has not hifn, either.

        2. By Anonymous Coward (204.80.187.11) on


          > What caught my attention is that my pc-engines WRAP that has almost exact hardware as soekris 4801, but without hifn, produces same results, which are way higher than 5501s. see http://pastebin.com/934757
          > It would make sense to me if 5501 with its faster cpu and on die glxsb would show higher numbers. On the other hand, if you're saying that 8192 byte chunks aren't large enough, I'd love to see benchmark results with glxsb turned off then.

          I'm not sure what the URL you posted has to do with anything. Who cares what the 4801 does in software by itself? If you look at the speed of the AES operation (the only operation that glxsb speeds up through OpenSSL) you will notice that the speed STAYS ROUGHLY THE SAME in software no matter what the chunk size is. If you look at AES operations on an accelerator, the speed INCREASES SIGNIFICANTLY AS THE CHUNK SIZE INCREASES.

          As our short crypto accelerator history teaches us, any side-by-side comparison of a CPU with accelerator and the same CPU without the accelerator will show the accelerator being slower on small chunks and faster on large chunks. Whether the cut-off is 8k chunks or 16k chunks, I don't know. I'm sure it is dependant on the hardware setup (e.g. some accelerator chips may handle smaller chunks faster than others because they can setup the crypto operation more quickly.) It also has to depend on driver efficiency and that leads to more obscure factors that would take time to figure out.

          In this case, the glxsb is significantly faster than any similar operation with software alone, but only for larger chunks. It is significantly slower for small chunks. It has nothing to do with net4801 vs net5501. If you turn off glxsb and do side-by-side comparisons of the CPUs themselves, you will find the net5501 to be faster for every test. Given that the 5501 has twice the clock speed, more cache and faster busses than the 4801, if you didn't see a 50% improvement in software-software comparisons, THAT would be interesting. The comparison of a software accelerator with a hardware accelerator is NOT interesting in this context.

        3. By sthen (85.158.44.148) on

          > What caught my attention is that my pc-engines WRAP that has almost exact hardware as soekris 4801

          Hmm, well actually for some reason WRAP.1E is a fair bit (approaching 10Mb/s when I tried last year) faster than net4801 on some tests of ethernet performance (NPtcp, running on the box itself).

          > produces same results, which are way higher than 5501s.

          What exactly is way higher? AES-128 (very useful for ipsec, and default for SSHv2 in OpenSSH) at 256 byte is 4x faster on 5501 than WRAP.1E. Push the packet size up and it's much better.

  6. By Martin Schr÷der (195.4.46.96) martin@oneiros.de on http://www.oneiros.de

    I can't find any absolute performance numbers for the Geode LX. How fast is it compared to a K6-III?

    1. By sthen (85.158.44.149) on

      > I can't find any absolute performance numbers for the Geode LX. How fast is it compared to a K6-III?

      I think you'll have to bench it on specific tasks you're interested in. Compared to K6-III, there's more L1 cache, less L2 cache, and a different system architecture (some things done with separate hardware on normal systems are done on the cpu here - read up about VSA if you care, laptop.org mailing lists have some details, and of course AMD data sheets). Geode GX/LX are based around MediaGX (ex-Cyrix), not the K6 range.

  7. By Julian Leyh (68.33.104.179) julian@vgai.de on

    I received my Soekris net5501-70 with case today and I must say, I love it :)

    The only thing I don't like is the SATA port... It's unusable with the case, because if you put something in it, it's higher than the case :(

    Does anybody know how I could solve this? Maybe a short cable that has a tiny plug?

    1. By Anonymous Coward (24.201.102.185) on

      > I received my Soekris net5501-70 with case today and I must say, I love it :)
      >
      > The only thing I don't like is the SATA port... It's unusable with the case, because if you put something in it, it's higher than the case :(
      >
      > Does anybody know how I could solve this? Maybe a short cable that has a tiny plug?

      Try a right-angle SATA plug.

      1. By Julian Leyh (129.2.12.68) julian@vgai.de on

        > Try a right-angle SATA plug.

        OK, will try to find something suitable...


        Another question about net5501 and SATA - is there some magic to make it boot or recognize my disk?

    2. By daco (87.16.235.171) on


      > Does anybody know how I could solve this? Maybe a short cable that has a tiny plug?

      http://www.coolerguys.com/840556028826.html

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]