Thursday, 23 December 2010

Car insurance renewal made easy with Linux

The boom in car insurance this year has meant my insurance premium is just over £200 up from the previous year but had I stayed with my current insurer the increase would have been over £300.

Moving from one insurance company to another often means sending proof of your no claims discount (NCD) and about a week after purchasing my new car insurance Aviva sent a request asking for such.

Although surprisingly Aviva gave me two options,

1. Send the proof of NCD by post, or

2. Email it

It is nice to see companies taking advantage of modern day technology and I decided to go for the modern approach and email it. (My printer was out of ink anyway)

This obviously means scanning my proof of NCD, a big problem with Windows 7 and Vista.

My scanner, a Canon CanoScan N650U is only supported in Windows XP which I no longer use. The scanner happens to be a good few years old but for occasional use works extremely well.

Linux however, fully supports my ageing old scanner. In the past I have used Xsane and Gimp until now.

I noticed a scanning application called Simple Scan in Fedora 14, curious to see how well it works I launched the program and immediately knew this program had my name on it. I like simple and this program really is simple.



Simple Scan, a no nonsense program

 Click on the scan button and that is it. The preferences (Document > Preferences) contain DPI settings.

What is really cool about Simple Scan is scanning as a Text file automatically saves the document as a PDF file, exactly what I wanted.

You can switch between scan modes by clicking on the little down arrow next to the scan button.

But but...this is even more interesting, viewing the about information.



Who says Canoncial doesn't submit anything upstream?

So Linux was able to save me money on printer ink, postage fees, a new scanner and scanning software. Overall making my car insurance renewal easy.

Windows 7, your PC simplified

Linux, your life simplified!

Saturday, 18 December 2010

Realtek gigabit network performance in Linux sucks

Recently I have been doing a lot of network file transfers between a few PCs but the very slow transfer speed of a 100Mbps connection has been making things too time consuming.

This equates to a maximum theoretical speed of 12.5 MB/s.

How did I work that out?

Since there are 8 bits in 1 byte, 100 Megabits / 8 = 12.5 Megabytes

Any modern system should easily achieve up to 12 MB/s.

So I decided to get a gigabit switch and upgrade my home network for as cheap as possible :-)

A gigabit connection is 10 times the speed of 100Mbps and therefore has  a maximum theoretical speed of 125MB/s.

All my systems feature gigabit NICs, so no additional expense required on that part at least for now. As for the switch, you do have to be careful when buying a cheap gigabit switch, many claim to be gigabit but suffer from poor performance.

A quick look on www.ebuyer.com revealed a Tenda 8 port Gigabit switch for £24.99 which looked promising, customer feedback on Ebuyer was positive.

The switch itself has a very solid feel and construction with a quality finish, made in China of course.



The instruction manual was also very encouraging.




How did it perform?

Many people are often under the impression that with a gigabit connection you will automatically be able to send or receive at near gigabit speeds, this is not quite the case.

Other hardware components in your PC will have an effect on the transfer speeds and your gigabit network transfer rate will be reduced by the slowest influential component in your PC.

For example if your hard drive can only read at 70MB/s then it would be impossible for this PC to send data at a faster speed than it is physically capable of.

Lets build on this example, if the PC receiving the data has a hard drive with a write speed of 40MB/s, this further bottleneck will limit the transfer speed even more.

Overall the speed of every network file transfer transaction is determined by the PCs taking part in the transaction.

With a 100Mbps (aka 12.5MB/s) network connection it is easy to over look how other hardware components can impact performance since most systems are able to handle data at speeds well beyond 12.5MB/s.

The test setup

System A

AMD Athlon II X2 250
ASUS M4A785TD-V EVO
4GB Patriot Gamer Series 1600Mhz DDR3 7-7-7-20
500GB Samsung SpinPoint F3 Hard Drive
Realtek RTL8112L Gigabit LAN controller
Windows 7 HP x64 / Ubuntu 10.04 x64

System B

AMD Athlon II X2 240
ASUS M3A78-T
4GB G.Skill PQ Series PC2-8000 5-5-5-15
500GB Samsung SpinPoint F3 Hard Drive
Marvell 88E8056 Gigabit LAN controller
Ubuntu 10.04 x64 / Windows 7 HP x64

Notes
Both systems have a 500GB Samsung SpinPoint F3 hard drive which is capable of read/write speeds of about 125MB/s - 140MB/s
System A was also tested with Fedora 14, openSUSE 11.3 and Ubuntu 10.10
Cat5e UTP Cable, 8 meters and 12 meters

Results 

1. System A (Windows 7 x64) / System B (Ubuntu 10.04 x64)

Copying a 17GB compressed file from System B to System A produced speeds of 109MB/s to 110MB/s
Copying the same file back from System A to System B produced identical speeds.

Not bad given a 1000Mbps is theoretically possible of delivering 125MB/s.

2. System A (Windows 7 x64) / System B (Windows 7 x64)

Same speeds as test 1.

3. System A (Ubuntu 10.04 x64) / System B (Ubuntu 10.04 x64)

Copying a 17GB compressed file from System B to System A produced speeds of  37MB/s to 40MB/s
Copying the same file back from System A to System B also produced speeds of 37MB/s to 40MB/s.

Very disappointing.

4. System A (Ubuntu 10.04 x64) / System B (Windows 7 x64)

Same speeds as test 3

Conclusion

System A was able to deliver good speeds only with Windows 7.
System B was able to deliver good speeds with Windows 7 and Linux.

System A suffered from a performance hit when using a Linux operating system.

Clearly Linux does not suffer from poor gigabit network performance, if this were true System B would have displayed similar results to System A, i.e. poor performance in Linux.
 
Why does System A perform poor with Linux?

The answer lies with the pathetic Linux drivers (r8169.ko) Realtek have provided for the Realtek RTL8112L Gigabit LAN controller featured in System A.

Even using drivers from Realtek's slow loading website (r8168.ko) resulted in the same miserable performance.

Does this apply to all Realtek Gigabit controllers that rely on the r8169 kernel driver or is it only the Realtek RTL8112L Gigabit LAN controller that is affected?

Searching on Google implies its a widespread issue with Realtek Gigabit controllers that use the r8169.ko.

But wait there's more..

I am also experiencing another issue with the Realtek network controller on System A.

Restarting Windows then booting into Linux causes the Realtek network controller to cease working.

The solution to get the Realtek back up and running is to power the system completely off including the mains or PSU switch, wait for a few minutes then boot directly into Linux.

In future I will try to avoid purchasing motherboards with Realtek Gigabit network controllers or alternatively purchase a Network card such as the Intel Gigabit PRO/ 1000CT PCIe adapter.

Realtek = POS

Wednesday, 15 December 2010

Fedora 14 (64-bit) - Install Flash Player "Square" (64-bit) in 4 easy steps

This quick easy 4 step process makes the assumption no prior Flash Player plugins have been installed.

Open a terminal and type the following commands,

cd Downloads

wget http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_2_p3_64bit_linux_111710.tar.gz

tar -xf flashplayer10_2_p3_64bit_linux_111710.tar.gz

su -c 'mv libflashplayer.so /usr/lib64/mozilla/plugins'

Restart Firefox and experience Flash in 64-bit.

For more details concerning Flash Player "Square" visit, http://labs.adobe.com/technologies/flashplayer10/square/

I suggest bookmarking this page and keeping an eye out for updates.


16/12/2010 - Important email received from Adam.W Fedora QA Community Monkey

I recommend not installing the 64-bit Flash plugin for several reasons.

See, https://fedoraproject.org/wiki/Common_F14_bugs#Strangely_distorted_sound_in_Flash-based_sites_and_applications_when_using_Adobe_64-bit_Flash_plugin

and the warnings at https://fedoraproject.org/wiki/Flash#64-bit_Preview_Release ,

and follow the instructions at https://fedoraproject.org/wiki/Flash#32_bit_wrapped_version to install the 32-bit version wrapped instead.

It is nice to see the fedora community (and a Red Hat employee) demonstrating an active interest in the users as well as the product.

Thank you for the email.

Tuesday, 7 December 2010

How to install www.nvidia.com drivers in Fedora 14

Since I have been playing around with Fedora 14, I thought I would try and write a very newbie friendly guide on how to install the nvidia drivers from www.nvidia.com.

You could always use the rpmfusion method but that's boring :-)

Are you ready?

Open a terminal and type,

su -c 'yum install gcc make kernel-devel'

This will install the necessary packages to compile the nvidia driver. Next we need to download the appropriate nvidia driver.

At the time of writing, 260.19.21 is the latest nvidia driver.

Fedora 64-bit users, type the following

wget http://us.download.nvidia.com/XFree86/Linux-x86_64/260.19.21/NVIDIA-Linux-x86_64-260.19.21.run

Fedora 32-bit users, type the following

wget http://us.download.nvidia.com/XFree86/Linux-x86/260.19.21/NVIDIA-Linux-x86-260.19.21.run

This will download the NVIDIA-Linux-x86_64-260.19.21.run or NVIDIA-Linux-x86-260.19.21.run file to your current directory.

Once the file has downloaded use nano (a simple text file editor) to edit the grub.conf

su -c 'nano /boot/grub/grub.conf'

Edit your first kernel entry and add the option 'nomodeset' and '3'

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,1)
# kernel /boot/vmlinuz-version ro root=/dev/sda2
# initrd /boot/initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,1)/boot/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.35.9-64.fc14.x86_64)
root (hd0,1)
kernel /boot/vmlinuz-2.6.35.9-64.fc14.x86_64 nomodeset 3 ro root=UUID=d18f27a8-5c8b-4f82-af72-75cc78ad3f27 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UT$
initrd /boot/initramfs-2.6.35.9-64.fc14.x86_64.img
title Fedora (2.6.35.6-45.fc14.x86_64)
root (hd0,1)
kernel /boot/vmlinuz-2.6.35.6-45.fc14.x86_64 ro root=UUID=d18f27a8-5c8b-4f82-af72-75cc78ad3f27 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UT$
initrd /boot/initramfs-2.6.35.6-45.fc14.x86_64.img
title Other
rootnoverify (hd1,0)
chainloader +1

Modify your grub.conf as illustrated above.

To exit nano and save the changes, press 'Ctrl-X' and answer yes by pressing 'Y', finally hit the enter button.

Now reboot your system.

Don't be alarmed that your system boots to a text login screen. The option '3' above is responsible for making the system boot to run level 3 as oppose to the default run level 5 which is a graphical login.

Login by typing your username and password.

Install the nvidia driver by typing,

Fedora 64-bit users

su -c 'sh NVIDIA-Linux-x86_64-260.19.21.run -q -a'

Fedora 32-bit users

su -c 'NVIDIA-Linux-x86-260.19.21.run -q -a'

After the installer has successfully completed, type

su -c 'nvidia-xconfig'

This will generate the xorg.conf file, don't worry if you see a warning message.

Finally, edit your grub.conf again and remove the option '3' from your kernel line.

su -c 'nano /boot/grub/grub.conf'

Do not remove the 'nomodeset' option, it is a requirement. Without it the nvidia driver will crash.

Below is a snippet of the full grub.conf as shown above with the '3' option omitted.

title Fedora (2.6.35.9-64.fc14.x86_64)
root (hd0,1)
kernel /boot/vmlinuz-2.6.35.9-64.fc14.x86_64 nomodeset ro root=UUID=d18f27a8-5c8b-4f82-af72-75cc78ad3f27 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UT$

Delete the '3' option to make your kernel line entry resemble the above.

Exit nano, saving your changes.

Reboot your system.

su -c 'reboot'

The nvidia drivers will now be up and running after the reboot.

Important notice: 

If a system update installs a newer kernel, you must reinstall the nvidia kernel module.

Therefore before restarting your system after a kernel update, repeat the process of adding the option '3' to the first kernel line entry in your grub.conf as described above, then reboot.

After logging in type,

Fedora 64-bit users

su -c 'sh NVIDIA-Linux-x86_64-260.19.21.run -K'

Fedora 32-bit users

su -c 'NVIDIA-Linux-x86-260.19.21.run -K'

Once completed, remember to edit out the option '3' from your grub.conf

su -c 'reboot'

Enjoy Fedora 14.

Update 23/1/2011

If you wish to use newer drivers, substitute 260.19.21 with the newer driver version. For example 260.19.36
And if updating from an older driver version, remember to uninstall the older driver before installing the newer version, for example on a 64-bit system, boot into run level 3 and run su -c 'sh NVIDIA-Linux-x86_64-260.19.21.run --uninstall'