Category Archives: Techie Corner

Does an iPhone charge faster with an iPad charger?

Since a few years ago, I’ve been using an iPad charger to charge my iPhone. I always thought it charged faster, though I was never able to (or rather, never got around to trying to) verify it. Google gave mixed answers. Engineers and technical people said it doesn’t matter, that the iPhone will draw 1A regardless of how much current the charger is able to provide. Some people swear that their phones do charge faster.

First, some background. The USB port on a computer provides 500mA, or 0.5A. A standard iPhone charger provides 1A of current, while iPad chargers provide 2.1 or 2.4A. An iPhone plugged into a computer charges slower, and this is not surprising since the phone is only able to draw half the current it can normally draw. An iPad that is plugged into a computer will not charge, and may not even maintain the battery level if the iPad is being used. This same iPad plugged into an iPhone charger (1A) will charge, but slower than if it were plugged into an iPad charger (2.1/2.4A).

Then I started to wonder, if I plug an iPhone into an iPad charger, will the iPhone draw more current, and hence charge faster?

Recently, I suddenly thought of testing this out, and thanks to a cheap USB power meter, I was able to run a simple experiment.

It turns out, my perception of charging times was wrong! The iPhone draws 1A current from both chargers.

While randomly pugging the meter around, I seemed to notice that the USB cables seem to affect current draw as well. Perhaps if there’s interest, I can run another experiment on cables.

Tweaking Apache + WordPress

It started one day when I was using the WordPress admin interface and kept getting HTTP 500 errors. A few refreshes, and everything would load again. I vaguely remembered encountering intermittent HTTP 500 errors previously before, but this time, it seemed to occur quite frequently, so I went to investigate.

I thought it was quite curious that after several seconds of refreshing, the page would load. Checking top showed that after hitting the admin interface, the server would have no free memory, then several seconds later, the memory would be freed. Sounds like this was due to KeepAlive. In my original configuration, KeepAliveTimeout was set to 15 seconds. So that’s the problem. Next question is, should I lower the KeepAliveTimeout, or just turn it off?

It turns out there’s quite a bit of discussion on this question. KeepAlive works alongside HTTP 1.1, which specifies persistent connections so that the browser keeps the same connection to the server to load other elements on the page. However, the reality is that modern browsers use parallel (concurrent) connections to the server, which is faster than loading page elements sequentially. This is especially when webpages are complex and contain lots of rich media. This is not to say that KeepAlive is outdated. It still has its use, but the decision to use it is not so straightforward.

To decide whether or not to use KeepAlive, consider the CPU/RAM limits of the server. On a server which is limited by RAM, KeepAlive should be off so as to quickly free up RAM for the server to continue serving the next request, instead of holding on and hogging available memory. Conversely, turning off KeepAlive would increase CPU usage from the overhead of creating new processes and opening sockets.

In this case, since the admin interface would use so much RAM, I decided to turn off KeepAlive.

However, I was still getting errors when performing some tasks, such as uploading a bunch a photos. With a fresh cup of coffee, I sat down and investigated further.

The first place to check was the syslog, which showed suhosin alerting me that WordPress admin.php was trying to increase the memory limit. The alert looks like this:

Jun 25 08:57:07 vps3 suhosin[22082]: ALERT - script tried to increase
 memory_limit to 268435456 bytes which is above the allowed value 
(attacker 'x.x.x.x', file '/xxx/wp-admin/admin.php', line 109)

 

Now, increasing the allowed limit is not a big problem. On Debian, the config file is located at /etc/php5/apache2/conf.d/suhosin.ini. Just edit the file and uncomment (or add) the line

suhosin.memory_limit = 256M

 

The bigger problem that follows is that with 256MB of memory usage, does the server have enough RAM to cope? Trying to upload multiple files answered that question. The server ran out of memory, and on my SSH terminal, I couldn’t even run top.

A quick reboot of the server, and I checked my Apache configuration. I don’t know when I last edited it, but I immediately spotted the problem.

<IfModule mpm_prefork_module>
 StartServers      4
 MinSpareServers   4
 MaxSpareServers   8
 MaxClients       48
 MaxRequestsPerChild 0
</IfModule>

 

The MaxClients is set to high. Assuming a (very) conservative 20MB per PHP process, 48 clients would require 960MB of RAM. If you add on MySQL and other services running on the server which has 1GB of RAM, this will clearly cause the server to run out of memory. Even worse, the WordPress admin interface requires 256MB of RAM. If I calculate MaxClients based on 256MB per process, I can only have a maximum of…… 3. That doesn’t sound very reasonable, especially when visitors hitting the WordPress blogs themselves would use far less. Yet if I increase MaxClients, then using the admin interface would cause the server to run out of memory! This is especially when you upload multiple files, which create multiple connections to the server (and each requiring 256MB). A quick Google search found many users encountering this problem, and I’m not surprised now.

Thankfully, after many complaints, WordPress added the ability to set the memory limit (it was previously hardcoded). Although they don’t specify what the minimum memory limit is for the admin interface to remain usable, 128MB seems to work fine. So I added this line to my wp-config.php:

define('WP_MAX_MEMORY_LIMIT', '128M');

 

With this new limit, I can re-adjust my Apache configuration. I prefer a more conservative setting, so I now set MaxClients to 6, which means at its peak, Apache will use up 768MB of memory, comfortable for my server without compromising on the performance of other services.

So far so good!

Setting up a repeater bridge with DD-WRT and D-Link DIR-600

I wanted to extend the Wi-Fi range by using my D-Link DIR-600 Rev. B. DD-WRT allows configuring a repeater bridge. This seamlessly links up two routers wirelessly. The repeater bridge is especially useful because the second router allows both wired and wireless connections.

Thankfully, repeater bridge is supported on DD-WRT on the DIR-600. I followed the instructions on the DD-WRT wiki, but kept encountering problems. After following through the instructions and applying the settings, I would see two SSIDs broadcasting from the router, and any device connected to the second router could not reach the first router. In addition, the network connections would drop intermittently. After much trial and error, flashing different versions, and searching the Internet, I realised what the problem was! It was from adding the virtual interface!

I re-setup the router, this time omitting the step to add the virtual interface, and everything worked perfectly! My DIR-600 works like a proper repeater, and wireless devices would seamlessly roam across the routers depending on the signal strength. Job well done!

Here are the steps I did (adapted from the DD-WRT Wiki). My primary router is configured with WPA2 AES. The secondary router is running DD-WRT build 14311. The latest build in the DD-WRT router database, build 14896, is buggy.

  • Restore Factory Defaults on Secondary (DD-WRT) Router
  • Connect your computer to the secondary router via wired LAN port.
  • Open the address http://192.168.1.1 in your web browser. Newer versions of DD-WRT will require you to set a password before you can continue.
  • Open the Wireless -> Basic Settings tab
    • Physical Interface Section
      • Wireless Mode : Repeater Bridge
      • Wireless Network Mode : Must Match Primary Router
      • Wireless Network Name(SSID) : Must Match Primary Router exactly including exact case- Make sure you spell this correctly
      • Wireless Channel : Must Match Primary Router (This will disappear once you put it in RB mode, and isn’t needed)
      • Wireless SSID Broadcast : Enable
      • Network Configuration : Bridged
    • Save
  • Open the Wireless -> Wireless Security tab
    • Physical Interface Section
      • Security Mode : Must Match Primary Router and DD-wrt only works reliably with WEP or WPA2-AES
      • WPA Algorithms : Must Match Primary Router
      • WPA Shared Key : Must Match Primary Router
      • Key Renewal Interval (in seconds) : Leave default
    • Save
  • Open the Setup -> Basic Setup tab
    • Connection Type will be: Disabled
    • Set STP for Disabled (Enabled sometimes can cause connection problems) redhawk
    • IP Address : 192.168.1.2 (Assuming Primary Router IP is 192.168.1.1)
    • Mask : 255.255.255.0
    • Gateway: 192.168.1.1 (again assuming Primary Router IP is 192.168.1.1)
    • DHCP Server: Disable
    • Local DNS: 192.168.1.1 (if IP of Primary Router is 192.168.1.1)
    • Assign WAN Port to Switch : Optionally enable this to use the WAN port as another LAN port.
    • Save
  • Open Setup -> Advanced Routing tab
    • Set Operating mode to “Router”
    • Save
  • Open Services
    • Disable Dnsmasq
    • Save
  • Open the Security -> Firewall tab
    • Uncheck all boxes…except Filter Multicast
    • Disable SPI firewall
    • APPLY Settings
  • Reboot the router.