On 14-11-07 04:58 PM, Paul Heinlein wrote:
I know you said that the CPU runs at ca. 5% load, but personally I'd
be unsure of a P-III-class machine at LAN speeds. What bus connection
do the NICs use? PCI? EISA? A 32-bit PCI bus operating at 33 MHz has a
theoretical maximum bandwidth of 133 Mb/s, and the 64-bit expansion
did little to improve that in any practical way. Plus, pre-MSI PCI
devices notoriously shared interrupts, slowing down device-to-devce
transfers. (And just to be cranky, I'll ask if any of the NICs in
shared PCI/ISA slots, which would squeeze performance even further.)
Dual P-III 1.1GHz is adequate. The 32-bit PCI bus has a theoretical max
of 133 MBytes/sec, not 133 Mbits/sec, which is substantially faster than
gigabit. The PCI-X standard extended it to 66MHz @ 64bits, quadrupling
the theoretical max to ~533MBytes/sec, more than adequate for the
dual-port, MSI-capable PCI-X ethernet card in there right now.
Have you tested that hardware in a routing capacity with non-pfSense
software?
I've tested that machine with that pfSense software - the performance
hit only occurs in one direction.
Does the pfSense box have good DNS service?
Yes. Redundant resolvers are directly attached to pfSense's WAN subnet.
Is the cabling flaky?
No. As I've said several times, the performance hit only occurs in this
specific configuration. Performance is perfectly fine for NAT'd SSH and
HTTP sessions initiated from the LAN side.
It's not a NIC or cabling issue, for an additional reason: every routing
interface on the pfSense box is a VLAN on an LACP trunk. If it were a
cabling or NIC issue, *all* traffic would by definition be affected,
including downloads initiated from the LAN side.
Is the pfSense box routing between subnets or just bridging? If the
former, what's there when pfSense is not "in the middle"? Another
router? Just a switch?
Routing, since it does NAT. When pfSense is not in-circuit (as
described), I'm doing one of two things: moving the client (and/or
server) to another VLAN off the primary router, and/or moving the client
and server together onto the same subnet.
My own testing has demonstrated quite clearly that the massive
performance hit only occurs on TCP sessions going *inbound* from the WAN
to the LAN (relative to pfSense's view of the world).
For now, I've simply moved the server semi-permanently; this was an
unusual and temporary configuration to begin with.
--
-Adam Thompson
[email protected]
_______________________________________________
List mailing list
[email protected]
https://lists.pfsense.org/mailman/listinfo/list
