Thanks to everyone for chiming in on my post. Here's a bit of follow-up I would like to contribute:
HALF-DUPLEX: Indeed, my assumption of cable connection as half-duplex was DEAD WRONG, and to confirm most of your retorts, most common flavors of internet connection indeed appear to be full-duplex, (although definitive information on the subject is conspicuously hard to find on the web). The take-home message is that some less common flavors are indeed half duplex, but most today (including mine) are indeed full-duplex. So why then the half-duplex-like behavior? Read on: EXPLANATION: A corrupted shaping policy?: PART A: By connecting my laptop DIRECTLY to my ISP's DOCSIS 2.0 modem I am able to get ALL (or essentially all) of the published upstream bandwidth while SIMULTANEOUSLY getting all of the published downstream bandwidth. My test method was to stagger two simultaneous online speed tests (One was speed test was streaming up while the other was streaming down). I assume this to be a valid test. PART B: Once confident that the Internet connection was not the bottleneck, I re-connected the DOCSIS modem to pfSense, and repeated the same test, naturally routing THROUGH PFSense (embedded on Soekris 5501). Just as I had originally observed, when I replicated the 'simultaneous 2-way' speed test (described above) I again observed the anomaly, in which the speed test performed far below the maximums of the shaping policy and further still below the ISP maximums. CPU Utilization was merely 30% during the test. Keep in mind that this anomaly did NOT occur while running ONE-WAY-AT-A-TIME speed test (First up, THEN down). In other words, the one-direction-at-a-time speed test ran exactly at the specified maximums per my traffic shaping policy. PART C: To isolate the problem, I DISABLED the traffic shaping policy, and found that the 2-way speed test ran just as it should--exactly as I had observed with the direct modem connection. I re-enabled the shaping policy, and the anomaly returned. Rebooting pfSense had not remedied the situation on the old policy Part D: Suspecting corruption, I deleted the shaping policy, and re-created the exact same policy 'from scratch'. The newly created version of the old shaping policy behaved 'properly' without the described anomaly as originally described. The simple shaping policy: 3480 down, 1280 up, VoIP prioritized & guaranteed @ 768K, VoIP provider is Asterisk on local subnet, no other policy attributes. DISCUSSION: I don't have any theories to explain this. With the current 'fixed' policy, I do notice that the up/down bandwidth is very slightly penalized while running traffic at policy maximum in the opposite direction (about 10% below running traffic alone), but I consider that to be normal by-product of non-specific resource constraints of the platform and policy. Comments welcome. -Karl Fife --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
