I have been pondering for some time getting a new core router, and a

recent question on HP Procurves vs Soekris boxes has kicked me into

thought. I have some more general questions:
I recall hearing tell (on here I think) that amd64 is a better arch for

routing, because of better interrupt handling or somesuch. Is this true?
I am under the impression that if I want to do BGP, I need 1GB of RAM

for the routing tables and whatnot. Given RAM is so cheap, and I'd like

some future-proofing, is there any use in getting 2G instead?
Is PF capable of making good use of multiple processors with GENERIC.MP,

or am I better off with a single faster CPU? With say a Pentium 4 CPU,

am I better off with GENERIC and no hyperthreads, or GENERIC.MP and

hyperthreads?
I believe some of these questions have been addressed previously on this

list some time ago, but I was hoping I could get away with asking again,

on the grounds that the recent major changes to PF and resultant speed

increases may have changed the answers.
I'm currently looking at a Dell PE860 (1U, Quad core Xeon@2.4GHz, 1G

RAM) or a Dell PE SC1435 (1U, Dual core Opteron@2.4GHz, 1G RAM). They're

near enough the same price, so its just a question of what will be best

suited to running PF. My ignorant thought would be that 4 cores is

better than 2, but if PF only uses one core perhaps if the Opteron has

better interrupt handling then AMD would be the better choice. Is it

relevant that the Xeon has 2x4MB cache and the Opteron has 2x1MB?
Hopefully I have started on the right foot by asking the right questions...
Dave Wilson

hasn't that been talked about a dozen times lately...
why not... more than 2G probably hurts more than it helps, but 2g 
more cache could help quite a bit.

on the other hand, opteron has way faster memory access, that helps

too...
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

if you have the hardware you can test each arch to see which is  
PF cannot use multiple CPUs. The only advantage to MP on a router

would be better interrupt mappings or speeds. Again, you should test.

OpenBSD/amd64 used to be worse than OpenBSD/i386 on the same hardware,

I'm not sure about now - I haven't seen any recently published i386 vs
Depends which routes you take. You probably want 1GB if you receive

full routes. Given there's no cisco tax on RAM here, this is quite
bgpd uses a bunch of memory during 'bgpctl reload'; my normally

<100Mb RDE processes on full table routers rise to around 300M while

that happens - free ram on a 1G RAM box drops to around 480M with

views of 230k + 66k + 170k routes.
(This lasts for a couple of minutes with 2700-line filters on

an opteron 144).
So 1G is fine for now. YMMV depending on distance between the
Possibly, I only have single-core Opterons here so couldn't compare.

here's my view of full routes w/1GB of RAM and 4.2:
24164 root       2    0 8344K 8752K sleep    poll     13:00  0.00% bgpd

15092 _bgpd      2    0   44M   44M sleep    poll      9:46  0.00% bgpd

27914 _bgpd      2    0  936K 1296K sleep    poll      3:11  0.00% bgpd
load averages:  0.20,  0.17,  0.16                                     13:50:43

17 processes:  16 idle, 1 on processor

CPU states:  0.0% user,  0.0% nice,  0.2% system,  5.1% interrupt, 94.7% idle

Memory: Real: 75M/232M act/tot  Free: 769M  Swap: 0K/0K used/tot

Here's my view with two providers with full routes also running 4.2.
load averages:  0.17,  0.19,  0.11

38 processes:  37 idle, 1 on processor

CPU0 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100%

idle

CPU1 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100%

idle

Memory: Real: 141M/232M act/tot  Free: 1777M  Swap: 0K/8197M used/tot
  PID USERNAME PRI NICE  SIZE   RES STATE    WAIT      TIME    CPU COMMAND

11648 _bgpd      2    0  101M  102M sleep/0  poll      1:13  0.00% bgpd

29961 root       2    0 8368K 8872K sleep/0  poll      0:24  0.00% bgpd

 2970 _bgpd      2    0 1336K 1800K sleep/0  poll      0:18  0.00% bgpd
HW: Dell PE860, 2 GB mem, Dual Xeon CPU 3060 @ 2.40GHz
-Thomas

The stats at the end of 'bgpctl reload' are more interesting

if you want to size memory. Especially if you're running on

a secondary storage device you'd rather not swap to.
This is from a peering router (70 sessions, full table split across

a couple of it's neighbours plus about 3500 peer routes) - 1G ram,

amd64 (anyone else who experienced the pae pmap bug will understand;

I would probably choose i386 now...)
This is slightly old code as the box has been up for 6 months (yes,

bgpd is pretty reliable :)
slacking ->
load averages:  0.09,  0.11,  0.11                                               23:07:27

48 processes:  47 idle, 1 on processor

CPU states:  0.0% user,  0.0% nice,  1.0% system,  1.0% interrupt, 98.0% idle

Memory: Real: 249M/489M act/tot  Free: 500M  Swap: 0K/0K used/tot
  PID USERNAME PRI NICE  SIZE   RES STATE    WAIT      TIME    CPU COMMAND

15157 _bgpd      2    0 5844K 6740K sleep    poll    786:34  0.20% bgpd: session engine

27390 _bgpd      2    0   92M   93M sleep    poll    541:17  0.00% bgpd: route decision e

30126 root       2    0   17M   18M sleep    poll     80:31  0.00% bgpd: parent
just finishing up a reload ->
load averages:  0.97,  0.40,  0.22                                               23:09:12

48 processes:  1 running, 46 idle, 1 on processor

CPU states: 95.8% user,  0.0% nice,  1.4% system,  2.8% interrupt,  0.0% idle

Memory: Real: 444M/684M act/tot  Free: 305M  Swap: 0K/0K used/tot
  PID USERNAME PRI NICE  SIZE   RES STATE    WAIT      TIME    CPU COMMAND

27390 _bgpd     56    0  286M  287M run      -       542:56 98.39% bgpd: route decision e

30126 root       2    0   17M   18M sleep    poll     80:31  0.05% bgpd: parent

15157 _bgpd      2    0 5840K 6736K sleep    poll    786:34  0.00% bgpd: session engine
I wouldn't choose to run full tables with <1G.