I really don't post much here anymore, but will leave it in case it is of any use to some random person ;).
For information about Jeremy Collake visit his company website or personal website.
Wednesday, March 9, 2011
Wednesday, September 24, 2008
Using OpenWrt/X-Wrt White Russian as a QoS device
For those Linksys WRT54G series owners upgrading their wireless networks to newer devices that don't support OpenWrt, I recommend using your old WRT54G as a Quality of Service (QoS) device. Placing it at the end of the topology, right before your WAN (modem), you can utilize the wonderful QoS features in X-Wrt White Russian to prioritize network traffic going over the WAN. You can also use the QoS of Kamikaze, but if White Russian does the job, it is the more mature platform. Tomato is another option, though I can only speak for the performance of QoS in OpenWrt. DD-WRT's QoS used to be completely broken, though that may have been fixed now.
QoS can greatly improve network responsiveness when you're reaching the cap on your WAN. In addition to improving the standard browsing experience while downloading in the background, it will also improve your gaming, VOIP, ping, and TCP connection initiation latency.
QoS can greatly improve network responsiveness when you're reaching the cap on your WAN. In addition to improving the standard browsing experience while downloading in the background, it will also improve your gaming, VOIP, ping, and TCP connection initiation latency.
Saturday, May 24, 2008
AES vs. RC4/TKIP benchmark, and CPU/RAM overclocking
I've been optimizing my small wireless network lately. Its a simple setup, running OpenWrt /w X-Wrt extensions on a WRT54Gv4 (essentially a WRT54GL) and a WRT54Gv5 running in client bridge mode on a downstairs computer. After doing many benchmarks, here is what I recommend:
WPA2 AES seems to perform 10% better than WPA2 TKIP/RC4 on these Broadcom platforms. I'm still maxing out at about 22MBits, but that's better than the 18MBits I was getting. The latency seems lower as well, which is quite important for remote desktops and gaming.
Now, for overclocking. I always overclock the WRT54GL-like series to 240mhz CPU and 120mhz RAM. Just setting it to '240' implies the RAM speed is 120, so only clkfreq=240 is necessary.
Its important your Linksys model have a NEWER CFE BOOT LOADER though, else you can brick it by an invalid clock setting. Starting with the WRT54Gv4, the boot loader was changed so that invalid clock frequencies are simply ignored. I verified this during detailed disassemblies of the CFE boot loader. More information is in my old R&D wiki here .
So, if your device is one that's 'safe' to try overclocking, then except for the risk of burning out your processor and starting a fire, its good to try. Without any heat-sinks I've been running both my WRT54G class devices at 240/120 for a couple years now and everything has been fine.
You can overclock it by changing the 'clkfreq' nvram variable. On units with these newer CFEs, you simply need to set the CPU frequency and the RAM frequency will be implied as one-half of that. For example, clkfreq=240,120 is fine, though clkfreq=240 is also valid and results in the same clocking.
Why do it? Simple. For increased throughput and decreased latency. Just because your CPU is idle most of the time, doesn't mean its speed isn't important during short-term bursts when its used to its capacity.
The argument about it safeness is debatable, but the RAM seems underclocked from its specs to start with. Also, the slightly newer (5352 vs 5354) Broadcom chipset used in the WRT54Gv7.2 and above is even clocked to 240mhz, suggesting the 5352 is at least close to being capable of running 240/120. That said, overclocking is obviously pushing beyond the limits the manufacturer deemed safe, SO NEVER CONSIDER IT SAFE AND DO IT AT YOUR OWN RISK.
In the end, I always overclock these biatches for a little better performance and have NEVER had any troubles.
WPA2 AES seems to perform 10% better than WPA2 TKIP/RC4 on these Broadcom platforms. I'm still maxing out at about 22MBits, but that's better than the 18MBits I was getting. The latency seems lower as well, which is quite important for remote desktops and gaming.
Now, for overclocking. I always overclock the WRT54GL-like series to 240mhz CPU and 120mhz RAM. Just setting it to '240' implies the RAM speed is 120, so only clkfreq=240 is necessary.
Its important your Linksys model have a NEWER CFE BOOT LOADER though, else you can brick it by an invalid clock setting. Starting with the WRT54Gv4, the boot loader was changed so that invalid clock frequencies are simply ignored. I verified this during detailed disassemblies of the CFE boot loader. More information is in my old R&D wiki here .
So, if your device is one that's 'safe' to try overclocking, then except for the risk of burning out your processor and starting a fire, its good to try. Without any heat-sinks I've been running both my WRT54G class devices at 240/120 for a couple years now and everything has been fine.
You can overclock it by changing the 'clkfreq' nvram variable. On units with these newer CFEs, you simply need to set the CPU frequency and the RAM frequency will be implied as one-half of that. For example, clkfreq=240,120 is fine, though clkfreq=240 is also valid and results in the same clocking.
Why do it? Simple. For increased throughput and decreased latency. Just because your CPU is idle most of the time, doesn't mean its speed isn't important during short-term bursts when its used to its capacity.
The argument about it safeness is debatable, but the RAM seems underclocked from its specs to start with. Also, the slightly newer (5352 vs 5354) Broadcom chipset used in the WRT54Gv7.2 and above is even clocked to 240mhz, suggesting the 5352 is at least close to being capable of running 240/120. That said, overclocking is obviously pushing beyond the limits the manufacturer deemed safe, SO NEVER CONSIDER IT SAFE AND DO IT AT YOUR OWN RISK.
In the end, I always overclock these biatches for a little better performance and have NEVER had any troubles.
Thursday, February 1, 2007
X-Wrt readies official Milestone 2.7
The last month has had its ups and downs. I was ill for a bit and neglected my role in the project, though thepeople managed things quite well in my abscence -- making me glad to see X-Wrt could survive just fine if I were to die or be otherwise incapacitated.
We've had many new additions to X-Wrt in the past couple weeks, with Spectra rewriting much of the CSS so that its much cleaner. In the process he reworked the color switcher so that it uses proper alternate theme mechanisms instead of a proprietary technique.
We fixed a number of bugs too, many appearing in the brief Milestone 2.6 version of the webif, which was snuck out far too hastily. There was a period of a few days this month where a person downloading the stable version may have got a version not so stable at all. I apologize for this, but we are still in beta.
A new stable webif build called Milestone 2.7 is already up, but its not the official release. Once Milestone 2.7 is officially released we'll probably freeze or pseudo-freeze the White Russian branch so that the Kamikaze branch can advance more freely. SSL support is planned to be implemented first in Kamikaze, though plans may change. At present, the plan is to write a new tcp tunneler that utilizes axtls. The alternate would be to use openssh+stunnel, but this is a very heavy solution weighing at least few hundred kilobytes. The axtls solution will probably end up being less than 100 kilobytes.
Our official release of Milestone 2.7, along with a new X-Wrt firmware image (finally), coincides with OpenWrt White Russian 0.9, which is supposed to be released very soon after a delay of over a month from its original release date. Its important this build be made public because there are some bugs in White Russian RC6 (note: they are fixed in the X-Wrt Milestone 2.5 firmware image).
In our new firmware image we have updated to Busybox 1.3.1 and Miniupnpd 1.0-RC3, for anyone who might care.
We've had many new additions to X-Wrt in the past couple weeks, with Spectra rewriting much of the CSS so that its much cleaner. In the process he reworked the color switcher so that it uses proper alternate theme mechanisms instead of a proprietary technique.
We fixed a number of bugs too, many appearing in the brief Milestone 2.6 version of the webif, which was snuck out far too hastily. There was a period of a few days this month where a person downloading the stable version may have got a version not so stable at all. I apologize for this, but we are still in beta.
A new stable webif build called Milestone 2.7 is already up, but its not the official release. Once Milestone 2.7 is officially released we'll probably freeze or pseudo-freeze the White Russian branch so that the Kamikaze branch can advance more freely. SSL support is planned to be implemented first in Kamikaze, though plans may change. At present, the plan is to write a new tcp tunneler that utilizes axtls. The alternate would be to use openssh+stunnel, but this is a very heavy solution weighing at least few hundred kilobytes. The axtls solution will probably end up being less than 100 kilobytes.
Our official release of Milestone 2.7, along with a new X-Wrt firmware image (finally), coincides with OpenWrt White Russian 0.9, which is supposed to be released very soon after a delay of over a month from its original release date. Its important this build be made public because there are some bugs in White Russian RC6 (note: they are fixed in the X-Wrt Milestone 2.5 firmware image).
In our new firmware image we have updated to Busybox 1.3.1 and Miniupnpd 1.0-RC3, for anyone who might care.
Wednesday, January 3, 2007
X-Wrt Blog
Welcome to the X-Wrt blog of Jeremy Collake. The intention of this blog is simply to provide a place to report on the latest thoughts and developments regarding embedded firmwares. For those unfamiliar with X-Wrt, see here.
Whether or not I actually utilize this blog remains to be seen, but for now, here it is.
Whether or not I actually utilize this blog remains to be seen, but for now, here it is.
Subscribe to:
Posts (Atom)