The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.
Sorry, my brain is messed up today 
Yes, I meant 50 Mbit/s. And 3MB/s would equal about 25 Mbit/s. I don't think a 264MHz could do even that, probably a lot lower even.
There's a huge benefit from running IPsec with kernel crypto btw, I can do 78 Mbit/s with my wdr4900 which is an 800MHz ppc. It only reaches 32 Mbit/s with OpenVPN.
OpenVPN throughput requires a lot of CPU power.
davidc502 wrote:arokh wrote:Yes, they have been running OpenVPN, and their file throughput when copying a file over the VPN has been 3MB/s. The WRT1900AC can do about 50MB/s right? Simple logic as you say.
It would be interesting to perform a download test to see the maximum speed of the 1900ac whilst using OpenVPN. 50MB/s actually sounds very high to me, because that's actually broken down to 400mbps. Speculation here, but I don't think there's enough CPU overhead to accommodate running OpenVPN over the WAN whilst using NAT, and get good download speeds.
The question is, is gaga's experience typical? High CPU on 1 core? Or are others not having the same problem or is everyone?
Also the question remains... is the OpenVPN package available for OpenWrt RC3 or Trunk, the latest version of OpenVPN?
**EDIT** Also2 - would love to console into the Stock firmware, and run the same download tests with OpenVPN.
50Mbit/s not 50MB/s
That makes a lot more sense.. the capital B is denoted for Bytes, and some people do use this to describe throughput, so over the years I've stopped questioning. Thanks for clarifying.
I'd say 50mbps is a lot more realistic based on the screenshots provided by gaga. And that sucks!
(Last edited by davidc502 on 23 Jul 2015, 19:54)
davidc502 wrote:Sure, if your PC is disc thrashing already, and you add RAM, there's going to be a performance increase - Absolutely.
We're not talking about disc thrashing because we are not talking about swap here. Routers run without swap so everything needs to be stored in memory. For example, with 64MB of RAM there are limits to how many services you can run before your router actually kills processes or reboots.
Just a note that even without swap you can benefit from more RAM. the system uses RAM to cache various things, including the stuff it reads from flash. If you are really tight on ram, but haven't yet completely run out, you can get into the situation where the system has to read from flash (and uncompress) every time you access something, or in extreme cases, every time you check a file timestamp.
Rather than watching the available ram, watch disk I/O instead. If you start seeing more I/O and aren't serving file, you are really close to completely running out of RAM.
But you are right that once you have 'enough' RAM, adding more doesn't help.
JW0914 wrote:davidc502 wrote:Setting up OpenWrt is easy to do as it just takes adding the opkg snmpd, making sure it starts when the router starts, and filling out 1 configuration file. The difficulty comes in with actually doing the motioning and being able to report it.
Should the data be saved directly on the router, or should it be sent to my FreeNAS server? If so, how would I configure that?
That's where the problem comes in... The snmp agent (snmpd) needs to be polled for the information, and as the information piles up, disc space can become an issue. To be clear, the router will not send the performance data, it must be polled using a application like Nagios or MRTG (There's a lot of them out there). I use HP SiteScope Freemium, but they all work the same way when it comes to SNMP.
The issue is with the MIBS (OIDs), and knowing what OID's to poll. That is where I can help as I've documented where all of the interesting OID are. I have them on a spread sheet, and would be willing to share with anyone.
Once you have your application set up and ready to poll, I can give you the OID's, and you're off and running.
another good approach you can take is to configure the router to send it's logs to a remote server and then have scripts on the box gather the stats and write them to syslog. SNMP is inefficient in that for each value you want to gather, you have to query it independently. If you are doing this over a network that you are then trying to measure, you end up with a hiesenberg. Using logging, you can gather a bunch of data and send it as one log entry, which becomes just one packet sent out.
However, under normal usage (NO VPN), the most RAM, 1900ac V1, seems to use is around 20%. I would love to monitor a 1900ac router running VPN to see how much RAM is used. Manually Running TOP during VPN will give the same indication, so if anyone is willing to post the results, we would love to see them.
Interesting that the load sometimes jumps from CPU2 to CPU1 and then back again to CPU2.
That is a problem!
It's actually the normal situation. No program runs 100% of the time (even openvpn under load), at some point every program needs to wait for something to happen (even if it's just getting the next chunk of network traffic from the OS). When this happens, something else can get a chance to run on the CPU that the app was running on. When the CPU hungry program is ready to run again, the OS has a choice between having it wait until the process running on the CPU it was on pauses, or running it on the other CPU. It almost always is going to end up running it on the other CPU because it doesn't know how long the process that's running is going to keep running.
If the CPU has a large cache (the way x86 systems do), this can hurt as reading from memory is slower than reading from cache. Back in the day when x86 systems were around 1GHz clock speeds, I was doing some testing on a dual-processor box and found that I was able to get ~10% faster performance of a number crunching process by running setiathome to keep the other CPU busy and prevent linux from bouncing the process from one processor to the other. Since then linux has gotten smarter about such things.
you can set cpu affinity/cpu limits for the openvpn process to limit it so that it can only run on one core and see if that makes a difference.
the Marvell Armada 38X cpu in these systems has a 1M cache, which isn't that large, and since both cores use the same cache, you shouldn't suffer much of a penalty for bouncing from one core to the other. So I would not expect any measurable difference in OpenVPN throughput if you limit it to running on one core as opposed to bouncing between cores.
@iwrotecode
Someone with far more experience porting wireless drivers to OpenWRT (i.e. Kaloz and other OpenWRT devs) would be a better resource for information as to possible reasons why WLAN speeds over 1gbps WAN are significantly slower than WLAN speeds on LAN.
This is actually fairly straightforward
1Gb wired lan is 1Gb in each direction (2Gb total)
1.3Gb wireless lan is 1.3Gb total capacity. So even in an ideal environment where there is nothing else trying to use the frequencies and no static, you are not going to get 1.3Gb of data transferred in one direction because you need to get ack packets back in the other direction.
Then there are other 'housekeeping' things going on that also take up airtime.
The SSID broadcast from the router that tells clients that it's there and can be connected to takes some time, and since it needs to be able to be understood by everything, it transmits at the slowest configured speed (1Mb/s), so even a short broadcast takes a significant amount of airtime.
If there is anything else in the area using the channels, you are even more restricted on how much airtime you can actually use.
This is how 1.3Gb of 'advertiser' bandwidth results in ~870Mb of measured bandwidth under perfect conditions.
Anything shy of perfect conditions is going to end up even slower.
As I work with RHEL, everything you're saying is absolutely true in my experience. Since working with OpenWrt, the OS is stripped down, and I've called into question some of what I've learned in the server world. Some things just don't work or isn't applicable.
At times, It just doesn't seem to behave like the 'linux' I've come to know and sometimes Love , and because of that, I've broken out the old guide to learning linux again, to see if I can fill in some of the gaps. I hope I'm making sense. Everything seems to be pieced together with OpenWrt. Just a feeling I get when working with it.
The kernel behaves just like on RHEL, because it's also Linux.
As I work with RHEL, everything you're saying is absolutely true in my experience. Since working with OpenWrt, the OS is stripped down, and I've called into question some of what I've learned in the server world. Some things just don't work or isn't applicable.
At times, It just doesn't seem to behave like the 'linux' I've come to know and sometimes Love
I think most of the differences are due to the software providing the service than anything else.
The other thing is that you've been spoiled by servers that have lots of resources, and so a lot of things that just don't matter on a server (you want a to cache 64M of data, no problem) cause problems on most OpenWRT systems (I say 'most' because you can run OpenWRT on your x86 server :-) )
I started with smaller systems (my first linux box was a 386 with 4M of ram), so OpenWRT feels very famililar to the 'high end' servers that I was running 10-15 years ago, which became the low end servers 5-10 years ago :-)
There are so many people using OpenWRT who have never used *nix, that I don't assume familiarity with how things work when people seem puzzled by what's going on.
Same here, my first Linux install was Slackware 3 on a 486 SX-25 with 4MB of RAM lol 
Just lost WAN signal on RC3... however, I didn't know what information to pull and save prior to rebooting.
What information do I need to grab when an issue like the aforementioned occurs?
Same here, my first Linux install was Slackware 3 on a 486 SX-25 with 4MB of RAM lol
I guess we know who the seniors are now lol
Just lost WAN signal on RC3... however, I didn't know what information to pull and save prior to rebooting.
What information do I need to grab when an issue like the aforementioned occurs?
cerowrt used this script to gather info for troubleshooting purposes https://github.com/richb-hanover/CeroWrtScripts/blob/master/cerostats.sh
some of the paths will be wrong for the 1900/1200 (different drivers), but if you can get the same type of thing it woudl probably be useful.
also take a look at http://www.bufferbloat.net/issues/442 and see what people were looking for when fighting a similar wifi lockup bug there
JW0914 wrote:Just lost WAN signal on RC3... however, I didn't know what information to pull and save prior to rebooting.
What information do I need to grab when an issue like the aforementioned occurs?
cerowrt used this script to gather info for troubleshooting purposes https://github.com/richb-hanover/CeroWrtScripts/blob/master/cerostats.sh
some of the paths will be wrong for the 1900/1200 (different drivers), but if you can get the same type of thing it woudl probably be useful.also take a look at http://www.bufferbloat.net/issues/442 and see what people were looking for when fighting a similar wifi lockup bug there
Once I edit the script, what command do I use to run it? (I've never ran a linux script)
Same here, my first Linux install was Slackware 3 on a 486 SX-25 with 4MB of RAM lol
my very first install was from floppies downloaded from University of Helsinki, I'm not sure it had a name yet. On a 16Mhz 386 (before the sx was introduced) I think this was the 0.99 kernel (it was pre 1.0 kernel I know that)
I don't miss the days of needing 30+ floppies to install a system and no Internet at home to use for downloading :-)
dlang wrote:JW0914 wrote:Just lost WAN signal on RC3... however, I didn't know what information to pull and save prior to rebooting.
What information do I need to grab when an issue like the aforementioned occurs?
cerowrt used this script to gather info for troubleshooting purposes https://github.com/richb-hanover/CeroWrtScripts/blob/master/cerostats.sh
some of the paths will be wrong for the 1900/1200 (different drivers), but if you can get the same type of thing it woudl probably be useful.also take a look at http://www.bufferbloat.net/issues/442 and see what people were looking for when fighting a similar wifi lockup bug there
Once I edit the script, what command do I use to run it? (I've never ran a linux script)
./cerostats.sh
or if it's not set executable,
sh cerostats.sh
./cerostats.sh
or if it's not set executable,
sh cerostats.sh
by the way, apologies that I can't give you more direct help. I've received the 1200 I ordered but haven't had time to put openwrt on it yet. I want to do a little testing with the stock firmware first anyway.
So I don't have one I can login to and lookup the exact paths.
dlang wrote:./cerostats.sh
or if it's not set executable,
sh cerostats.sh
by the way, apologies that I can't give you more direct help. I've received the 1200 I ordered but haven't had time to put openwrt on it yet. I want to do a little testing with the stock firmware first anyway.
So I don't have one I can login to and lookup the exact paths.
No big deal at all, I appreciate the help =]
RickStep wrote:alirz wrote:Whatever its worth. I do a weekly reboot via script every Saturday 4am. With that in place, i've never had a lockup or router freeze. I have both IOS and Android wifi devices. I know a reboot is not a clean solution to the freezes but it only takes a few seconds and is worth avoiding lockups.
If @alirz temporary solution PREVENTS crashes; then the question is why is TIME part of the problem.
This sounds like a classic memory leak.
If true; what might be running; stopping and restarting?
The first thing that comes to mind are the wireless devices that are constantly starting; going on standby (because of zero use) and restarting or wireless devices continually disappearing and reappearing as devices leave the building and come home again.
Questions:
1. What size is the available RAM.
2. Is RAM a homogeneous block or is some of it "hard" partitioned for sole use by some applications and perhaps under sized.
3. Is it possible that some application(s) are not releasing memory resulting in a "freeze" when memory is no longer available.The question above about "blocked memory" has to do with observations of some posters who have suggested that when WIFI crashes; Ethernet still works.
Do we know how RAM is used?
Can we monitor the free RAM over time to determine if the free memory shrinks to close to zero before a crash?
Just a thought.
Rick
Oenwrt is line any other linux system in how it manages ram
there is some ram that the kernel reserves for it's own use, the rest of the ram is available for any use. If you don't use it for anything else, linux will use it as a disk buffer.
This makes it harder to look for running out of ram, but if it does run out of ram, linux will log that it's doing something (in syslog and on the console), I assume that in the months that this has been worked on, someone has had a serieal console attached when the box froze and got no useful info from it.
As was noted earlier in the thread, wifi freezing while everything else keeps working sounds like a driver bug. bugs like this are not uncommon in wireless drivers (cerowrt ran into a similar thing on the wndr3800, different driver, same symptoms)
the problems copying a file from the router via ssh/ftp could be a memory problem with the server software running on the router, which is why my suggestion was to try known-scalable software rather than the cut-down version that works for simple tings and is the default on the openwrt build to save space.
because the ram is used as a disk cache, it's hard to precisely monitor memory use, but if you write a script that does something like
while true; do
clear
cat /proc/meminfo
sleep 10
doneand run it on a console (ideally a serial console with your client software capturing it all to disk) you can watch all the details of memory use. I wouldn't expect this to find anything, but it doesn't hurt to have someone look.
Thanks for the lesson on Linux. I am a 70 year old Windows programmer retired for many years; haven't always kept up to date.
The main issue that I have is why time (or timing) seems to have an effect on when the router crashes.
While the driver could very well be the main problem; it would be very unlikely that the driver could influence TIME; unless IT is using scratch RAM.
The issue then becomes what can influence time.
@alirz says that if he reboots the router once a week there is NO crash.
Those that reboot after a crash have several days up time before the next crash.
We seem NOT to be chasing why TIME is a real issue.
Rick
Is there a sure way of getting a V2 of this router?
Go to a Walmart or Best Buy and look for the packaging differences - http://www.snbforums.com/threads/linksy … ost-183613
That being said, two different V2s were unusable for me. Read previous posts if you want to know why.
dlang wrote:RickStep wrote:If @alirz temporary solution PREVENTS crashes; then the question is why is TIME part of the problem.
This sounds like a classic memory leak.
If true; what might be running; stopping and restarting?
The first thing that comes to mind are the wireless devices that are constantly starting; going on standby (because of zero use) and restarting or wireless devices continually disappearing and reappearing as devices leave the building and come home again.
Questions:
1. What size is the available RAM.
2. Is RAM a homogeneous block or is some of it "hard" partitioned for sole use by some applications and perhaps under sized.
3. Is it possible that some application(s) are not releasing memory resulting in a "freeze" when memory is no longer available.The question above about "blocked memory" has to do with observations of some posters who have suggested that when WIFI crashes; Ethernet still works.
Do we know how RAM is used?
Can we monitor the free RAM over time to determine if the free memory shrinks to close to zero before a crash?
Just a thought.
Rick
Oenwrt is line any other linux system in how it manages ram
there is some ram that the kernel reserves for it's own use, the rest of the ram is available for any use. If you don't use it for anything else, linux will use it as a disk buffer.
This makes it harder to look for running out of ram, but if it does run out of ram, linux will log that it's doing something (in syslog and on the console), I assume that in the months that this has been worked on, someone has had a serieal console attached when the box froze and got no useful info from it.
As was noted earlier in the thread, wifi freezing while everything else keeps working sounds like a driver bug. bugs like this are not uncommon in wireless drivers (cerowrt ran into a similar thing on the wndr3800, different driver, same symptoms)
the problems copying a file from the router via ssh/ftp could be a memory problem with the server software running on the router, which is why my suggestion was to try known-scalable software rather than the cut-down version that works for simple tings and is the default on the openwrt build to save space.
because the ram is used as a disk cache, it's hard to precisely monitor memory use, but if you write a script that does something like
while true; do
clear
cat /proc/meminfo
sleep 10
doneand run it on a console (ideally a serial console with your client software capturing it all to disk) you can watch all the details of memory use. I wouldn't expect this to find anything, but it doesn't hurt to have someone look.
Thanks for the lesson on Linux. I am a 70 year old Windows programmer retired for many years; haven't always kept up to date.
The main issue that I have is why time (or timing) seems to have an effect on when the router crashes.
While the driver could very well be the main problem; it would be very unlikely that the driver could influence TIME; unless IT is using scratch RAM.
The issue then becomes what can influence time.
@alirz says that if he reboots the router once a week there is NO crash.
Those that reboot after a crash have several days up time before the next crash.
We seem NOT to be chasing why TIME is a real issue.
Rick
The only piece of code that just came to mind is lease time; and it doesn't recover. But that code failure would mean that every router would fail at the same time UNLESS that time has been adjusted by the various posters to a time.
Please don't let this post detract from the earlier one.
Rick
arokh wrote:Same here, my first Linux install was Slackware 3 on a 486 SX-25 with 4MB of RAM lol
my very first install was from floppies downloaded from University of Helsinki, I'm not sure it had a name yet. On a 16Mhz 386 (before the sx was introduced) I think this was the 0.99 kernel (it was pre 1.0 kernel I know that)
I don't miss the days of needing 30+ floppies to install a system and no Internet at home to use for downloading :-)
I was privileged. When I got started I bought a crazy priced rat shack computer I am pretty sure it was an ibm 486 33mhz with a turbo button Os DOS and win the only use for the turbo button was to slow down some of the games to make them playable. I signed up for a BBS. My favorite program was called Terminate. Jim Dunmyer did finally get a T1 to share amongst us and it was like lightning compared to the dial up speeds I still have my last modem a Courier v. everything and remember replacing the chip to gain new capabilities AKA speed. I Remember buying Multiple external modems from 1200 on up until I got smart. I built quite a few computers after that... Before it was cheaper to buy prebuilt. I like to learn and this is a fun way to learn at least a little about Nix. I messed around with Nix for a short time but I have run multiple boot for quite awhile and LILO was not so cooperative so I stayed with Microsoft.
So please excuse me if I ask stupid questions
Thanks for your patience.
dlang wrote:RickStep wrote:If @alirz temporary solution PREVENTS crashes; then the question is why is TIME part of the problem.
This sounds like a classic memory leak.
If true; what might be running; stopping and restarting?
The first thing that comes to mind are the wireless devices that are constantly starting; going on standby (because of zero use) and restarting or wireless devices continually disappearing and reappearing as devices leave the building and come home again.
Rick
Thanks for the lesson on Linux. I am a 70 year old Windows programmer retired for many years; haven't always kept up to date.
The main issue that I have is why time (or timing) seems to have an effect on when the router crashes.
While the driver could very well be the main problem; it would be very unlikely that the driver could influence TIME; unless IT is using scratch RAM.
The issue then becomes what can influence time.
@alirz says that if he reboots the router once a week there is NO crash.
Those that reboot after a crash have several days up time before the next crash.
We seem NOT to be chasing why TIME is a real issue.
Rick
There are a couple things here
first off, as I understand it, this isn't a reliably reproducable thing. Some people have problems regularly, others have no problems at all.
if it's an improbable race, then the longer it's running the more likely it is to hit the race.
The driver does have internal state that it keeps. For example, it's list of what's connected to it. If it 'looses' an entry every once in a while, it will keep going for a while and then stop.
The fact that when the problem hits, it's not the entire system that dies, just the one wireless interface in an indication of a driver problem.
The kernel has a mechanism to deal with running out of memory (it looks at what it thinks is taking 'too much' memory and kills a process), this would show up in logs.
but I can always be wrong, so it's worth someone checking who can reproduce the problem.
I apologize, I misunderstood. I don't have the time tonight to do a file transfer speed test, but over this past weekend I had to transfer a 256GB WIM to my NAS over WiFi, and I had constant 100MB/s+ transfer speed (100MB/s is equivalent to ~800mbps), while a 235GB WIM over LAN transferred in excess of 180MB/s (~1440mbps/1.44gbps).
I'm a bit perplexed by the 20mHz width as well, as VHT is enabled on the 7260ac (HT is 40mHz, VHT is 80mHz). I've been wondering for a while if this is the cause of the noise level being so high, as it's ~33% higher than it should be when only a few feet from the router. Granted, I don't see any other negative effect, as >100' from the router, I'm still getting speeds in excess of 500mbps between my laptop and the router. (To put the noise level in perspective, -98db - -90db is the nominal range for smartphones on 1x and 4G)
EDIT
The 20mHz anomaly would be a great question for @Kaloz or another OpenWRT dev
No worries on the speed test - I gave this program a shot: http://www.totusoft.com/lanspeed.html
Version 1.3.1
OS Version: Windows 8
Processor: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
Date: 07/23/2015
Time: 19:55:30
Program Parameters: 0
High Performance Timer: 0.0000002932
Test File: G:\NW_SpeedTest.dat
Write Time = 230.4298272 Seconds
Write Speed = 71.1019040 Mbps
Read Time = 112.3367558 Seconds
Read Speed = 145.8471920 MbpsDuring the WLAN speed test:
This was reading and writing 2048mb to the USB3 HDD on the router from the wireless desktop. As you can tell, WLAN speeds seem to be slow as well, in fact even slower than WWAN speeds. Maybe there's a better test to run out there (or do I need to run the speed test from client to client instead of client to router)?
@iwrotecode
Someone with far more experience porting wireless drivers to OpenWRT (i.e. Kaloz and other OpenWRT devs) would be a better resource for information as to possible reasons why WLAN speeds over 1gbps WAN are significantly slower than WLAN speeds on LAN. (I assume your ISP speed is 1gbps, though I could be wrong.)
I wonder if fragmentation size/MTU needs to be adjusted on your WAN connection. What type of internet service is fiber classified as (cable, dsl, etc.), as, if I recall correctly (and I could very well be misremembering), each service requires different fragmentation/MTU values for optimal speed.
Connection is AT&T GigaPower (fiber). Setup is fiber to the building -> personal ONT -> ATT gateway -> WRT1900AC. Max MTU on the gateway is 1500 (which is what it's set at). Since I get the expected speeds via Ethernet, I feel like it's probably not a setting with the gateway (that and the results I got from the WLAN test above).
(Last edited by iwrotecode on 24 Jul 2015, 01:11)
Decided to completely bypass the WRT1900AC and test wireless AC directly from the gateway to PC.
Welp, results still shitty.
