Posted: Fri Jun 06, 2014 21:31 Post subject: QOS Wont work
Hi, after a recent free upgrade of my cable connection i got tired of the fact my poor old router (one of sashs most hated devices) a 1043 restricting the potential of the upgraded line.
So i dug out an old intel atom N270 (2.5 TDP) board i had laying around and threw in a secondary relteak PCI Gigabit network card (so i had two Gigabit cards), i know its pci, i will need to order a mini pcie replacement one as there is only pci and mini pcie on the board has.. anyway.
The system boots and works fine, internet speed is fantastic and im getting well of 100Mbps (more than i expect out of the little PCI CARD).
However the moment i turn QOS on the internet (wan) traffic crawls to pre dialup speeds (at a guess 9600bps). Ive running exactly the same QOS settings ive always used with mips based routers running dd-wrt, i tried other types HTB HFCS / SQF FQ_CODEL, set the QOS or upload download to 0 / the correct values, turned out small packet priority... nothing the moment i turn QOS on it all grinds to a halt.
Im running the public VGA, which should support QOS right?!?
So my question is where am i going wrong, is QOS broken on X86 builds or do i need a certain build number.
The other thing... which is a bit strange, normally i can connect to my cable modems (in brige mode) interface by going to 192.160.100.1, this works fine with dd-wrt on the 1043 but doesnt on the x86 box.
Checking eth0 is the wan port and eht1 is assinged to br0 as i would expect.
After seeing the potential for speed of X86 i dont ever want to go back to the lower power mips based routers again..
I really hope someone can help throw some light on it.
Yeah i like the tplinks to, just not the 1043 v1 and its flakey pre final n wireless lol, i figured you and brain slayer were also pretty sick of repeating to people why the wireless was flakey on the v1 and having people bash ddwrt, when its the wirless chip at fault.
I initially tried the latest beta, which is what had the issue with, qos grinding everything to a halt, when i tried earlier builds, 221188 for example of one i tried, i got a kernel panic on boot (not sure why, possily the older 2.x kernel (2.4 maybe).
Just to test out if its the hardware ive loaded openwrt 12.09rc2 (stable branch) and with and without qos i got full speed 162mb however the latest build of ddwrt got me 115mb ish pre turning on qos.
So now thinking about it even though the latest beta booted i can only assume it was having an issue of some form before i had even turned on qos and turning it on only made matters worse.
Hardware wise its an n270 itx atom board, usb storage (in hard drive emulation mode), 2gb ram, both network adapters are rtl gigabit (should be the same driver, one on board and one on pci) no wifi (as i knew public vga wouldnt support it).
If you have any suggestions or want me to test anything i can switch usb drives to boot and test.
I would prefer to be able to use ddwrt over openwrt in the long run, its always served me well on other devices and projects, there is so many small things ive discover in setting it up that i find are either missing on openwrt or are not as well thought out or as easy to setup.
Having now seen the light of using lower power x86 im keen to overcome the issue so i can share the x86 ddwrt love and spread to others.
Besides ive always found the ddwrt support community is always more friendly and helpful
Code:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
stepping : 2
microcode : 0x218
cpu MHz : 1595.900
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lah f_lm dts
bogomips : 3191.80
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
I think both the network controllers fall under the remit of the the rtl8169 driver.
