Contributed by deanna on from the just-works(TM) dept.
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)
By Anonymous Coward (81.165.220.56) on
Comments
By Anonymous Coward (64.132.1.80) on
I got an email earlier this week saying the money will be refunded.
By Marc Balmer (213.189.152.34) on www.vnode.ch
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).
By Henrik Kramshoej (85.81.149.98) on
Comments
By Anonymous Coward (24.201.102.185) 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 & AES acceleration?
Comments
By sthen (85.158.44.149) on
>
> 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:
Comments
By sthen (85.158.44.149) on
...
> > Is this what it looks like? on-die RNG
>
> Yes, and also AES acceleration.
ahh, undeadly.org quoting of comments containing '&' strikes again! (-:
By Greg Mortensen (TheVision) thevision@pobox.com on http://pobox.com/~thevision
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).
By Anonymous Coward (75.85.80.55) on
Comments
By Anonymous Coward (69.3.44.234) on
It has 4 10/100 Mbit nics. How the hell is it supposed to saturate a 1Gbit connection?
In short: Duh, NO.
Comments
By Darren Tucker (dtucker) on
>
> 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.
Comments
By Brad (brad) on
> >
> > 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.
By Anonymous Coward (71.234.149.35) on
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?
Comments
By Anonymous Coward (64.81.82.25) on
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.
By sthen (85.158.44.148) on
Plenty. In most places, if you can afford 100Mb/s, you can afford a faster router.
Comments
By Anonymous Coward (71.234.149.35) on
>
> 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.
By Anonymous Coward (74.115.21.120) on
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
By Henrik Kramshoej (85.81.149.98) on
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!
Comments
By gixxer john (70.196.124.80) on
By Anonymous Coward (204.249.220.101) on
Comments
By Anonymous Coward (199.250.8.220) on
That would require Gigabit interfaces, which as previous posters pointed out, the 5501 does not have.
Comments
By Anonymous Coward (198.175.14.193) on
>
> 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)
Comments
By Brad (brad) on
> >
> > 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?
Comments
By henning (213.39.157.138) on
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.
Comments
By Brad (brad) on
>
> 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?
Comments
By Brad (brad) on
> >
> > 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)
By henning (80.171.10.47) on
> >
> > 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.
By Anonymous Coward (12.158.188.186) on
I get almost identical to 4801 results on my WRAP, so hifn is not the reason.
Comments
By Anonymous Coward (198.175.14.193) on
> 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.
Comments
By Anonymous Coward (12.158.188.186) on
> > 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.
Comments
By Anonymous Coward (213.189.152.34) on
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.
By sthen (85.158.44.148) on
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.
By Martin Schröder (195.4.46.96) martin@oneiros.de on http://www.oneiros.de
Comments
By sthen (85.158.44.149) on
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.
By Julian Leyh (68.33.104.179) julian@vgai.de on
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?
Comments
By Anonymous Coward (24.201.102.185) on
>
> 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.
Comments
By Julian Leyh (129.2.12.68) julian@vgai.de on
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?
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