Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: GigabitEthernet on July 31, 2015, 09:49:14 PM
-
Kitz,
I understand you're in contact with ZyXEL.
Is there any chance you could request them to add a bufferbloat fix to newer firmwares? If they could implement fq_codel that would solve the problem.
-
Hi
Kitz,
I understand you're in contact with ZyXEL.
Is there any chance you could request them to add a bufferbloat fix to newer firmwares? If they could implement fq_codel that would solve the problem.
Testing at Think Broadband on their new speed test it rates the ZyXEL as B for download and A for upload, if you test what does it rate it as?
Regards
Phil
-
Oh I don't own the router, yet :)
I'm trying to ask all router manufacturers to consider adding this protocol so I just asked because of that really.
It may already have it implemented, I don't know.
-
No I dont have any particular contacts with Zyxel, if I report anything I just do so via the usual channels.
Just ran a couple of tests for buffer bloat. I also see B download and A for upload at TBB.
.. and this is my one from DSLreports
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fdfkrkqaqb1zsx.cloudfront.net%2Fspeedtest%2Fcdn%2F992879.png&hash=fae1b68e66ab1fb64de63049b40ec218666b5217)
-
Just upgraded mine to V11 from V6 and now port forwarding isn't working. I believe I've set it up exactly as before (from a screen shot) and the rules are active, but it doesn't seem to work. Anybody got any suggestions as to what I could have missed or is it just Zyxel's flaky firmware?
-
Hi
Port forwarding working on mine all okay on 11, have you selected the correct WAN Interface? Are you forwarding to the correct IP address (as it may be different)?
Do you do a factory reset?
Regards
Phil
-
Hi Phil,
Thanks for your reply, yes, yes and no, perhaps I should do a factory reset - forgot that bit :blush:
-
Done a factory reset, and still can't get port forwarding to work :no:
I've got to have a remote session with Zyxel at some point regarding the parental controls problem, so I'll see if they can work out what's going wrong or what I've missed.
PS. Also my TBB ping monitor is no longer working, I'm on a static IP and I've checked that hasn't changed, only option I can see in in the Firwall/DoS where it states Deny Ping Response, which I've set to Disable.
-
Hi
For ping monitoring, try going to Maintenance - Remote MGMT - then put a tick in ICMP LAN/WLAN and WAN and see if it now works. For some reason they've doubled up on the setting, 11 is still a BETA so I expect this will be cleaned up hopefully on the final release.
For your forwarding problem, is this to a Windows PC? If Yes the PC may have recognised some network changes and put it into the Public realm as a net work by default, usually on logging it will prompt, this prompt various depending on the Windows version, whereas it should be private unless you make firewall changes on the PC.
Regards
Phil
-
Thanks Phil, that's fixed the ping monitor. The rules forward to a Windows Server, I'll have a look at that side of things, although I didn't notice any problems when I was on it yesterday.
Edit: I've had a fiddle around with the server, no idea what it was but it does now seem to be working, thanks once again.
-
No I dont have any particular contacts with Zyxel, if I report anything I just do so via the usual channels.
Just ran a couple of tests for buffer bloat. I also see B download and A for upload at TBB.
.. and this is my one from DSLreports
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fdfkrkqaqb1zsx.cloudfront.net%2Fspeedtest%2Fcdn%2F992879.png&hash=fae1b68e66ab1fb64de63049b40ec218666b5217)
Strange - I've just run the same test using my 8924 and get an A. I don't know if it makes a difference but I'm using firmware 7C0.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.dslreports.com%2Fspeedtest%2F1009246.png&hash=1a5a7e964f15d1f65102ab4a411772ee1f2558de)
-
I assume no QoS has been enabled on the router?
-
Yes QOS is off - is that what makes the difference?
-
It may be that QoS on this router is using a recent algorithm designed to reduce BufferBloat. It is really hard to say unless you do a before and after test :)
-
I've just run this on my 8924 on TalkTalk and got this:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.dslreports.com%2Fspeedtest%2F1014169.png&hash=c4564561862b8106b31e60a8d33832f4abde9d5a)
on 10C0 f/w and no QOS.
Stuart
-
Just ran a couple of tests for buffer bloat. I also see B download and A for upload at TBB.
.. and this is my one from DSLreports
Strange - I've just run the same test using my 8924 and get an A. I don't know if it makes a difference but I'm using firmware 7C0.
As was discussed in another thread (http://forum.kitz.co.uk/index.php/topic,15863.msg295319.html#msg295319) the fact that Im seeing B for download and A for upload on the TBB test probably indicates that any problems with bufferbloat are outside my own network. As also discussed in the other thread although these tests can identify that there is bufferbloat somewhere, there are various places where it can occur. Presumably the 'B' rating on my DSLreports test will have come because my downstream is 'B'.. whereby the TBB test scores the upstream and downstream independently.
ejs made a very good point in that other thread - for downstream its less likely to be the router itself. When its downstream then the router is going to be presented with traffic at <80Mbps from the WAN and in theory it should have no problem (or need) to buffer data onto a 1GbE LAN. Its with upstream where our routers are most likely to show signs of bufferbloat because its being presented with traffic of up to 1Gbps from the LAN, but can only put upto 20Mbps on to the external WAN.
-
If you run a traceroute when downloading a large file, you can see exactly where the latency is occuring.
Could you all run a traceroute please?
-
@kitz regarding upstream, if you have a router on your LAN that is a gateway when it's transmitting to the LAN it could possibly (in theory) use flow control to create back pressure and push buffering back into sending edge devices. So no buffer bloat in that gateway. I have no idea if this actually happens. I have designed systems that work exactly like that though.
Assuming there's no flow control available, LAN-to-WAN routers can have a problem with tx buffer management but there are lots of techniques for doing the right thing. You need to have a tx buffer for several reasons, having virtually nothing isn't a viable option. QoS need to get hold of several PDUs and see them so it can prioritise them and do its job right. Even without QoS you might at leadt want to have a fair queing policy and have tx ack prioritisation by queue-jumping as a TCP performance optimisation.
-
Just ran a couple of tests for buffer bloat. I also see B download and A for upload at TBB.
.. and this is my one from DSLreports
Strange - I've just run the same test using my 8924 and get an A. I don't know if it makes a difference but I'm using firmware 7C0.
As was discussed in another thread (http://forum.kitz.co.uk/index.php/topic,15863.msg295319.html#msg295319) <snip>
Thanks for that I have a better understanding now, and the need to make time to read more threads.
-
Just ran a couple of tests for buffer bloat. I also see B download and A for upload at TBB.
.. and this is my one from DSLreports
Strange - I've just run the same test using my 8924 and get an A. I don't know if it makes a difference but I'm using firmware 7C0.
As was discussed in another thread (http://forum.kitz.co.uk/index.php/topic,15863.msg295319.html#msg295319) the fact that Im seeing B for download and A for upload on the TBB test probably indicates that any problems with bufferbloat are outside my own network. As also discussed in the other thread although these tests can identify that there is bufferbloat somewhere, there are various places where it can occur. Presumably the 'B' rating on my DSLreports test will have come because my downstream is 'B'.. whereby the TBB test scores the upstream and downstream independently.
ejs made a very good point in that other thread - for downstream its less likely to be the router itself. When its downstream then the router is going to be presented with traffic at <80Mbps from the WAN and in theory it should have no problem (or need) to buffer data onto a 1GbE LAN. Its with upstream where our routers are most likely to show signs of bufferbloat because its being presented with traffic of up to 1Gbps from the LAN, but can only put upto 20Mbps on to the external WAN.
you correct but policing the downstream can move the buffer to your own network and as such QoS functions on a router can and do improve downstream buffer bloat.
I dont like it every time I read in places that user's are powerless to fix downstream bufferbloat, its not that, its just that its harder to do and as such developers dont like to push downstream QoS features.
I am guessing everyone missed my earlier posts on this, here is a pic of effect of downstream QoS.
Now as to why some people get good bufferbloat without local QoS policies? I guess it depends on their isp. As some isp's will buffer more than others, also bufferbloat will increase if the isp has congestion or has their own QoS.
-
> policing the downstream can move the buffer to your own network and as such QoS functions on a router can and do improve downstream buffer bloat.
@Chrysalis - apologies, but I don't understand
-
I just had a look at the QoS settings on my 8924 and it looks to me that you could quite easily get it all messed up and make things worse. I think I have some reading to do before I try messing with this ;)
Stuart
-
Weaver tcp self regulates its speed, however it does this by zig zagging up and down. It will slow down when the receiver cannot keep up and speed up when the congestion window and receive window are not filled.
Isp's tend to have large buffers for various reasons, the main one been it helps situations when there is saturation either isp or user side. So what happens is because the isp is buffering the traffic, essentially the receive window gets too big. The data gets backlogged in the isp's buffers and hence buffer bloat. Then all data has to wait its turn to get through that buffer and hence higher latency.
Basically by policing the traffic on the router, it will slow down traffic before TCP mechanisms do and prevents the receive window getting too big. This moves the buffer to the router, and you have direct control how big those buffers are on the router.
There is downsides, one been that typically single threaded transactions will not max the connection as the policing prevents thats. But they will still typically be able to utilise a high %, and multi threaded will typically flat line at the police limit.
I know it works as I have it configured on my own connection. Before policing my downstream downloading from steam caused heavy packet loss, now it does not, and typically latency is only slightly affected now as well.
-
> will slow down traffic before TCP mechanisms do
Thanks Chrysalis, I feel that's the crux of it.
Very helpful. I have designed systems like this before, but I didn't get your point until I read this.
-
Split this off from the other thread which was used to report latest f/w versions and any problems with the various versions.
Bufferbloat seems to be a hot topic in itself right now, so it deserves its own thread.. plus I'd like to read it when Im not about to drop :)
-
well kitz is some missing posts now regarding the bufferbloat conversation :(
-
well kitz is some missing posts now regarding the bufferbloat conversation :(
I split this topic off from this thread here (http://forum.kitz.co.uk/index.php?topic=13930.255) which is supposed to be for f/w versions.
Any of the posts about bufferbloat where split out of the f/w discussion thread and I cant see any still in there that Ive missed.
I think confusion may be because there are also topics about bufferbloat that were started in other threads too.