Isn't the Fusion chip a combined GPU/CPU?
It might require a lot more work than normal new hardware to get working.

Steve

Edit: It seems as though amd has already released opensource drivers for it though.

one ASUS AT5NM10-I and one Intel D425KT

If your choices are:

a. Use 2.0 which is fairly stable and about to hit RC1, and properly supports your hardware

-or-

b. Use 1.2.3 with hacked up drivers copied from another source or OS revision

I don't know about you, but I'd be leaning more toward 'a', since you are likely to introduce your own instabilities into 1.2.3 by going the 'b' route…

Ok.

I will perform the procedure.

Thanks for the help.

Assuming the contents of the HDD were not corrupt, then yeah that should work. The other limiting factor may be onboard NIC differences between the two systems. But as long as the assigned interfaces match up, it should work. And if they don't, it's just a matter of re-assigning the interfaces in the way you expect.

That'll easily max out your connection with normal Internet traffic. It will probably not be able to completely fill that pipe with VPN traffic terminated on the firewall, though it will get more than half your connection speed at least, maybe 35-40/5. Probably adequate unless you're in a scenario where you can actually get and need to get 60/5 over the VPN.

That's not x86 hardware, not supported.

@Night:

when in reality it's 54 divided by about 4 devices divided by 2 directions (making some assumptions about my average traffic both ways here) so it's 1/8 of what I would already consider slow. Learn something new everyday.

Worse than that even, "54" Mbps wireless can only transfer ~27 Mbps of actual traffic at best.

When Is 54 Not Equal to 54?
http://www.oreillynet.com/pub/a/wireless/2003/08/08/wireless_throughput.html

When doing some bandwidth testing recently I used the TTCP tool. It's available as a package from FreeBSD so easy to install on pfSense. Also there are versions for Windows and Linux so you will probably have other machines to run it on already. It runs client/server and generates and sinks traffic on the fly so it's not slowed by disk performance.

Steve

@jimp:

or it could be a driver bug due to them being shared.

Its a bad idea to share a level triggered interrupt (PCI device) with an edge triggered interrupt (ata and ISA devices). vr0 should be moved to its own IRQ or one shared with other PCI devices (USB, vr1, etc etc). There are often mechanisms in the BIOS for adjusting interrupt lines but they are usually very system specific. For example, you might have to specify something like "IRQ15 is not available to PCI".

@rancor:

I will soon got this toy to play with: http://www.applianceshop.eu/index.php/firewalls/opnsense/opnsense-pfsense-dualghz-19-appliance.html and It's going to be fun to see how much it will deliver.

Would be good to get a review when you get it.
I find it hard to believe that they are using standard DC barrel connectors for power. That implies you need an external power brick, which has it's advantages (normally more efficient, removes heat from the box), but seems a bit out of place in a rack. Mostly though those barrel connectors are so easy to pull out by accident. Just imagine running a patch cable and powering off your router by mistake! It's not like there aren't many other better DC connectors.

Steve

http://www.zdnet.com/blog/storage/ssd-reliability-lower-than-disks/1222

Some food for thought.  :o

Roy…

Hey guys,

There is some great information here for anyone setting up a PAPT2 behind a pfense box.

I did, however, finally solve my problem.

My box was put together in China from scrap parts I pulled together at a computer market.  Unfortunately, I can't find a decent quality NIC around here - which you will see was part of the problem

I have all my other interfaces filled up with working components in my house.  Unfortunately, the interface I was trying to connect my PAP to was an older NIC.  I had to use a cross over cable as well as change the NIC that the PAP was coming out of.

For some reason the NIC that I was using did not support data across a 10baseT/UTP connection (I wired the crossover cable myself, thus the UTP).  So I should have thought of the cross over cable right off the bat but I guess Im so used to working with newer NIC's that it's just not necisary - Also, the NIC that I had left over just didn't support the 10baseT/UTP, like I mentioned.

I got it solved but everyone's advice was very much helpful - furthermore, Im sure people who are looking for information on this will find it helpful in the future as well.

Cheers,
Brian

Hi Benntech,

Thanks for the really comprehensive answer to this, that's great.

I think I may re-review this, and perhaps wait till next quater when the new Atoms are out, and look at the available motherboards then…

Thanks again

thx, i`ll try this

Unfortunately it appears more complicated than that.
It now seems that if you have run the script at all then the rc.conf_mount_rw/ro commands become ineffective. This will either leave your system permanently R/O or if you issue another 'mount -u -w /' then permanently R/W. One for the devs I think. I started a topic in 2.0 feedback.

Steve

Edit: Too many threads with the same information.
See the main LCD thread for efforts to sort out this problem. Here.

I got done by this too. Luckily the online store I bought it from waived the re-stocking fee (which would usually apply, as this was an order-in part), so I paid the difference between this and the PCIe version. I swear I did my homework before buying it… just not enough, apparently.  ;D

Yep works great!
Have a look through the x550e thread for details on that box. (x550e, x750e, x1250e are the same)

Steve

@sirjeannot:

ghm > any tweaks? what extra services do you use?

Pretty much stock config - nothing fancy. Extra services are: Siproxd, blinkled (LED assignment) and an OpenVPN config - nothing spectacular but no performance killers such as Snort either (don't need it, have only very few open ports).
One aspect that might be important re config: I need VLANs both on the WAN side (my ISP expects tagged frames) and for the various LANs I have. It seems important that once you use VLANs on a given port to no longer assign the parent port to a network but only the VLANs. E.g. If you have LAN11, LAN12 - don't just tag/assign LAN12 to VLANID12 (aka eth1.12) and LAN11 to eth1. Nothing should be assigned to eth1 if there are VLANs on that port. Hence LAN11 must become a tagged VLAN as well and assigned to e.g. eth1.11.

What are you CPU / Mem loads like when you run into the maximum throughput?