Friday, April 24, 2009

Ubuntu Jaunty - half speed graphics, slower boot, slower login.

Well, well... after spending a night optimizing some graphics code I noticed I could upgrade to the new version of ubuntu... Jaunty 9.04 on my laptop.

After an hour and a half, of installing (which I had to come back to about 8 times because it had stopped to ask me questions mid way)... I came back to a new system.

Ya! I thought. Apparently a faster boot, and other such goodness... and all fresh packages as well!!!

However my boot time is now slower. It also takes longer for everything to start after login.

Also my graphics are half the speed they were before upgrade. This is non-3d stuff too... 3d 'accelerated' stuff takes a much larger hit.


Moral of the story? Don't believe the hype... and also wait until others have upgraded first before you do to try it out.

I think the graphics slow down is related to this bug ... reported in november last year.

So if you have intel graphics... DO NOT UPGRADE YET!!! If you do, everything will go really slow. If you have a laptop, chances are you have an intel graphics chip. Not really sure how the ubuntu people let such a massive performance regression affecting most laptop users get through.

Now... that graphics code I was working on before the upgrade... even slower now! hahaha. At least it sets me a new coding challenge. Fun ;)

I changed this in my /etc/X/xorg.conf

Section "Device"
Identifier "Configured Video Device"
Driver "intel"
Option "AccelMethod" "UXA"

I added the Driver, and Option lines... and now graphics are almost as fast as it was before in Ubuntu intrepid.

Also just tried my laptop with a second monitor attached... and it actually works ok now. Brilliant.

Update 2: after I made that xorg conf change, video playback is much smoother than even intrepid now... if only they autodetected the computers properly to add those 2 lines for everyone else with an intel chipset... not everyone knows how to edit xorg conf files.

Update 3: after an automatic update today, the xserver and compiz were upgraded. Afterwards video was slow again... using 90%/90%+ core1/core2.

After disabling compiz video was smooth again, and the cpu usage went down to 40%/60% core1/core2.

To disable compiz: 'right click on the desktop, select "Change Desktop Background", click "Visual Effects", click the "none" option'

Here's hoping the next update doesn't slow it down again.

pps. the link to open the bug in your web browser from the update manager seems broken. Luckily you can copy the bug link to clipboard and manually open the bug.

Update 4: a few people in the comments left some more tips and their experiences(generally happy with improvements). One related link is: From that page a link to which might be some use to people.

Another thing I noticed... my track pad is now much better. Before it used to trigger a mouse click sometimes when I was typing - and now it doesn't! Also the little up/down scroller works again(but not the left/right one).

One issue with my monitor plugged in(which now works at full res in this release) is that if I close the lid of my laptop, turn the monitor off, and then my laptop goes to sleep. However when I open the lid to my laptop the laptop screen doesn't come on. However, a work around is to make sure the external screen is on - and then the login appears on the external screen... and once logged on, the laptop screen can be turned on with the Fn-key + F8(CRT/LCD).

I had another xserver/video driver update, and this time things didn't slow down.

Sunday, April 12, 2009

Distributed testing - the easy way.

Distributed testing is easy.

Include your tests in your package, and then whoever can install your package can install your tests.

At pygame we have had much luck with including the tests with pygame.

Then people can just do "import pygame.tests;"

It makes distributed testing easy, since now any of your users can run all the tests without having to have anything else installed(like source code, and a development environment).

Then you need one machine to package your build for windows, and then it can be tested on lots of other windows machines. (same with mac). The builds are uploaded to the testing machines(that don't need a dev environment set up), and then tested there.

Cherrypy and numpy(numpy.test()) also include tests with their downloads, and including tests is in the original unittest white paper.

Testing bots.

Then creating a network of test bots is trivial. Upload your package to them, or have them download it using http, and then get them to run the tests - then upload the test results to a central server.

Rather than them have to install a development environment - they can just download a pre-packaged version and run the tests.

Users are now equipped to be testers.

Now all of your users can also be testers. However they install your package they can run your tests. They don't require the source code to run the tests.

If they install with a apt-get install, an easy_install, a windows installer, or a mac installer, they can run your tests.

Someone posts a bug, you can make a bug fix, then ask them to download your latest pre-release and get them to run "yourpackage.test()". Saves you and the bug reporter time.

So rather than having 1-20 testing machines you can now have 1000's of machines testing your code.

Put your tests in install
Have your tests run at the end of your:
make install

python install

Make them fail if they fail your tests. Every time someone installs, your tests are run :)

Then have your setup ask the user to upload to your test result collection web page.