Performance with rc3 vs. rc1 (usenet) not as expected
-
Logs are kept in RAM and unless you have a very high level of blocked packets (like a DDoS attack against you) it has no performance impact on the system. The type of performance issues a firewall can induce (most commonly duplex mismatch, maxing out your CPU if it's very slow relative to bandwidth, driver issues) are universal, you won't get maximum performance with one protocol and not another. So it's highly unlikely to be firewall related. One exception to that - if you're using traffic shaping you can introduce limits on some protocols and not others. Best way to analyze network performance is to analyze a pcap of the affected traffic, comparing LAN and WAN simultaneously, as any performance degradation introduced by the firewall will result in packets coming in on LAN and not leaving WAN or vice versa.
-
@cmb:
The type of performance issues a firewall can induce (most commonly duplex mismatch, maxing out your CPU if it's very slow relative to bandwidth, driver issues) are universal, you won't get maximum performance with one protocol and not another.
While that is perfectly clear to me, it does not explain why in RC1, I had no such problems, and why my CPU is not maxed out.
So it's highly unlikely to be firewall related.
Well, connecting to my cable modem w/o pfsense yields in maximum throughput over this protocol.
One exception to that - if you're using traffic shaping you can introduce limits on some protocols and not others.
Please, I am not that dopey :D That's why I deleted all my traffic shaping first thing when I found the performance to be degraded and made sure there is no other traffic on the line.
Best way to analyze network performance is to analyze a pcap of the affected traffic, comparing LAN and WAN simultaneously, as any performance degradation introduced by the firewall will result in packets coming in on LAN and not leaving WAN or vice versa.
Will do that with RC3 and perhaps RC1 and post the results. Thanks!
-
Are you using anything such as snort, l7 filtering, traffic shaping, etc?
-
Today I noticed that my ftp transfers (downloading some huge psd files) appear to have halved in speed to what I used to see.
Download speeds today were around 60/mbit @ 5 - 10 % cpu usage.
Only a few weeks ago, speeds were a solid 100/Mbit @ around 10% cpu.
Possibly related, or a coincidence?No traffic shaping, no snort, no layer filtering.
-
Are you using anything such as snort, l7 filtering, traffic shaping, etc?
No, absolutely nothing in regard to extra packages or filtering/shaping.
I tried to install the 2011-6-15 version yesterday (pfSense-Full-Update-2.0-RC1-i386-20110615-0944) and did a factory reset, transfers were still slow.
Looking back in my logs, I had full bandwidth until I updated pfsense on the 2011-6-24 (of course, this information is absolutely useless to you as you don't know which version I had before that. Here's the bummer: me neither.).
Is there any mirror where I can get a snapshot older than 2011-6-15, perhaps from the beginning of May? I am quite sure I had some May 5th or something snapshot before.
-
Were any drivers changed from RC1 vs. RC3, particularly network drivers?
-
The em/igb driver was updated. Until this latest revision, people had been seeing several different failure conditions with the driver but it is now working for those who were having issues.
-
My pfSense machine uses an intel ET network card through ESXi, which provides pfsense with an intel e1000 virtual network card.
Am I correct in deducing that my issue could be with the EM driver?
Would it help to switch to another vm-driver? -
Possible, but not likely. You might be able to try the vmnetx driver (search elsewhere on the forum) but AFAIK the performance with/without VMware did not change at all between driver revisions since it uses the legacy code path, mainly igb cards were affected by the changes (but not all)
-
Thanks Jimp, I'll go check out the alternate driver.
Who knows, I've changed so much since I switched from an x700 to this new machine that I might have inadvertently changed some other value.
Still, that doesn't help the TS.
