1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QOS: Downloads listed as DNS?

Discussion in 'Tomato Firmware' started by Azuse, Oct 5, 2009.

  1. Azuse

    Azuse LI Guru Member

    QOS: Ack woes =(

    I picked up a WRT54GL a while back, flashed tomato and spent afew weeks experimenting to get qos running properly, however i have a problem (correct me if I'm wrong).

    When i download from i.e. port 80 I upload at roughly 25KB/s, fair enough. The problem is the router and the pc seem to disagree on what port the upload is going out on. According to the firewall the uploads are all on port 80 and are correctly classed as low, the rotuer shows the same connections, but they're only using a fraction of that 25KB, most of it's being displayed as source ip of open dns port 53 (see below).

    Aside from messing up games/voip while downloading, I find it strange that the router is listing open dns as a source and no rules I can create can shift it out of highest. To me it seems like a bug, but being totally new to tomato it could equally be some setting I've overlooked/missed. How do i get my downloads to correctly sit in the low/lowest category and is it me or the router that's messing up?

    [​IMG] [​IMG] [​IMG]:frown:
     
  2. mstombs

    mstombs Network Guru Member

    If you are downloading from tcp port 80 surely the upstream "acks" are also tcp going back to port 80?

    The udp dns connections are nothing to do with it - they are replies from opendns source port 53 to Tomato's source port randomized dns lookup request.

    Are you using p2p and trying to lookup the names of large number of IP addresses? You should also see the threads in this forum which discuss "connection storm" because that's what it looks like!
     
  3. Azuse

    Azuse LI Guru Member

    Apologies, I should have been clearer. What I've posted up top is a lone browser download, nothing else running, no other machines attached to the router. I've also got the prioritise Ack box checked. However, if i do use multiple p2p apps on 2 pcs, i don't get these connections, everything is correctly assigned to the lowest (bulk traffic) priority. Those udps only appear when I'm downloading i.e. the router shows no tcp Acks, just those udp dns. Now it gets strange.

    If i uncheck the prioritise Ack box those connections simply vanish, instead i get a sting of TCP connections to the router, server I'm downloading from. Weirder still i no longer have the outbound Kb constantly climbing in the firewall display, it seems rather it's responding via the router rather than the ones downloading meaning it takes a whole 5 minute to trigger that 512Kb rule and drop into the low category.

    In other words, if i prioritise Ack packets my p2p etc, everything runs fine except regular http downloads which produce a hue number of udp dns. If i uncheck Ack packets everything runs fine except http downloads which stop responding to the server and send tcp directly to the rotuer. I'm particularly interested in why responses are going udp via open dns to my isps dns servers (which i don't) use rather than tcp to the server the data is coming from.

    Firmware bug? Connections incorrectly handled/misinterpretation? I doubt it's a connection storm, they're only open for 2-3 seconds then gone, not defunct connections. Whatever it is, it's making qos completely useless :frown:

    [​IMG]
     
  4. mstombs

    mstombs Network Guru Member

    In the first example there are 2 LAN PCs connected, '164' is definitely running P2P-like programs connecting from your ISP Bethere to virgin cable in UK and fastweb in italy! Are you running skype or anonymizer software perhaps?

    163 is making multiple connections to media.eve-files.com

    The UDP connections are download from opendns to your router, presumably replis containing dns lookups.

    Is your wireless secure and are you running anti-virus on all your LAN machines?
     
  5. Toastman

    Toastman Super Moderator Staff Member Member

    You may find it helpful to organize your QOS so that anything you do not specifically classify in a rule bypasses your rules and ends up in the "bulk" class. This is done by setting default class to "bulk" (use E for example - the absolute lowest priority class). Some of your rules will then become unnecessary. A lot of traffic which you may not even be aware of may then disappear into the bulk class.

    What software is doing the downloading? Is it some weird connection manager, for example, that could be responsible? There are several that do.

    Look also for P2P applications running DHT, and Bit Torrent DNA, which can cause a lot of hassle. Once installed on a PC it continues to run without your being aware of it. Viruses likewise.

    Perhaps these things are not the cause, but I mentioned them nevertheless.
     
  6. Azuse

    Azuse LI Guru Member

    164 is actually an xbox someone decided to switch on after being told not to which answers the second problem (dns) - fyi xboxlive is entirely p2p based.

    The first was http downloads bypassing the rules to highest, well that seems to be caused by prioritising Ack flags, not quite the behaviour I was expecting but it makes sense, i a way. Anyway, with that unchecked they're back where they're supposed to be. I am slowly adding rules now that I've got my head around it.
     
  7. Toastman

    Toastman Super Moderator Staff Member Member

    I have ACK flags prioritised (otherwise other applications will be slowed down). It doesn't put HTTP downloads in the highest class though. STEAM is also notorious for causing connection storms (see this thread: http://www.linksysinfo.org/forums/showthread.php?t=62860 ) If you allow P2P on your system, then I wouldn't recommend it. It can be other things too, not just P2P.

    What actually happens when you prioritize ACKS, is that they move OUT of the BULK class they were in, to the highest class. Now, since P2P applications are mostly downloading, and the majority of the outgoing traffic is actually ACKS to the downloads, we have effectively killed our QOS for P2P and prioritized it as highest instead! Thus if you use P2P, you should never prioritize ACKS.
     
  8. Azuse

    Azuse LI Guru Member

    I've already said i have no issue with any storms :) I took a snapshot while some dolt was firing up an xbox loading all the crap on it's menus. Prioritising Ack flags shifts http downloads to highest causing 25-28KB of traffic in the highest class, although it's all dns while a tiny portion of http is still classed in the low/lowest.

    At least it seems to be dns from the connections it shows. If i un-check Ack then the 25-28KB outbound traffic falls in the low/lowest class, while the dns connections remain in highest (although there is only the handful I'd expect, not a constant stream). To me, it doesn't seem to be functioning the way I'd expect.

    Either I've done something horribly wrong, there's a bug or something went funny during the flash. I'm thinking re-flash?
     
  9. Toastman

    Toastman Super Moderator Staff Member Member

    I think that's right. The prioritised apps in the ticked flags use the highest class by default, so unchecking them should make them drop into whatever else class matches, probably your default class. DNS is always prioritised in your class rules, there is no checkbox, so it won't change to the lower class unless you change it's rule.

    It is normal to see a lot of unexpected DNS and other activity in the highest class, I wouldn't worry unduly about 28k.

    You can stop a lot of junk appearing by checking "Avoid displaying LAN to router connections" in the debug menu. If you still get a high outgoing count and want to find out what it is and where it is going, I recommend using Wireshark network analyzer.
     
  10. Azuse

    Azuse LI Guru Member

    Not doing a very good job of explaining this am I? :) Incidentally every piece of p2p software I've used is tcp, uTorrent is playing with udp in version 2 but currently, the udp I've got is either games, skype or msn. Too the point.

    If I've understood what you've said above, then by prioritising a flag then any app using it i.e. tcp is moved to the highest class. It would make qos pretty worthless if every tcp app ignored the classes. Let me explain. N.B. I've separated bulk into A, visually it's clearer.

    This first screen is me running uTorrent (tcp) with the Ack not prioritised, note it's assigned the correct class (A). The seconds screen is Ack prioritised, the 25-30kB needed for downloading is int he highest.

    [​IMG] [​IMG]

    Now here's an http download, first is Ack off, and it's in the correct class. Second with Ack on, it's all in been moved to highest.

    [​IMG] [​IMG]

    Prioritising Ack packets is lifting the entire stream out of it's class into highest. It essentially makes the rules governing it useless.

    If i don't have Ack checked everything suffers, if I have it checked downloads go strait to the top and everything suffers. Is this working as intended and if so how do I fix it so that they won't jump strait up to the top? If not, what should I be doing to fix it?
     
  11. Toastman

    Toastman Super Moderator Staff Member Member

    Let's consider this more carefully.

    At the moment you seem to be showing downloads should be Medium class. ACKS are quite small, so if classified by a HTTP size rule, would fall under 0-512k. When ACKS are not prioritized, this normal HTTP class is where they show up when I download anything. That is also what you are seeing?

    So let's look at normal operation with ACKS given priority.

    1) You download something (say, an update from MSN) via HTTP. After initial handshaking the download begins.

    2) Packets are sent to you and should be tracked by conntrack, checked that they correspond to your outgoing download request, and therefore assigned as Medium Class. But since that is INCOMING traffic nothing will appear on the bandwidth pie chart, which shows only outgoing traffic.

    3) However, any limits placed on incoming MEDIUM data in the INBOUND LIMIT section should work to restrict the data flow - you can try testing this.

    4) Now, while the transfer is going on, there is probably no traffic back to the distant server except ACKS for the received data. You have ACKS prioritized, for speed purposes, so they should appear in the highest class in the bandwidth pie chart. The actual connections in the top (connections) graph however is still shown in the Medium class.

    That seems to be in order. The actual level of that ACK traffic seems quite high, but that is probably just how things are if you have a good speed download and you are not limiting it. (What is the actual download speed? Then you can see if the ACK traffic seems reasonable).

    If there were any other traffic destined for that server, apart from ACKS, only then it should show in the Medium class of the pie chart.

    Now to the point. If you say at this point everything suffers, then it is probably because your incoming download is saturating your inbound link. Placing a lower limit on incoming Medium class may therefore control things. The lower limit will slow down the link using normal TCP backoff mechanisms, and that will then reduce the levels of ACKS, and other apps will have some more bandwidth available.

    Does this make sense?
     
  12. Planiwa

    Planiwa LI Guru Member

    Priorizing ACKs may be counterproductive

    Sorry -- so very little time -- may I suggest reconsidering ACK Priorization in light of actual traffic distribution and bandwidth:

    ===> http://www.linksysinfo.org/forums/showthread.php?t=52537 <===

    Tomato QoS is very attractive, but extremely easy to misinterpret.
     
  13. mstombs

    mstombs Network Guru Member

    I do not claim to know how QOS works, but I fully understand the need for it when the upstream is close to saturation.

    I "prioritze acks" because I felt it would encourages big established downloads at expense of setting up new.

    But what if the downstream path is congested?

    One way of slowing down downloads would be to delay the transmission of acks, (TCP speedup tweaks typically increase the RWIN window which increases the quantity between acks).

    What azuse seems to observe is that prioritizing acks defeats the download rate limiting for multi-user shared operation, confirmed by that thread linked by Planiwa. Is this correct?
     
  14. Azuse

    Azuse LI Guru Member

    Basically. My download is a happy 11550k, the problem is the uploads.

    Say i set my bulk traffic to 60%, my upload is set to 125K, I'd expect 75K for torrent uploads. The problem is when I prioritise Ack those packets are moved into the highest rule which means they use the full 125K, or spike up to it, making the actual rules useless. This is what happens when I use http downloads (and torrents), anything tcp basically.

    From a certain viewpoint I can understand how this makes sense, but from a logical end-user viewpoint I'd expect the Ack packets to be moved to the top of their class, not the highest class. The prioritise Ack box may as well be named qos off as it simply makes it redundant.

    Esh, that thread's from '07, although I'm not misinterpreting it, it does precisely what it says on the tin. well at least I'm not the first victim of literal translation :biggrin:

    I've been experimenting with inbound p2p limits, but it seems they reach a point where they're simply ignored, usually the point highest is saturating the uplink. Could you give me an example to try/play with? I don't like seeing unchecked boxes :tongue:

    "That doesn't affect any other applications." it doesn't solve the problem of the saturated uplink either.
     
  15. Toastman

    Toastman Super Moderator Staff Member Member

    Try this quickly... just set an incoming limit on your chosen P2P class of 100k. If that works, then your problem is solved. It works here. If it doesn't work, then we have something different.

    This is the big problem we have with asymmetrical ADSL. You've got 11Mbps incoming and the ACKS need a lot of bandwidth. Nevertheless, it matters not how you slow down the download, but I maintain it is better to do it without delaying all ACKS. It does work perfectly here.

    One thing I do wonder, even scaling down your 10Mbps by half to fit my lower speed, your do have rather high ACK traffic. I am going to saturate my link with P2P in a moment, and see what I get. I'll post it.

    JEEZ I just read through the thread that Planiwa posted. I wish someone would delete it because it is full of silly examples and misinformation. That's forums for you...
     
  16. mstombs

    mstombs Network Guru Member

    Azuse, what is your upstream limit? You seem to mix bits and bytes. Tomato uses kbit/s on the QOS page, I have 500kbit/s up for 10000kbit/s down. If you only have 125kbit/s up then that is the big problem!
     
  17. Toastman

    Toastman Super Moderator Staff Member Member

    OK, done. I am now using a dedicated 5Mbps line, just me on it.

    I am hitting 5Mbps incoming P2P - my outgoing Highest (ACK) data rate is 72kbps. Outgoing P2P class (D) has approx 170kbps (this is traffic to the trackers). This with NO incoming limit on P2P data.

    With an incoming limit of 2.5Mbps the outgoing Highest (ACK) rate drops to 42kbps and the traffic in the P2P class (D) is now 139kbps.

    Switching off ACKS, no incoming limit set, outgoing Highest class now 2.15kbps and P2p class (D) is 206kbps. My uTorrent graphs show a small drop in download speed to 4.6Mbps. This shows that delaying the acks has not actually done very much to control the P2P.

    Hope this helps...

    EDIT - I've been assuming, from your graphs, that you have 512kbps uplink. Sometimes your upload in your P2P class is shown as 475k - ish ??
     
  18. Azuse

    Azuse LI Guru Member

    Unfortunately that won't work (well it will choke it thus slowing it down, but it's only a temp solution) because so many program like to use random ports passed 1024 these days. Msn and Skype are the best known, but it's basically allow udp/tcp passed 1024, making them fall into the p2p rules completely messing them up.

    I've also tried shoving it all into a class with 20% (25K) and it has the steady 25K, unfortunately it also has a steady 5K of Acks in highest plus constant bursts up to 40K (total). Now this is only uploading. If I'm downloading I have the same overspill of Acks but it's proportionally higher (just like http) and it's these Acks not bound by the class rule causing the problem.

    I'm going to keep fiddling with this (IT will work :p) but I have an observation too. Removing the Acks does indeed slow browsing, noticeably but still only a fraction of a second, however I have always under the impression the purpose of qos was to ensure latency sensitive traffic. Web browsing and p2p arn't (relatively speaking) latency sensitive :p

    I'm not saying I want to disable it (I don't), but assuming that qos is all about no lag on voip, video and games, well prioritising acks seems to have a negative effect once they are no longer restricted by the class rule.

    Edit: Uplink is 1350k sync, so it's set at 1000 in qos (Adsl overheads :frown:).
     
  19. Toastman

    Toastman Super Moderator Staff Member Member

    Perhaps you should read through the QOS thread below (if you haven't already). With QOS here in these apartment blocks a WWW test page opens in 4 seconds. Switch off QOS and it can take between 8 and 20 seconds easily. With QOS off, nobody in the block can even retrieve POP3 mail. It can often take up to a week of retrying and timing out. That's how I got the job in the first place!
     
  20. Toastman

    Toastman Super Moderator Staff Member Member

    Wow, if you have 1 Mbps upload, why on earth are you worrying about 40k of ACKS? Something is badly wrong with your QOS. The typical upload bandwidth (measured) in this country is 350k, it can drop as low as 180k. Yet the QOS works fine here. Incidentally, I have 8 large sites, each around 300+ rooms, and three smaller ones, up to 60 rooms. I use the same setup in all of them. And also on this spare line for my own test use.

    I think I'd start again from scratch, if that's possible, add one thing at a time and observe.
     
  21. Planiwa

    Planiwa LI Guru Member

    Yeah. That's what I meant by too little time -- I was aware of the thread, but hadn't had the time to read it through. I have now looked at this, though:

    http://www.cfos.de/traffic_shaping/traffic_shaping_e.htm

    It has nice charts that appear to be unnecessarily counter-factual. I wish that someone who would go to the trouble of making such pretty pictures would make an effort to align them more directly with actual facts.
     
  22. Azuse

    Azuse LI Guru Member

    Well that's why acks off doesn't make a massive difference, but I'm lucky, the uk average is 468 I believe, with a huge portion lower than that. Why? Because all I need is 2 people active to mess it up and that's really what qos is ment to solve.

    So, my first page focused on http, acks checked, making the http rules pointless, this time torrents. I put all p2p into class E and set it at 20% (25KB) then started a stack of wow patches (plenty wow addicts to fill the line).

    This is the line with acks off: [​IMG] playing nice and using the 25K I assigned to it.

    This is the line with acks on: [​IMG]
    and using more than double the assigned, because the elevated acks ignore the p2p rule.

    Now imagine a couple browsers, the odd console/phone, game, p2p etc all ignoring the class rules and it fills up very fast. It's working exactly as it should, they're going strait to the top. It would be better if they went strait to the top of their class however, ratehr than the top class. If anyone knows the dev the option to choose would make many people happy =).

    Sure, the other thread may be miss-informed, but this is why so many people suggst trying them off and on. Also, for the record, I reset this morning and started from scratch, this afternoon I re-flashed and stated again. The program is doing exactly what it is designed to. I think.
     
  23. Azuse

    Azuse LI Guru Member

    Experimenting with this (no ack) seems to work, total traffic control. Ackjust breaks it, unless i drop the values down to 5-10 and it'll still have problems should enough people (I don't have enough) use it.

    [​IMG] [​IMG]
     
  24. Toastman

    Toastman Super Moderator Staff Member Member

    Actually, I do not really understand why you have a problem because your rules and useage are pretty simple and your outgoing data rates are low enough to leave plenty of spare bandwidth.

    Here is what I see:

    1) The data classified is NOT going straight to the highest class. Only the ACKS are. And the ACKS are commonly given priority to improve speed of data flow, no?

    2) The data itself is still correctly classified and responds to limits. But I see all of your incoming limits are set at 100% - no limits at all. Especially the QOS class must have a lower limit or it will swamp your router if you get some good seeds, or a lot of part files being downloaded. Based on my experience, you will never get your QOS to work until you start to place some sensible limits on things. If you are thinking that you would like the P2P to take 100% incoming bandwidth when nothing else is using it, it will not work. P2P is unpredictable and variable in nature and will generally take what is available and more. In general you can have a full incoming data stream and poor latency, or good latency with a limited incoming data stream. You can't have both. And it is usually P2P that is the most difficult to control because of the constant opening and closing of multiple connections, leaving very little time for QOS to be able to do anything. A HTTP download, however, should be very easy to control.

    3) Your outgoing P2P class presently allows it to send out up to 650kbps of data. Based even on a low 20% or so ratio you could expect an incoming data steam well in excess of 13Mbps - which will saturate your link. Try setting it much lower, say 150kbps and see what happens (I generally allow no more than 60kbps with my 512kbps uplink and 5Mbps downlink. Any more than that can cause problems, with ACKS prioritized).

    4) The maximum outgoing stuff I see in your graphs is less than 500kbps. Only 300kbps of this is ACKS/whatever - in the highest class. Yet you have available 1Mbps? So you have plenty of spare outgoing bandwidth. The problem must therefore be in your incoming data saturating your downlink. *OR* the outgoing bandwidth (measured with an online ADSL speedtest page over a period of a few days at different times throughout the day and night) may actually be much lower than 1.3Mbps.

    5) If incoming data *IS* saturating your link then you must stop it and the mechanisms available to you are a) to limit the incoming rate of that class. b) turn off ACKS. Whatever works for you is fine.

    Check the 24 hour graph - what is the incoming data rate? Is it around 11Mbps and is the graph flat-topped with almost no bumps? If so, it is a sign that your link is overloaded. As it becomes less congested it will become less flat with some troughs.

    5) While your comment that it would be better if the ACKS were to go to the "top" of it's class rather than highest, this would not constitute much of a priority, would it? Probably not worth doing. And also, to do this, would mean assigning ANOTHER sub-class or space in the transmit buffer for each class. Thus there would effectively need to be 20 "classes".

    6) In fact you might say the "normal" method for a router QOS would be for the ACKS to be in the same class as the data. However, due to engineering tests and user requests, the choice to prioritize ACKS was added to the firmware of many, if not most, routers to speed up the response time. It would be interesting to see who was first to do it. At the end of the day, if not using it does not slow down your response times for other applications significantly, then there's no problem and just ignore it. It is, as with everything in QOS, a matter of balance and compromise. I'm just surprised you get a problem, is all.

    In general, if you want best performance for VOIP (and probably this applies to games also) - setting the INBOUND LIMIT to around 66% of the total available bandwidth (in your case this would be around 7Mbps) has been empirically found necessary to provide good latency. You can see the effect of this by setting up a ping to your ISP gateway and watching the response time while varying the limit. The commonly quoted 90% of full bandwidth setting isn't of much use here!

    I think you have enough food for thought and experimentation, so good luck and hope you sort things out to your satisfaction. I'm off to bed - 'night all!

    EDIT: Tomorrow I am hoping to do a lot of experimenting on the basis of ACKS not being given priority. This has also given me some food for thought!
     
  25. Toastman

    Toastman Super Moderator Staff Member Member

    My findings:

    At first, I thought there was a big overall improvement with ACKS off. After studying it for a while, to be honest, there is no really great difference in perceived performance between ACKS on or off here. As you say, HTTP is not significantly different. Ping times to my ISP gateway however are much better with ACKS off (improves from a spread of 23-160mS to 23-70mS with occasional spikes to 100mS. This with 3300kbps of P2P (uTorrent downloading 30 movies) - some HTTP exchanges with trackers, and some DNS. I also have 4 different IPTV windows open just to satisfy my curiosity. In both cases my incoming bandwidth overall limit is set to 80% (80% of my 5Mbps= 4Mbps).

    So I have to agree with you that in this particular set of circumstances, the QOS works a little better, perhaps a lot better - in some circumstances - with ACKS off, and would this would probably be significant to a games player. I found it does not make the huge difference claimed by the other forum members.

    The big problem here is that prioritizing ACKS in itself seems innocuous enough. However, they are moved into the hjgher class by default and this causes the application to get an unfair advantage over others in different classes unless limited in some other way. In this you are 100% right. It is better not to check the box unless there is a good reason to do so.

    In the past when I have compared settings, I got better results with the box checked. That was not so today, so based on this test at least, I will leave it unchecked. I am sure that after some retuning of other rules and classes, that it will indeed be an advantage.

    But, much more important:

    If I lower the incoming max bandwidth figure to 3300kbps (the magic figure of 66%) which has the effect of lowering all of the class limits in proportion, my P2P drops to 2650kbps, but my ping times show less spread. 22mS up to 43mS with only a very occasional spike above this, reaching about 70mS. That's a good average of 30mS, some 20mS faster than before (80%). I am sure this would be an extremely good figure for VOIP and games.

    But for my setup, the first figure of 80% is adequate and alows me to use a little more of the incoming bandwidth. Go higher than 80%, and the ping time begins to rise quite sharply. For me 80% is a good compromise because we aren't particularly trying to make games or VOIP perfect (although I'm told by both Skype and iPhone users it works fine).

    Now here's the closer.

    If I completely remove the class limits (by setting the oft-quoted 999999 in the inbound max bandwidth box) my P2P rises to 4300kbps, the ping times immediately rise to between 160mS and 1200mS with many dropped pings (looks like about 30%). The IPTV channels all begin to hang and then fail. This happens with ACKS on or off. My incoming link is running at 5Mbps and is saturated. The QOS system has ceased to work effectively.

    It recovers if I kill off some of the P2P sessions, but the behavior is quite unpredictable from one minute to the next. The limit is necessary for "insurance" under all circumstances.

    I am not a games player - but from this, I would say this confirms that the *single* most important thing to do in both instances is to first place limits on your incoming data classes. In your case, try 7000kbps in the INBOUND MAX BANDWIDTH box.

    I could achieve the same result in this instance with overall MAX set to 5000 and my P2P limit set to 4000. This would allow apps other than P2P to use the full bandwidth and limit only the troublesome P2P. However, this would perhaps also allow some other application to cause the ping time to rise higher on occasions. Individual carefully chosen limits would work but would take time to get right.

    I am trying that now on another identical setup but with 30 users online, and see that a good many spikes up to 120mS have indeed crept in. The setting is not a good catch-all, and an overall lower limit is much easier and safer.

    And now - I really am off to sleep !
     
  26. Azuse

    Azuse LI Guru Member

    Ack was the only outbound problem, it's been off for afew days and had and effect at all therefore it's staying off and outbound working fine.

    Inbound was unlimited while i was playing around, it's now set at 11500 and the value set - the difference between 66% & 96% is only 2 ms btw, <3 isp) so http (lowest plus C) at 90 and E 80, and latency is fine, about a 4 ms increase raising game pings to 33-34 :).

    The problem comes with the rule change, when they get shifted from class lowest to class c, they saturate the line for 20-30 sec, then return to normal once all the threads are in class c. I'm not certain if this is because tomato is trying to assign both classes 90% or because it takes afew seconds to reclassify, but seeing as downloads start at 90% i find it strange they rise after afew minutes then drop back down.

    Worse is the only solution i can see would be removing the 512k+ rule leaving a single class for http. What could be causing this ?
     
  27. Toastman

    Toastman Super Moderator Staff Member Member

    Just have time for a quick reply without considering it much, but I would expect while changing class for things to take a while to stabilize. Each connection that changes class will act independently with it's server - making the effect worse if there are a lot of connections changing class more or less simultaneously. I assume that after it has done so, for most of the time it's pretty stable?

    If the difference between 66% and 96% (assuming that you have torrents capable of saturating your incoming link) is only 2mS then I'm surprised. The difference is usually considerable. But it sounds good to me!
     
  28. Azuse

    Azuse LI Guru Member

    Saturated? No. The idea is to avoid saturation :) I meant 66% adds 4ms, 96% adds 6 ms, torrents are separate, anything above 85% chokes the line, they probably need to be even lower tbh.

    For example, here's a pair of http downloads (5 threads each, 10 total) [​IMG]. The problem is it takes so long for them to change over qos may as well not exist. So how do I prevent, or minimize the impact, this happening?

    Deleting the 512k rule would make browsing, is tehr a way I could pin them down to a single class without messing up the web or is there a better way to go about this?
     
  29. Toastman

    Toastman Super Moderator Staff Member Member

    Hmm. If they were torrent downloads I could imagine it might take an extended time because there would be many, many connections starting and stopping all the time. But if they are http downloads there shouldn't be such a problem. What is the method for the downlaods (software, distant source, how big are the files etc.) and I'll try to do something similar and see if I can duplicate it. How does this affect your other traffic.

    What happens if you set the max INBOUND BANDWIDTH to say 8Mbps?
     
  30. Azuse

    Azuse LI Guru Member

    At 8m, can you spot the point where they change class? [​IMG]

    That's just a pair of the 1gig test files (just empty .zip) through firefox using any download manager with 5 segments per file, so 10 total. The same thing happens if single section downloads are used, but the time is shorter though still quiet noticeable for anyone else trying to game or use voip [​IMG]
     
  31. Toastman

    Toastman Super Moderator Staff Member Member

    I haven't been able to reproduce that step. With my QOS rules it is more or less a flat line from the time the download begins. I used DAP with 5 segments.

    But yours is showing several minutes to change over and has a distinct and large step? Curious.
     
  32. Azuse

    Azuse LI Guru Member

    What qos setting are you using?

    Edit: just tried DAP, qos fail completly.
     
  33. Toastman

    Toastman Super Moderator Staff Member Member

  34. Azuse

    Azuse LI Guru Member

    Those ones I've already tried :(

    Actually I tried scripting port 80 too but same effect, inbound qos is simply ignored while changing class :(
     

Share This Page