M4300 feels sluggish with default EDP.

[rosmaniac]

Ok, in the thread https://osxlatitude.com/index.php?/topic/3078-m4300-no-ethernet/ a set of files are posted, and a bit of discussion occurred about M4300 performance relative to D820 with default EDP, and the extreme performance boost presented by the use of the MBP5,1 SMC and SMBios, along with some other kext changes.  Please see that thread for the files, context, and such.  Also see the article on performance tuning with FakeSMC and SMBios, http://www.osxlatitude.com/tuning-performance-with-fakesmc-smbios-plist/

 

Now, I'm getting ready to build my second M4300 into a benchmarking rig, but before I put out the effort to do so I wanted to see if it was worth it to get a completely apples-to-apples comparison.  So I ran XBench 1.3 in three different scenarios:

 

1.) On my D820 at home running Lion;

2.) On my M4300 running ML and the default EDP kext set/SMBios setting (MBP3,1)

3.) On that same M4300 running Mav and the MBP5,1 SMBios and kext set with native speedstep.

 

Now, I know that those benchmarks are not exactly apples-to-apples, but they give me enough information that I'll post the composite numbers here, and then I'm going to build my benchmarking rig over the next weeks.  I have a spare Seagate Momentus 7200RPM 500GB drive, and I'm going to either create seven or nine partitions:

 

1.) MavE (EDP default)

2.) MavC (MBP5,1 custom Extra)

3.) MLE (EDP default)

4.) MLC (MBP5,1 custom Extra if I can make that work with ML)

5.) LionE (EDP default)

6.) LionC (MBP5,1 custom Extra if possible)

7.) SLE (EDP default) (if doing this with 10.6 is even important)

8.) SLC (Custom MBP5,1 if at all possible)

9.) Data.

 

Yep, either a sextuple or octuple-booting system.  It will be interesting to see how Chameleon handles that.  Of course, I will have to be exceedingly careful doing the installs in the right order, and I've also gotta figure out that order.....

 

And I may only do quad boot, with just Mav and Lion, but I haven't decided.  I do have hardware that works only up to 10.6.8, and I have other hardware that only works up to ML (Tascam US-224 and 428 up to 10.6.8; Tascam US-144 for up to ML, although Tascam might possibly release for Mav, since their entire US-xxx line is out of commission on Mav right now (32-bit kexts.....)).

 

Anyway, the numbers that to me make this worthwhile to get true apples-to-apples (and the reason that I want Lion on the M4300, both EDP default and the MBP5,1 custom) is the comparison between the D820 (limited to Lion unless you want to go to great lengths and do odd things) with a T7400 CPU and the M4300 with the much much faster T9300 CPU.

 

Xbench produces a composite result of 51.32 on the D820, with a CPU composite of 69.44, a Quartz composite of 94.21, an OpenGL composite of 28.25 (35.83 FPS), and a User Interface composite of 57.05 (261.83 refreshes/second).

 

Ok, on ML on the M4300 with a 2.5GHz T9300 and the default EDP, Xbench composite is 86.71, CPU 158.37, Quartz 191.03, OpenGL 87.25, but a User Interface composite of 43.26 (198.53 refreshes per second).  That last number exposes just how slow the system feels, which for many things is noticeably slower than the D820 at a 433MHz slower clock and a Merom CPU versus the Penryn.  It's impressive that even when held back a bit the Penryn manages over twice the performance of the not-that-much-slower-clocked Merom.

 

On the tuned Mav install (MBP5,1) the M4300 really shows its speed potential, with a composite of nearly twice that of the default EDP on ML of 166.9, a CPU  of 180.05, a Quartz test of 187.94, an OpenGL of 111.89, and a User Interface Test of a blistering 240.67 (1K refreshes per second).  Now that's more like it, with the Penryn really shining at 2.5 times the speed of the Merom and the interface responsiveness clocking at a nearly five times the speed of the ML with default EDP on the same M4300 hardware, and four times the speed of the D820 (and it really is that noticeable in real use).

 

And I agree that perceived performance under real world use is more important than artificial benchmark numbers, but in this case the almost totally unusable performance (with programs that I use daily) of ML or Mav with the default EDP contrasted with the several times more responsive Mav with the MBP5,1 mod is a real eye-opener where the true magnitude of the difference is completely reflected by the benchmarks. 

 

While I don't have the Mav with EDP default numbers (and I really don't want to change anything with my main M4300 to test that!) at least the merit of having such a benchmarking/test rig is apparent.  Now, I use the ML numbers for the default EDP on the M4300, but Mav with the EDP default install felt slower than the ML with default EDP.

 

At least I'm not using the Win7 in a VM on OSX on a PC numbers.....

[Hervé]

Sorry, but what's the point of all this again? Because, you've confirmed things run as expected with tuned settings, so I'm not really following the purpose of those tests, especially with what you call "default EDP " and which we'll change very soon...

[rosmaniac]

The point is to illustrate that the EDP default is pretty poorly tuned, at least for M4300.  And I'm glad to see change in that on the horizon, and I want to be able to confirm improved performance in the default EDP.  After all, one of the draws of EDP over the rest is that there is model data that is supposed to be somewhat tuned for each supported model, no?  Incidentally, this isn't meant as a criticism of the project, just a desire to make it better.

 

And when I have my test rig built and in hand, I will be able to hopefully help confirm that what EDP builds for each model really is tuned.

 

Perhaps I'm odd, but I tend to think that a newer model with a faster processor should perform better in real world tasks than the older model with a slower processor.  I'll go the next step and state that I think it's a bug in the current model data that the performance isn't at least somewhat tuned.

 

I am willing to help check out different combinations, too, to try to find sane default model data for at least the M4300 (and maybe the D820, too, since it may not be running optimally).  And I'll again be looking forward to seeing the SVN commits come down.

 

EDIT.

 

Upon reading that, I see that I really didn't explain what I consider to be a 'default' EDP setup.  I consider a default EDP setup to be what an EDP build made by just selecting the model the normal way, and then doing the build without any customizations of any kind.  I'm not talking about bootpacks, here.

[Hervé]

I perfectly got what you mean, but we also already know what is required for our D series Latitude as partially listed in the following post:

https://osxlatitude.com/index.php?/topic/2673-performance-tuning-with-fakesmc/

 

This was not implemented in EDP because EDP, until now, uses a common set of kexts for all integrated systems and the performance tuning changes that concept. It therefore makes everything far more difficult to maintain and manage, notwithstanding the additional tests that the exercise requires.

 

An additional difficulty is the extremely rapid pace at which Kozlek makes new versions of the FakeSMC kext. We just can't keep up with it and EDP needs some degree of stability. We just can't re-test all our integrated models with every new FakeSMC release...

 

You should also take into consideration the fact that these benchmarking tools are far from being entirely reliable and you should not base performance evaluation on them. Eg: https://osxlatitude.com/index.php?/topic/2088-cant-restartshutdown-lion-or-mountain-lion/?p=15973.

 

Also note that comparing a system running Lion with a different system running ML is meaningless, if only due to the difference in graphics management within both OS X versions.

[rosmaniac]

Hervé,

 

I appreciate the additional information and your great work in these forums.

 

I've only put in the details that I have in order to support my initial assertion: the M4300 with Mavericks felt sluggish with the out of the box EDP build (as of SVN rev 762).  It felt slower than my previous D820.  And that's the bottom line.

 

It's great that there are customizations that can be done outside EDP, and I thank you for the pre-baked M4300 files.  But it does mean I've left EDP behind for anything in the future, as an EDP model build will wipe out what is working so wonderfully right now.  (Yeah, I know how to put it back....).

 

But the ordinary EDP user is not getting the performance that they could get; and, yeah, I see the difficulties with how to go about implementing that on the developer side, especially in light of the rapid updates to FakeSMC.  And I thoroughly understand the stability question (that's why my choice of Linux is CentOS, based on RHEL).

 

Please understand that I'm not complaining for myself by any means; I'm just trying to advocate for the newbie; even the seasoned PC user, Windows or Linux or other, is going to find OS X to be a bit arcane for a while (I certainly did, and I've been using, administering, and programming Unix systems for 26 years).

 

I'd like to help solve this in some way, and one thing I can do is set up a testbed for regression testing the default EDP builds for M4300 for each supported version of Mac OS.  Because, as you mentioned, testing is critical.  Much of the infrastructure for doing the customizations is already in place; EDP is already database-driven and highly configurable (I'm looking forward to seeing the latest developments, too, particularly any changes made in edp.sqlite3).  If you know what you need to modify and have the values for the appropriate places in FakeSMC and smbios.plist those can be database-driven.  No, that's not a small task. 

 

Barring the customizations, there has to be something else going on; it just doesn't make any sense that the substantially faster M4300 would feel slower than the D820, with both systems running the 'stock' EDP builds, and both on Lion (which is where I started with the M4300).

 

But I reserve the right to be wrong.  And if you and the rest of the OSXL crew just want me to shut up about it, well, I can do that too.  But I'd like to help improve the performance situation for the user who just uses the stock EDP build for M4300, if I can.

[Bronxteck]

thanks for the offer. EDP always has room for improvements. it has not gotten this far without them. it started as a bash script. EDP is pretty much capable of a lot of things. but time gets hard to find plus supporting over 80 machines and 4 os it gets intricate. what works for one os might not work well with another. then you have each update of each os. so what works lets say at 10.6.0 might not work at 10.6.8. same for the other 3 os's. now I'm sure there are some things that can be done like updating at least smbios models it is still a big task for the few coders we do have. then there is there time factor. we only have 5 coders. which have there own personal lives to attend too as well as help us in the community. each one has there forte in the edp development parts they do each does there specific part then need the others to implement. getting all 5 together sometimes is difficult as we are a global team. it involves many super late nights or no sleep to accomplish because of geographical diversity. we do this all for you our peers and community. and of our free will to help. what i can say about edp is that it helps generate knowledge and understanding to users that are not familiar with osx as it opens there horizons into a new and exciting endeavor. we all need to start somewhere EDP opens that door for you. with time and perseverance many of our users have excelled and returned to our community to also return the favor of helping struggling community members. and thats what we try to achieve. to make our community what it is strong, vibrant and courteous.

[rosmaniac]

Bronxtech,

 

I'll do what I can.  I understand the time issues, since I've been involved in some open source projects before, including one stint over a period of five years that, when I did step down, a number of people expressed surprise that I had done it all as a volunteer.  I also have several children and a full time job, and I understand the pressures, particularly in terms of support (it's amazing to me how pushy people can get for support of a free-to-them nature!  I still get e-mail 'demands' for fixes, and I haven't maintained that one package for several years!).

 

Within the four unique systems I have (all listed in my sig), what do you think needs the most attention?  I'm going to put forth the most effort into just looking and seeing what set of modules, within the normal EDP framework, produces the best out-of-the-box performance on M4300, and I'm working towards that first by setting up a multiinstall rig over the next few weeks.  I'll record my selections as I go, and then update my local edp.sqlite3 database and make sure the default on my system then matches what works. 

 

Anyway, I'll find it fun to learn some of this that is new to me, and I hope I'm able to provide some positive contributions back to the project.

[Hervé]

If you can, try and optimize performance on the Inspiron 9400 and Precision 690 as we have the others fully covered.

[rosmaniac]

Ok, can do.

 

And, yes, the 690 is on my list.  That will need a complete set of new model data, and will be a fun project.

 

Separate threads; I would assume posting results and such in the R&D section......