Watchguard XTM 5 Series
-
Nice you caught something I missed there! :)
acpi_dsdt_load="YES" acpi_dsdt_name="/conf/e3400.aml"
dev.est.1.freq_settings: 2600/65000 2000/53800 1600/47500 1200/42000 dev.est.0.freq_settings: 2600/65000 2000/53800 1600/47500 1200/42000 dev.cpu.0.freq_levels: 2600/65000 2000/53800 1600/47500 1200/42000 dev.cpu.0.freq: 1200
Wrong values for my CPU but relatively easy fix!
Steve
Edit: Of course the 13x multiplier from the 3400 would be trying to drive an 8400 at 4.5GHz… which seems unlikely to succeed!
-
Does seem to actually work though:
[2.4.3-RELEASE][admin@xtm5.stevew.lan]/root: sysctl dev.cpu.0.freq=1200 dev.cpu.0.freq: 2600 -> 1200 [2.4.3-RELEASE][admin@xtm5.stevew.lan]/root: openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 26453752 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 7755366 aes-128-cbc's in 2.98s Doing aes-128-cbc for 3s on 256 size blocks: 2042954 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 518803 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 64976 aes-128-cbc's in 3.01s OpenSSL 1.0.2m-freebsd 2 Nov 2017 built on: date not available options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 141086.68k 166314.03k 174332.07k 177084.76k 176966.95k [2.4.3-RELEASE][admin@xtm5.stevew.lan]/root: sysctl dev.cpu.0.freq=2600 dev.cpu.0.freq: 1200 -> 2600 [2.4.3-RELEASE][admin@xtm5.stevew.lan]/root: openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 39744717 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 11696373 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 3068062 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 777909 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 97684 aes-128-cbc's in 3.01s OpenSSL 1.0.2m-freebsd 2 Nov 2017 built on: date not available options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 211971.82k 249522.62k 261807.96k 265526.27k 266049.61k
Actual result is 1.5x faster. I suggest that it is limited to a 9x multiplier on the 8400 so 6x at the "1200" setting and 9x at the "2600" setting. Actually 2GHz > 3GHz. Fun :)
Steve
-
Nice to hear! If you have a locked CPU then you are limited to what the minimum and maximum FID and VID values are for each given CPU. The Core Extreme CPUs as I understand are unlocked, so you could tweak the values freely.
I continued to tinker a bit. My latest changes implemented P-State dependencies _PSD, although that does not seem to make any obvious difference.
When I have a moment I will write down some quick notes 747Builder. Yes, I did update the microcode, but only for the CPUID that I am using. I don't see why one could not pick some other G41 based motherboard AMI BIOS that is recent and simply replace the whole CPU microcode module. Or you could do what I did and simply replace the microcode for the CPUID that you are using.
Peter.
-
Yes the max and min values for the E8400 (at least the one I have) are 9x and 6x so only 4 speeds. Unless it supports half speeds, I haven't tested.
Lot of warnings when you compile that. I think I went through it and fixed them last time around… too long ago! ::)
Steve
-
This post is deleted! -
Yes, seems to. But I've just seen a horrible typo! :-[
Edit: OK this looks better. Works OK here but YMMV. To be honest it doesn't do much from my testing. Maybe 1W less, at idle at least.
Steve
-
I have not attempted to fiddle with the rest of the code to correct the factory errors. I find the code very confusing, with my limited coding experience - I have done mostly C in the past. I tried the Intel reference manual but that was of not much help either. So if you recall how you fixed the errors it would be great to see a diff.
I have now confirmed that the BIOS (and the CPUs of course) support C1E state, so when idle the power is already as low as it can get even without SpeedStep. The benefit will be at partial loads, but I'm not sure how to quantify it. I looked at it this way - if I can spend a bit of time now and learn in the process it's worth it, even if it saves me only a few $ over the deployment time. At my rates here 1W a year is about $1 saved ::)
-
$1, it all counts! ;D
I was never really doing it for the power saving. That was the same conclusion I came to about C states. My own coding skills are nothing special, I think used trial and error last time.
Steve
-
This post is deleted! -
This post is deleted! -
Has anyone got 2.4.3 update working on XTM 5 yet? For me 2.4.2 update works fine. But if i try updating from 2.4.1 to 2.4.3 the unit stops booting. Any ideas?
-
@747builder: Yes. Loading the compiled .aml file at boot works as long as you're running a BIOS with Speedstep unlocked and enabled.
@diesel678: Yes, running 2.4.3 here. Had no issues upgrading.
Edit: Typo
-
I measured my youngest (manufactured in 2015) XTM5 box power consumption with the Q9505S CPU in all power states with all cores loaded using mprime. This unit is also equipped with 80+ PSU made by FSP, as opposed to my other two units that have Seventeam PSUs. The idle power consumption on this box is only 37W.
But in my measurement I also discovered why Lanner / WatchGuard might have disabled Speedstep. Basically, it looks like the box power consumption savings are smaller than the extra processing time required by the CPU caused by reduced frequency, resulting in net power consumption increase rather than decrease! See the attachment.A good practical case study would be to measure steady state power consumption of a XTM5 box in actual installation with both BIOS configurations. Like a unit doing all its routing / firewalling / UTM duties under controlled traffic…
Edit: I had a momentary lapse of reason and the numbers in the attachment are obviously incorrect, since they assume that when the box is idle it consumes 0W as opposed to 37W. I will post corrected numbers later tonight, but there is a notable overall power saving, so implementing SpeedStep remains worthwhile.
![XTM5 Speedstep Power.jpg_thumb](/public/imported_attachments/1/XTM5 Speedstep Power.jpg_thumb)
![XTM5 Speedstep Power.jpg](/public/imported_attachments/1/XTM5 Speedstep Power.jpg) -
Ok, fresh off the press, here are the corrected power consumption numbers and net energy use for XTM5 with Q9505S in each available processor power state. Note that I was able to load the CPU more consistently by selecting a different mprime torture workload and I repeated each test several times to eliminate measurement variability. Also note that I reformatted the table to make it easier to understand. The numbers look very good and I will definitely keep Speedstep enabled in my deployed box. Under partial loads the energy savings are substantial!
Peter.
Edit: Cleaned-up the attached image for additional clarity.
![XTM5 Speedstep Energy Usage.jpg_thumb](/public/imported_attachments/1/XTM5 Speedstep Energy Usage.jpg_thumb)
![XTM5 Speedstep Energy Usage.jpg](/public/imported_attachments/1/XTM5 Speedstep Energy Usage.jpg) -
Nice! Guess I'll leave it enabled then. ;)
I'll do it anyway just to see how it affects stability, if at all.
Steve
-
I've read in a different thread that you do not need to flash the bios on an XTM 505 if you use a hard drive to boot pfsense. I can get the hard drive to boot on a different machine but on my XTM 505 it boots up shows me the bios and just plays a weird post jingle. When I get into bios everything is still view only. So I'm guessing I will have to flash it. Is there a particular bios I should flash with?
-
Yes, it should be possible to boot without flashing the BIOS. I may have already unlocked mine before I put an SSD in there. It certainly boots a CF card without any change.
Either the image I tweaked ages ago or t-rexky's image linked above should unlock the options and allow you to choose what to boot from.
There are details on flashing it earlier in this thread.
Be aware that flashing your BIOS is always inherently risky and that doing so with an image you downloaded from a forum even more so. ;) Your box may end up a brick etc etc
Steve
-
Yes, it should be possible to boot without flashing the BIOS. I may have already unlocked mine before I put an SSD in there. It certainly boots a CF card without any change.
Either the image I tweaked ages ago or t-rexky's image linked above should unlock the options and allow you to choose what to boot from.
There are details on flashing it earlier in this thread.
Be aware that flashing your BIOS is always inherently risky and that doing so with an image you downloaded from a forum even more so. ;) Your box may end up a brick etc etc
Steve
Got it, thank you. The only CF card I have at the moment is the 1GB that came with the Watchguard. When I used Win32DiskImager to image that card with your rom it still wont boot to the CF card. Is there a size limitation or am I goofing something up?
-
What do you mean by "When I used Win32DiskImager to image that card with your rom it still wont boot to the CF card."? You need a CF card with a bootable OS on it, BSD or Linux, a file with the BIOS image and installed 'flashrom' tools to actually do the reading and writing of the EPROM…
Also, the XTM5 boxes boot from SATA devices if there is no CF card installed without a need to flash the BIOS, so there is something else gone south with your attempts. So, unchanged factory BIOS with factory settings should successfully boot a SATA drive as long as you remove the CF card. All you need to do is unplug the CF card and plug-in the SATA drive, then power-up.
-
What do you mean by "When I used Win32DiskImager to image that card with your rom it still wont boot to the CF card."? You need a CF card with a bootable OS on it, BSD or Linux, a file with the BIOS image and installed 'flashrom' tools to actually do the reading and writing of the EPROM…
Also, the XTM5 boxes boot from SATA devices if there is no CF card installed without a need to flash the BIOS, so there is something else gone south with your attempts. So, unchanged factory BIOS with factory settings should successfully boot a SATA drive as long as you remove the CF card. All you need to do is unplug the CF card and plug-in the SATA drive, then power-up.
Ok, obviously I'm being a dummy about the BIOS then. Thanks for the info. I guess I still have some troubleshooting to do with the SSD then.. I can boot pfsense if I plug the SSD into another machine. But for whatever reason the Watchguard just sits there stuck at the different startup options.