Sunday, 30 September 2012
Cinnamon Performance -- It was Chrome's Fault
I've written lately about my struggles with sluggish Ubuntu and Mint desktops. Finally, I discovered that Chrome was the problem. At one point in my ramblings, I recommended using Mate instead of Cinnamon. Well, I'm happy to report that my slow Dell Vostro 1440 runs Cinnamon just fine, as long as I'm not running Chrome.
Long Fat Networks
Long fat networks are high bandwidth, high latency networks. "High latency" is relative, meaning high latency compared to a LAN.
I ran into the LFN phenomena on my last data centre relocation. We moved the data centre from head office to 400 kms from head office, for a round trip latency of 6 ms. We had a 1 Gbps link. We struggled to get a few hundred Mbps out of large file transfers, and one application had to be kept back at head office because it transferred large files back and forth between the client machines at head office and its servers in the data centre.
I learned that one can calculate the maximum throughput you can expect to get over such a network. The calculation is called the "bandwidth delay product", and it's calculated as the bandwidth times the latency. One way to interpret the BDP is the maximum window size for sending data, beyond which you'll see no performance improvement.
For our 1 Gbps network with 6 ms latency, the BDP was 750 KB. Most TCP stacks in the Linux world implement TCP window scaling (RFC1323) and would quickly auto tune to send and receive 750 KB at a time (if there was enough memory available on both sides for such a send and receive buffer).
SMB 1.0 protocols used by most anything you would be doing on pre-Windows Vista are limited to 64 KB blocks. This is way sub-optimal for a LFN. Vista and later Windows use SMB 2.0, which can use larger block sizes when talking to each other. Samba 3.6 is the first version of Samba to support SMB 2.0.
We were a typical corporate network in late 2011 (read, one with lots of Windows machines), and they were likely to suffer the effects of a LFN.
Note that there's not much you can do about it if both your source and destination machines can't do large window sizes. The key factor is the latency, and the latency depends on the speed of light. You can't speed that up.
We had all sorts of fancy WAN acceleration technology, and we couldn't get it to help. In fact, it made things worse in some situations. We never could explain why it was actually worse. Compression might help in some cases, if it gets you more bytes passing through the window size you have, but it depends on how compressible your data is.
(Sidebar: If you're calculating latency because you can't yet measure it, remember that the speed of light in fibre is only about 60 percent of the speed of light in a vacuum, 3 X 10^8 m/s.)
There are a couple of good posts that give more detail here and here.
I ran into the LFN phenomena on my last data centre relocation. We moved the data centre from head office to 400 kms from head office, for a round trip latency of 6 ms. We had a 1 Gbps link. We struggled to get a few hundred Mbps out of large file transfers, and one application had to be kept back at head office because it transferred large files back and forth between the client machines at head office and its servers in the data centre.
I learned that one can calculate the maximum throughput you can expect to get over such a network. The calculation is called the "bandwidth delay product", and it's calculated as the bandwidth times the latency. One way to interpret the BDP is the maximum window size for sending data, beyond which you'll see no performance improvement.
For our 1 Gbps network with 6 ms latency, the BDP was 750 KB. Most TCP stacks in the Linux world implement TCP window scaling (RFC1323) and would quickly auto tune to send and receive 750 KB at a time (if there was enough memory available on both sides for such a send and receive buffer).
SMB 1.0 protocols used by most anything you would be doing on pre-Windows Vista are limited to 64 KB blocks. This is way sub-optimal for a LFN. Vista and later Windows use SMB 2.0, which can use larger block sizes when talking to each other. Samba 3.6 is the first version of Samba to support SMB 2.0.
We were a typical corporate network in late 2011 (read, one with lots of Windows machines), and they were likely to suffer the effects of a LFN.
Note that there's not much you can do about it if both your source and destination machines can't do large window sizes. The key factor is the latency, and the latency depends on the speed of light. You can't speed that up.
We had all sorts of fancy WAN acceleration technology, and we couldn't get it to help. In fact, it made things worse in some situations. We never could explain why it was actually worse. Compression might help in some cases, if it gets you more bytes passing through the window size you have, but it depends on how compressible your data is.
(Sidebar: If you're calculating latency because you can't yet measure it, remember that the speed of light in fibre is only about 60 percent of the speed of light in a vacuum, 3 X 10^8 m/s.)
There are a couple of good posts that give more detail here and here.
Sunday, 16 September 2012
Ubuntu and Mint Very Slow
I've been struggling for some time with poor performance of Ubuntu, and now Mint, on my Dell Vostro 1440. Admittedly it's a cheap laptop, but in this day and age a Linux desktop should run decently on pretty much anything, as long as you're not using a lot of fancy desktop effects.
Running top I was seeing a lot of wait time. When the performance was really bad, I'd see over 90 percent wait time. Typically I'd be dipping into swap space when performance was bad, but it would be bad without swapping (I "only" have 2 GB of RAM). I would see this when running only Thunderbird and Chrome, although Chrome with a lot of tabs open.
I spent many frustrating hours Googling for performance issues on Ubuntu or Mint and didn't find anything really promising.
Finally, last weekend I was dropping off some old computer gear for recycling at our local Free Geek and saw a pretty sweet Dell laptop for sale. I started playing with it, partly to see how it performed. They sell used computers with Ubuntu, and Ubuntu comes with Firefox. Firefox was snappy as all get out, and on a lower powered CPU than mine at home.
So I went home and tried Firefox. It works great. So I started Googling performance problems with Chrome on Linux and got all sorts of hits. This one looks like it's turning into a bit of an omnibus bug report, but has some good info and links to other places.
It looks like one factor is that Google has made its own Flash viewer, since Adobe is no longer supporting new versions of Flash on Linux. Many people report disabling the Google Flash viewer helps, but it didn't work for me.
Others report that it is indeed due to memory usage of Chrome with many tabs. Others report that it has something to do with using hardware graphics rendering, that the hardware is actually slower. Still others report issues with Chrome scanning for devices, and particularly webcams.
My gut says it's a combination of things -- perhaps all of the above are involved, but you only see the performance problem when two or more of the factors coincide.
I haven't found a solution that works for me yet, so I'm somewhat reluctantly using Firefox. It's certainly a lot faster than it was two years ago. However, I miss the combined link and search field in Chrome, amongst other things. It does seem like Firefox has stolen most of Chrome's good ideas, so it's not as hard as I thought it might be to readjust.
Running top I was seeing a lot of wait time. When the performance was really bad, I'd see over 90 percent wait time. Typically I'd be dipping into swap space when performance was bad, but it would be bad without swapping (I "only" have 2 GB of RAM). I would see this when running only Thunderbird and Chrome, although Chrome with a lot of tabs open.
I spent many frustrating hours Googling for performance issues on Ubuntu or Mint and didn't find anything really promising.
Finally, last weekend I was dropping off some old computer gear for recycling at our local Free Geek and saw a pretty sweet Dell laptop for sale. I started playing with it, partly to see how it performed. They sell used computers with Ubuntu, and Ubuntu comes with Firefox. Firefox was snappy as all get out, and on a lower powered CPU than mine at home.
So I went home and tried Firefox. It works great. So I started Googling performance problems with Chrome on Linux and got all sorts of hits. This one looks like it's turning into a bit of an omnibus bug report, but has some good info and links to other places.
It looks like one factor is that Google has made its own Flash viewer, since Adobe is no longer supporting new versions of Flash on Linux. Many people report disabling the Google Flash viewer helps, but it didn't work for me.
Others report that it is indeed due to memory usage of Chrome with many tabs. Others report that it has something to do with using hardware graphics rendering, that the hardware is actually slower. Still others report issues with Chrome scanning for devices, and particularly webcams.
My gut says it's a combination of things -- perhaps all of the above are involved, but you only see the performance problem when two or more of the factors coincide.
I haven't found a solution that works for me yet, so I'm somewhat reluctantly using Firefox. It's certainly a lot faster than it was two years ago. However, I miss the combined link and search field in Chrome, amongst other things. It does seem like Firefox has stolen most of Chrome's good ideas, so it's not as hard as I thought it might be to readjust.
Installing Ruby on Rails on Linux Mint 13
A few months after my last post about installing Ruby on Rails, and much has changed. There was an issue with zlib so I had to flail around a bit. The following instructions are what I think I should have done:
Now create an application to test:
Browse to localhost:3000 and you should see the Rails default page.
- Run "sudo apt-get install zlib1g zlib1g-dev" in a terminal window
- Install the Ruby Version Manager (rvm) from these instructions
- Run "rvm requirements" in a terminal window
- Install all the packages the output of "rvm requirements" tells you to install (apt-get install...). You must do this before you start installing any rubies with rvm. If you don't, you may have all sorts of problems crop up later, like weird messages from irb ("Readline was unable to be required, if you need completion or history install readline then reinstall the ruby.")
- Do the following in a terminal window:
rvm install 1.9.3-p194 rvm --default 1.9.3-p194gem install rails sudo apt-get install sqlite sudo apt-get install libsqlite3-dev libmysqlclient-devsudo apt-get install nodejs Now create an application to test:
rails new testapp cd testapp rails server Browse to localhost:3000 and you should see the Rails default page.
Sunday, 2 September 2012
Use Mate with Cheap Hardware
[Update: This whole post is a lie. See how Chrome is the culprit here. and see my confirmation that Cinnamon is fine here.]
A few weeks ago I switched to Linux Mint and chose the Cinnamon desktop. That turned out to be a disaster with my cheap Dell laptop (Vostro 1440). The performance was excruciatingly slow -- apps would take tens of seconds to open, the mouse would freeze, etc. Switching to Mate has made it bearable. Unfortunately, switching the desktop, while doable (Google it) doesn't work perfectly. I have duplicate items in some menus, or multiple ways to do the same thing. I never know when I'm going to see Nautilus or Caja when I open a folder.
I also suspect, based on what I was seeing while trying to debug the performance problem, that a 5400 RPM drive just doesn't cut it for a desktop user. The minute I dip into swap space, performance starts to fall off. I guess what I really should say is that 5400 RPM disk plus 2 GB of RAM doesn't cut it. That would solve the swapping. However, I would expect the slow drive would still slow initial program start-up.
A few weeks ago I switched to Linux Mint and chose the Cinnamon desktop. That turned out to be a disaster with my cheap Dell laptop (Vostro 1440). The performance was excruciatingly slow -- apps would take tens of seconds to open, the mouse would freeze, etc. Switching to Mate has made it bearable. Unfortunately, switching the desktop, while doable (Google it) doesn't work perfectly. I have duplicate items in some menus, or multiple ways to do the same thing. I never know when I'm going to see Nautilus or Caja when I open a folder.
I also suspect, based on what I was seeing while trying to debug the performance problem, that a 5400 RPM drive just doesn't cut it for a desktop user. The minute I dip into swap space, performance starts to fall off. I guess what I really should say is that 5400 RPM disk plus 2 GB of RAM doesn't cut it. That would solve the swapping. However, I would expect the slow drive would still slow initial program start-up.