Moving Windows XP from an Intel based PC to an AMD based PC will cause a BSOD during startup (STOP 0x07E). Instead of reinstalling Windows, spend fifteen minutes following the steps below. You will be rewarded with a working computer.
Of course if you have a working Intel based computer that you are going to switch to an AMD based computer before you shutdown the Intel system open a command prompt and type:
“Disable intelppm” then shutdown.
This will change the registry settings and not load the intel drivers on start up. If you don’t have a working system then follow the steps below.
This only works using the same install CD as the original Windows.
1. Take the hard drive out of the old computer (Intel) and install it in the new computer (AMD).
2. Place the Windows XP Installation CD in the CD Drive and boot the new computer from it.
3. When the initial Windows XP Setup files have been loaded, press Enter to start a Windows XP Installation.
4. Press F8 if prompted to agree to the Microsoft End User License Agreement (EULA).
5. The installer will search for (and find) the Windows installation that already exists on your hard drive.
6. You be asked if you want to perform a Repair Install. Yes, you do! Press “R” to confirm and begin.
7. The installation environment is copied to the hard drive, and it automatically reboots to run the rest of the installation.
8. If you allow the computer to try to boot from the hard drive, it will blue screen. Instead, boot from the XP Setup CD again.
9. Enter the Recovery Console (press “R” at the first screen)
10. When you are logged into your Windows installation, and have the command prompt in front of you (C:\Windows), navigate to the following directory:
11. Your command prompt should now read:
and be awaiting you to key in a command.
12. Run the following two commands:
13. Type exit and press Enter.
14. Let the computer boot from the hard drive this time and Voila’! Your computer should run through what appears to be a typical first time Windows XP install.
15. Install the necessary drivers for any new hardware, install a massive number of Windows Updates, and you should be back in business.
I’ve always wondered why Windows doesn’t allow you to set an arbitrary size for the filesystem cache. What if you have a slow hard drive in your laptop, but loads of available system memory? Shouldn’t you be able to maximize that memory in order to speed up hard drive access?
I’ve found a slightly documented tweak that will allow you to tell Windows to use more cache for the NTFS “pool”, which should increase performance if your system opens and closes a lot of files all the time like mine does.
According to the Microsoft documentation:
Increasing physical memory does not always increase the amount of paged pool memory available to NTFS. Setting memoryusage to 2 raises the limit of paged pool memory. This might improve performance if your system is opening and closing many files in the same file set and is not already using large amounts of system memory for other applications or for cache memory. If your computer is already using large amounts of system memory for other applications or for cache memory, increasing the limit of NTFS paged and non-paged pool memory reduces the available pool memory for other processes. This might reduce overall system performance.
I’ll be testing this change out myself, and I really hope to get feedback from our excellent readers on this one. Please note that I’ve not run any benchmarks yet, so I can’t confirm yet that this yields any major benefit in real-world performance.
Command Line Hack
Open up an Administrator mode command prompt by right-clicking and choosing Run as Administrator, or type in cmd into the start menu search box and use Ctrl+Shift+Enter.
Type in the following command to increase the cache setting:
fsutil behavior set memoryusage 2
To check the current value, type in this command:
fsutil behavior query memoryusage
To change the setting back to the default, use this command:
fsutil behavior set memoryusage 1
Many new workstations and servers are coming with integrated gigabit (define) network cards, but quite a few people soon discover that they can’t transfer data much faster than they did with 100 Mb/s network cards. Multiple factors can affect your ability to transfer at higher speeds, and most of them revolve around operating system settings. In this article we will discuss the necessary steps to make your new gigabit-enabled server obtain close to gigabit speeds in Linux, FreeBSD, and Windows.
First and foremost we must realize that there are hardware limitations to consider. Just because someone throws a gigabit network card in a server doesn’t mean the hardware can keep up.
Network cards are normally connected to the PCI bus bus via a free PCI slot. In older workstation and non server-class motherboards the PCI slots are normally 32 bit, 33MHz. This means they can transfer at speeds of 133MB/s. Since the bus is shared between many parts of the computer, it’s realistically limited to around 80MB/s in the best case.
Gigabit network cards provide speeds of 1000Mb/s, or 125MB/s. If the PCI bus is only capable of 80MB/s this is a major limiting factor for gigabit network cards. The math works out to 640Mb/s, which is really quite a bit faster than most gigabit network card installations, but remember this is probably the best-case scenario.
If there are other hungry data-loving PCI cards in the server, you’ll likely see much less throughput. The only solution for overcoming this bottleneck is to purchase a motherboard with a 66MHz PCI slot, which can do 266MB/s. Also, the new 64 bit PCI slots are capable of 532MB/s on a 66MHz bus. These are beginning to come standard on all server-class motherboards.
Assuming we’re using decent hardware that can keep up with the data rates necessary for gigabit, there is now another obstacle — the operating system. For testing, we used two identical servers: Intel Server motherboards, Pentium 4 3.0 GHz, 1GB RAM, integrated 10/100/1000 Intel network card. One was running Gentoo Linux with a 2.6 SMP (define) kernel, and the other is FreeBSD 5.3 with an SMP kernel to take advantage of the Pentium 4’s HyperThreading capabilities. We were lucky to have a gigabit capable switch, but the same results could be accomplished by connecting both servers directly to each other.
For testing speeds between two servers, we don’t want to use FTP or anything that will fetch data from disk. Memory to memory transfers are a much better test, and many tools exist to do this. For our tests, we used ‘ttcp'(http://www.pcausa.com/Utilities/pcattcp.htm).
The first test between these two servers was not pretty. The maximum rate was around 230 Mb/s: about two times as fast as a 100Mb/s network card. This was an improvement, but far from optimal. In actuality, most people will see even worse performance out of the box. However, with a few minor setting changes, we quickly realized major speed improvements — more than a threefold improvement over the initial test.
Many people recommend setting the MTU of your network interface larger. This basically means telling the network card to send a larger Ethernet frame. While this may be useful when connecting two hosts directly together, it becomes less useful when connecting through a switch that doesn’t support larger MTUs. At any rate, this isn’t necessary. 900Mb/s can be attained at the normal 1500 byte MTU setting.
For attaining maximum throughput, the most important options involve TCP window sizes. The TCP window controls the flow of data, and is negotiated during the start of a TCP connection. Using too small of a size will result in slowness, since TCP can only use the smaller of the two end system’s capabilities. It is quite a bit more complex than this, but here’s the information you really need to know.
By default, Windows XP Professional does not clear the virtual memory pagefile when the system is shut down. In some organizations this is considered a breach of security because the data in the pagefile might be accessible to users who are not authorized to view that information. To enable this feature and clear the pagefile each time the system is shut down, start the Group Policy snap-in, expand Local Policies, and then select Security Options. Right-click Shutdown: Clear Virtual Memory Pagefile and then click Properties. By default, it is disabled. To force Windows XP Professional to clear the pagefile when the system is shut down, select Enabled.
Wednesday, January 5, 2011
Installation Synergy server in Debian GNU/Linux Lenny 5.0
After installing the Synergy keyboard/mouse sharing program, I needed to figure it out how to set up the server. The installation process of Windows XP is mostly done on GUI interface. Linux is still catching up.
penguin@L64:~$ find / -name synergy*
For server installation:
The server needs configuration file to star up /etc/synergy.conf
copy /usr/…/examples/synergy.conf to /etc and modify it. It has set up for three computers.
Make sure the host names in synergy.conf exist in /etc/hosts. If not, you write the IP addresses instead of host name.
192.168.1.101 L64.room L64
192.168.1.100 Laptop.room Laptop1
My /etc/synergy.conf file:
# sample synergy configuration file
# comments begin with the # character and continue to the end of
# line. comments may appear anywhere the syntax permits.
# 01/05/2011 Me: Synergy setup
# three hosts named: moe, larry, and curly
# L64 is 64 bit Linux box – this one
# Laptop is a Windows XP laptop
# L64 is to the left of Laptop
right = Laptop1
# Laptop is to the right of L64.
# and larry have a symmetric connection (they’re in
# opposite directions of each other).
left = L64
And Then, go to other client (i.e, Windows XP laptop), replace the server name with IP address, and start it. Back to the Linux box, launch the server in foreground mode so that it would display messages in real time.
L64:/etc# /usr/bin/synergys -f –config /etc/synergy.conf
INFO: synergys.cpp,1042: Synergy server 1.3.1 on Linux 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64
DEBUG: synergys.cpp,1051: opening configuration “/etc/synergy.conf”
DEBUG: CClientProxy1_0.cpp,404: received client “LAPTOP1” info shape=0,0 1024×768
NOTE: CServer.cpp,278: client “Laptop1” has connected
INFO: CServer.cpp,447: switch from “L64” to “Laptop1” at 0,509
If there is a warning or error message, terminate the job.
When you restart Synergy and have the following message, it means previous synergy process is still running.
I had this messages quite a lot.
WARNING: synergys.cpp,505: cannot listen for clients: cannot bind address: Address already in use
DEBUG: synergys.cpp,519: retry in 10 seconds
Do ‘ps -aux | grep synergys’. It will show
L64:/etc/network# ps -aux | grep synergys
Warning: bad ps syntax, perhaps a bogus ‘-‘? See http://procps.sf.net/faq.html
root 4582 3.2 0.3 61656 3032 pts/1 Tl 17:28 0:05 synergys -f –config /etc/synergy.conf
type ‘killall -9 synergys’
+ Killed synergys -f –config /etc/synergy.conf
Find error in configuration, then start the server again. Suppose both computers are in the same local network and connection is fine, the error is likely from the configuration either server or client side.
Once Synergy works fine, make the server auto start. My Linux box starts on GDM (Gnome Desktop Manager) default, so I go to System > Preferences > Sessions > click [+Add] button.
Name: Synergy server
Command: /usr/bin/synergys –config /etc/synergy.conf
Comment: Synergy keyboard/mouse server