DPI on 4 GB RAM system - Linkedin still does not open

I can confirm, this is still happening on EAP 2.

On a Intel J1900 with 4GB ram, using DPI with decryption, a good amount of websites doesn't open at all, and most of times i would get this error: "PR_END_OF_FILE_ERROR"

(Firefox on Linux) (SSL/TLS Inspection rule is set at, Maximum Compatibility.)

Upgrading to 8GB ram fixed almost all my issues with the DPI. But still, the overall performance on v18 is about ~45% of what i was getting on v17.5.x.

Thanks,

I can confirm, this is still happening on EAP 2.

On a Intel J1900 with 4GB ram, using DPI with decryption, a good amount of websites doesn't open at all, and most of times i would get this error: "PR_END_OF_FILE_ERROR"

(Firefox on Linux) (SSL/TLS Inspection rule is set at, Maximum Compatibility.)

Upgrading to 8GB ram fixed almost all my issues with the DPI. But still, the overall performance on v18 is about ~45% of what i was getting on v17.5.x.

Thanks,

Well, that has fast.

Same thing happened on v18 EAP 2, with 8GB ram. (Firefox Nightly on Linux.)

Refreshing the page a couple times, and it loads as expected:

But at least it took some time to happen with 8GB.

As the J1900 doesn't have the AES-NI instruction set, i wonder if you're overloading on it?

I wouldn't understand it, but i wonder if a process/cpu trace would be hitting some form of early termination.

Emile

Thanks Prism. I have the exact issue on Mac with Firefox, but even safari on iPhone and android phone browser are not working. You need to reload the page multiple times to get the page.

Upgrading the ram in my case is not possible as my system supports maximum 4 GB of ram.

Also, the home license cuts the ram at 6 GB so they need to fix the performance issue or upgrade the home license to 8 GB.

Regards

Emile on EAP1, with dpi enabled, ips service was crashing continuously, so they fixed the issue in eap2, but now in my case doesn’t make difference if I am using dpi or proxy. Pages do not load completely.

Hope to get a dev to look up into my XG next week.

Regards

CPU isn't the issue.

I'm currently using right now, Ryzen 2200g with 8GB DDR4 RAM, which is a bit overkill for a NGFW with only 240/120Mbit/s connection.

But the same thing that happens on my J1900, is happening with the Ryzen 2200g, a CPU that is at least 7x faster. And also have AES-NI.

What mostly impresses me is the performance issue on v18, while on v17.5 with the J1900 i could push 240/120mbit/s with almost everything on while using less than 50% of the CPU, on v18 not even my 2200g can push 240/120Mbit/s without snort killing the CPU.

SFVH_SO01_SFOS 18.0.0 EAP2# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 17
model name      : AMD Ryzen 3 2200G with Radeon Vega Graphics
stepping        : 0
microcode       : 0x810100b
cpu MHz         : 1728.810
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx hw_pstate sme vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr ibpb arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
bugs            : sysret_ss_attrs null_seg spectre_v1 spectre_v2
bogomips        : 6986.71
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

Hello Prism,

I think it's one of the very few times i've seen UTM/XG running on AMD hardware.

It does seem like we are having performance fluctuations EAP to EAP but unfortunately, the AMD hardware is not officially supported by Sophos, and if I remember correctly, nor has any optimisations for it.

The official Hardware compatibility only states Intel compatible hardware sadly :(

https://community.sophos.com/kb/en-us/118185

I would love to see AMD get more love but unfortunately I doubt it will in this space.

Emile

Unknown said:

It does seem like we are having performance fluctuations EAP to EAP but unfortunately, the AMD hardware is not officially supported by Sophos, and if I remember correctly, nor has any optimisations for it.

I understand that AMD isn't officially supported by Sophos.

But in the end, Sophos XG has made to run on x86 Hardware, and both AMD and Intel sells x86 chips, unless Sophos XG needs an set of CPU instructions that AMD doesn't have, you will probably have no issue running on AMD hardware.

I get some people will say: "Sophos made optimizations for Intel CPU's.", It just means Sophos uses Intel CPU's for their appliances. And of course that's the reason why they made improvements on it. But it doesn't means that won't run on AMD CPU's.

At the end, it still doesn't explain how I'm able to push 3.2Gbit/s of IMIX traffic on v17.5.9, with all features on. And on v18 i can barely push to 1.1Gbit/s, on a AMD Ryzen VM environment. (Used Cisco TRex for the tests. i don't believe it's necessary pictures right now.)

Also doesn't explain how an Intel CPU on v18 EAP 2, is getting less than 50% of the performance of v17.5.

Unknown said:

It does seem like we are having performance fluctuations EAP to EAP

Yes, we got an performance increase primarily on IPS, from v18 EAP 1 => v18 EAP 2. While on a single connection i could push ~320Mbit/s on v18 EAP 1, in v18 EAP 2 It's now ~430Mbit/s. But compared to v17.5.x, that still almost half of what i was getting.

I get some people will say: "It's an EAP, this is expected", but all I want is an official answer from Sophos explaining this. I've already made two posts about this, and got no good answer on it.

It feels like this issue is being ignored.

Sorry if here is the wrong post for this, but it's my little rant on v18 EAP performance.

But, AMD is intel compatible hardware, they run the same instruction set and Intel even licences some of AMDs instructions.

Ian

Ok, I didn't really want this to become an Intel vs AMD waterfight and only stated my original comment because Sophos will not support AMD platforms and including that data in your issue reports muddies waters.

AMD and Intel are inter-compatible on pretty much everything out there, they use (mostly) the same instruction sets and what you can do on one you can do on another. However, the instruction sets are just a specification of end result and it's how Intel/AMD have decided to get to the end result that makes it different between the two. An optimised code path on AMD may not be an optimised code path on Intel and vice versa. For example, Intel and AMD are both compatible with AVX256 at a minimum (thank you Zen 2) and both instructions sets have the same end result but Intel processes AVX256 wildly different to how AMD does both before and after they were compatible. Same result, different route.

As far as I know, the last time I spoke with someone knowledgeable on this, Sophos NSG products have only been optimised for Intel code paths. And because AMD is not Intel, any issues or errors working on the hardware will not be investigated.

Note: I never said it would not be compatible only that it was surprising it was being used and that it would not be supported.

As this can quite easily devolve into a fist fight as most Intel v AMD discussions end up, AMD can run Sophos software but whether you should is a question you can raise in the XG forum rather than the v18 EAP forum.

Back on topic, an answer from anyone at Sophos on this wild performance fluctuation matter would be nice.

Emile Belcourt