See the issue with QoS is that it itself may be artificially lowering your throughput for the sake of latency in addition to it being cpu intensive. What I am most curious in is flat out fastest throughput possible. Do you get the full 100 Mbps now with QoS disabled and by disabling the bandwidth monitoring like nicram explained?
If I connect directly to the cable modem via wired connection, I get 99 Mbits/sec for the same test (www.speedtest.net).
So the firmware, without QoS and the monitoring, is more inefficient than the stock firmware. The stock without QoS did better. However, QoS works better using Gargoyle, as does Wireless N.
Can you confirm that you had both upload and download QoS enabled when you did this test? Can you confirm that you had only the default QoS rules and classes?
It would be nice to compile a little list of these types of figures for different routers that Gargoyle runs on.
I posted about a similar problem on my connection with the 1043nd. The downstream speed was definately being constrained by the TP-link processor. With QoS disabled I got my max downstream speed of 61Mbps. I have a Netgear WNDR3700 on order which should solve the problem. I'll post my results once I receive it.
Yup, QoS up down was enabled. I have two additional QoS rules based on IP, as I only want to prioritize voip packets from two devices on my network.
I believe the CPU on the 1043nd is underpowered, the max throughput lan/lan is about 120 Mbits/sec, so going to the wan with routing and QoS certainly decreases the performance.
It's sort of expected, here in Oz 1043nd can be had for $62, so it's a pretty cheap router.
It is strange though that top from SSH did not indicate anything???
About the only think that I can think of to improve gargoyle would be to look at the lowest level code and see if any optimisations could be made. Normally, when faced with similar problems in the past (interrupt routines were generally the first place to start), I would drop into #inline and code the IR in assembler. C usually pushes the whole register stack when in enters a routine and pops it off at the end, taking lots of time. If you only need a couple of registers, then pushing and poping only those saves heaps, especially if the IR only does a few things.
Just a followup, was doing a big download and ran top from SSH. Looked a little more closely and 80% of the cpu is in nic and 20% in irq. So the 1043nd is flat chat handling the traffic. The only way to improve this is optimise the code further. Assembler perhaps.
mix wrote:You are reading the output of top incorrectly-which says just about all I need to know about this I suppose.
Yes, just realised, 80% idle, 18% irq, which means the CPU is idle most of the time.
Still, there is something holding back the router as direct to the cable modem is 99 Mbits and max without QoS turned on is 81 ish. This performance is also similar to other reports regarding the router on Openwrt.
