From your description, your problem is not software related, its hardware related. More properly, its a radio propagation problem.
I am not sure if it is a problem at all. Those speeds are about right for the setup.
First: WiFi networks are half-duplex. This means that the neat numbers you see on the boxes of the Access Points at the market are not exactly the running speeds of those devices. By Half-duplex this means that the quoted speeds are one way only. Its the signalling speeds of the channel. To test this you might put two access points (one as AP the other as client) into a anechoical chamber and start transfering data both ways. What happens ? You wont see anywhere near the 150mbit/sec hated, you will see something close to HALF the speed, because the channel is shared between transmiting and receiving. So, it would be more like 75mbit/sec.
Second: The values advertised are - conveniently - measured in bits per second. But what you transfer between computers is usually bytes. This means that to have a figure in bytes per second you have to divide the values by eight. And this is not enough. Every time your computer wants to communicate with the access point and vice versa, this is done via PACKETS, packets are limited ammounts of data that are marked with addresses and flags. This means that for each certain ammount of data you transfer between your computer and your access point, a certain ammount of boiler plate information will have to be transfered between them. So make those 75mbit/sec up/down at the same time be more like 40mbit/sec up/down.
Third: You are not alone in your channel. Even if you have no known nearby source of emission of radiation on the same channel, eletromagnetic radiation is generated by a lot of physical processes in our own world. When a radio wave is not transmitting information, its transmitting noise. The most common source of noise is heat. No, your access point is not getting hot and generating noise. Everything around us has a temperature. Be it 100F or 20C, any temperature above the absolute zero will produce radio waves. We call that radio waves "thermal noise". On any channel theres something called noise floor, thats the lowest ammount of noise present on that channel. On top of the natural noise, nearby access points - even if present in other channels - raise the noise floor, because theres no perfect way to "insulate" one channel from the other. And the more close they are to each other, the more powerfull this radiation becomes. The capacity of an access point to transmit information using radio waves is limited by what we call "signal to noise ratio". If there is more power in the signal, this value grows, if there is more power in the noise, this value falls. If you increase your signal too much, instead of generating a signal with a better signal to noise ratio, you might very well increase your noise floor due to the components in the signal path of the radio operating at a higher temperature where they generate more thermal noise. So, you must find the correct value for the power setting in your device (and your neighboor incorrectly configured AP might interfere here too). That being said, the ultimate arbitrer of the speeds that you might get out of your access point is the noise floor that all the devices see in the selected channel. Walls in the path of the signal might attenuate it too much. Bad placement of antennas on the devices themselves etc. Everything can be a reason for a lower performance. So the previous 40mbit/sec might be 20mbit/sec, for example.
Forth I advise you not to change RTS/Fragment threshold values. RTS is not very usefull in a "soho" environment. This value is used to decide if its worth asking for a CTS (clear to send) before sending (a process that takes some time but might prevent collisions) or sending the packet straight on. If the packet is smaller than the value of RTS threshold it will be sent straight away, if its equal or bigger it will grant a RTS/CTS handshake. This is done to avoid the hidden node problem. But for shorter ranges, all devices should be, usually, within sight of each other. The fragment threshold is used to decide when to fragment TCP/IP packets into smaller frames. This might be usefull under heavy interference ambients, when all channels are occupied and losing a big packet to collision is worse than losing a series of small packets. It might be usefull when you have a non-wifi source of interference too (i.e.: repetitive interference that might consistently drop big packets). I dont believe this is your case.
What can be done ? Take a screenshot of your access point web management screen, on the tab that shows all the connected clients so i can check out whats happening more profoundly. The 802.11n protocol specifies various modes of connection (MCS) to take most out of a channel, and each of those modes has its own characteristics speeds, lags etc. So the first thing to consider is the MCS mode that is being used by the devices.