bandwidth quality?

Discussion in 'Tomato Firmware' started by NewG, Jan 29, 2009.

  1. NewG

    NewG Addicted to LI Member

    First off I am on an Asus wl520gu running the usb version of v1.23.

    I don't even know what to call this but my connection seems to "pause" during long downloads. Everytime I'm watching hulu it will pause in random points. Bandwidth also drops off during downloads (like downloading ubuntu ISO). I have done speedtests and my bandwidth seems fine (2572kb/s / 515kb/s) so I don't see where I should have pausing or drops or anything like that. I didn't see this when I was on DDWRT or the original firmware. It very well could be an ISP issue... but I was wondering if anyone here had any thoughts/ideas.

    I dont know if this helps here is a graph that was generated while I was watching Hulu. Each circle represents where the connection lagged and hulu stopped playback and had to buffer.

    Just a thought... would QoS help at all?

    Attached Files:

  2. Toastman

    Toastman Super Moderator Staff Member Member

    Firstly, you need to make sure that the problem is coming from the router, the ISP, or Windows. Where you get the pause, data ceases to come in for a short while, causing the dip. Then the backlog surges in at once, causing the peak. This may be due to a holdup in your web browser, windows TCP/IP, or other factors.

    1) If your windows machine has not been patched for the no. of half-open connections, google for "half open connections", read about the problem, and apply the "lord" patch, set to a few hundred.

    2) TCP Vegas can cause this. Turn it off, if it is enabled.

    See if that improves things before we look further. Is your QOS switched on, with any default rules? Do you run P2P? Try a different web browser such as Safari, Opera or Chrome (IE is very slow)...

    QOS will probably help you if you run several different applications at once, which from your comments on downloading, seems to be the case.
  3. az2008

    az2008 Addicted to LI Member

    Everything I've read says that TCP Vegas operates on outbound TCP data only. It shouldn't affect downloads except to the extent that it avoids upload congestion which would affect how fast acknowledgments are sent.

  4. Toastman

    Toastman Super Moderator Staff Member Member

    Mark, you're quite right that Vegas, like router QOS, operates on outbound packets. But the whole point of running it is to control inbound data so that it does not pile up at the ISP before being sent to our router. i.e. it can indeed control congestion over the whole link from router to distant server and back again.

    It does that by delaying ACKS to incoming TCP packets to slow down the distant server, eventually the theory is that all incoming data will slow down enough to fit inside the router's download bandwidth. If it delays too much, for some reason, there will be a brief pause before the server starts sending again, this can cause a brief hiccup in the graph. Several people have noticed this and posted somewhere on the forum a few months back when Rhester added Vegas to Tomato.

    When I was experimenting with the parameters in Vegas, I could also make this happen, but not so much as the other guys reported. Nevertheless, that's why I suggested turning it off just to eliminate one of the variables. But usually I find that kind of hiccup to be caused by the browser....
  5. NewG

    NewG Addicted to LI Member

    First off thanks for the reply... next I'll do my best to answer your questions

    I notice the peaks and (death) valleys with the drop outs on my ubuntu laptop as well. so I don't think its a 'half open' problem.

    Turned if off just in case and I'm still getting the same stuff.

    Nope, QOS is not on

    Run a bit but nothing on a consistent basis

    Tried Firefox 3 and Chrome...

    Not really the case... when Im watching Hulu I'm not usually downloading anything at the same time. I live alone as well and pretty sure the neighbords aren't thieving my bandwidth :p
  6. Toastman

    Toastman Super Moderator Staff Member Member

    OK, all understood.

    Is it possible for you to flash the original Jon Zarate's 1.23 ND version and see if that suffers the same fate? Or did you already try that - not sure what you meant by "original" version, probably you meant Linksys.

    you can get it at

    If it is OK, then we may have a problem that Teddy Bear can look at, perhaps driver related ....
  7. NewG

    NewG Addicted to LI Member

    Im starting to wonder if its an ISP issue. I did a line quality test at dslreports and I'm getting up to 10% packet loss.

    When I get a chance I'll flash to Jon Zarates version.

    Thanks for all the help Toastman
  8. Planiwa

    Planiwa Network Guru Member

    This seems like a perfect time for tcpdump.

    Start the real time graph, start tcpdump (record in a file), start a download (100MB). Note the gaps in the real time graph and look in the tcpdump for what happened then.

    With a 100MB download you should expect to get about 7 gaps, if the image you posted is typical. There should be under 20,000 packets, so your tcpdump file will not be too large to sift through. It should take 15-20 minutes.

    Try to run nothing else. You may want to run tcpdump on a quiet system (except for the real time chart) (for 10 minutes), to get a baseline.

    Another thought: eliminate the router. (and run ubuntu). No pretty Tomato chart, but you can write a simple awk script to make your own. :)

    Please share your findings.
  9. NewG

    NewG Addicted to LI Member

    Excuse my ignorance... but how would I go about doing tcpdump?
  10. NewG

    NewG Addicted to LI Member

    Ok well I tried the non Teddy version... and so far I'm still getting the drops and lags in bandwidth. I am trying on a few different systems (Tower: windowsXPpro, Windows7 and Ububtu Laptop: WindowsXPpro and Ubuntu) and browsers (firefox beta3 and chrome... sorry I refuse to use IE) and sites and whatever else I can think of to troubleshoot. Even tried toggling tcpvegas.
    From what I can tell so far though, tcpvegas has no real effect on any system.
    Also, in just about every OS there are the same drop outs. Its seriously like the bandwidth just takes a rest to catch its breath and then sprints to catch up.
    Even with all this said, its not THAT big of a deal and would probably just live with it but if its a bug I'd like to help ya'll out. Then if its an ISP issue... I'll live with it since the big bad corporation could probably make me disapear if I made too much of a fuss :p
    My next test will be to jack right into the modem and see if bypassing the router all together is the answer... but I think I'll do that in the morning...

    And Toast... Teddy... if ya ever are near San Francisco the first beer is on me :thumbup:

    Edit: 1)attached is XP laptop, tomato 1.23nd, disabled tcpvegas, downloading linux ISO 2) same configuration but no averaging

    Attached Files:

  11. Planiwa

    Planiwa Network Guru Member

    I wrote my message before I saw your packet-loss message. That would certainly be the first thing to be addressed.

    Perhaps I shouldn't have suggested tcpdump for you. It may be too steep from a standing start. Sorry. I probably misinterpreted your mention of Ubuntu.

    One thing you might try is to run the real time graph without Averaging. (It is set at 4 in the posted image.)

    That way we might get some clue from the shape of the gaps.
  12. Toastman

    Toastman Super Moderator Staff Member Member

    It certainly seems not to be Tomato that's the problem, but then, you say DD-WRT doesn't do it? That's odd, unless it's just a coincidence that it happened after you made the changeover. You might try connecting to your router by cable to eliminate the wireless as the problem, as well as using the modem directly.

    Mark, sorry I meant to add more but had a visitor and was cut short.

    Re. TCP Vegas, there are occasions when it seems to do something to incoming downloads, but it does depend what you are doing. Once again, making experiments to attempt to see what is actually happening versus what the papers say *should* happen, can be interesting.

    The papers say that Vegas works on data uploads - and measures round trip times based on received ACKS, and also dropped packets, to delay uploaded data to avoid congestion on the link (an oversimplified explanation but let's stick with it). In other words, it works only on the originating server's uploads. If that were strictly true, and there is no other function, it should not have any effect on downloads from a remote server. However, setting up a large download while streaming IPTV shows that Vegas does have a big effect. And many people report tremendous improvements with Vegas on all kinds of incoming traffic, which cannot easily be explained. It's easy to dismiss the claims, but there are too many of them to be hoaxes.

    I've found many posts from developers refer to *delay* of ACKS to *incoming* data by TCP Vegas as being able to control incoming data from remote servers. A (very) crude experiment I did using Wireshark's timestamp to investigate this, also did appear to show ACK delays to incoming downloads.

    However, that function isn't described in the definitive papers on TCP Vegas. If it is a function, perhaps it has been added more recently, or is part of some other protocol, or it has merely been skipped over in the references.

    Once again, it's all a bit of a mystery.

    That being said, in my setup, over a period of time and with varying traffic from dozens of clients, TCP Vegas didn't seem to accomplish much, so I don't use it any more.
  13. NewG

    NewG Addicted to LI Member

    Ok so I couldn't sleep and because of my insomnia I decided to jack directly into the modem and bypass the router. I'm attaching the results.

    So with this it looks like without the router. I downloaded for a good 20 minutes and didn't see one drop.
    Now as far as DDWRT vs. Tomato... I honestly don't think I was paying close enough attention when I was doing the DDWRT so it could very well have been doing it as well. I think thats my next test though... flash DDWRT on and see what happens. Could very well be a 'bad router'

    Oh and Toast... I added a second graph to that last post... it was my tower that was wired to the router... so it wasn't just the wireless.

    And the troubleshooting continues:confused:

    Attached Files:

  14. Toastman

    Toastman Super Moderator Staff Member Member

    Well, looks very strange. It affects wired tower - so not radio. Does DD-WRT still do it I wonder? If not, down to tomato, or something in the configuration that is different.
  15. Planiwa

    Planiwa Network Guru Member

    I'm glad you decided to eliminate the router.

    Thanks for the graph without the averaging. This also shows very clearly that the gaps are not valleys but canyons. And huge ones -- wider than half a minute!

    Those are 6 MB gaps. 4,000 packets in a row ... replaced by nothing at all.

    This does not look like the the result of software-efficiency tweaks such as Vegas or QoS. Likely something more drastic. (Like a loose contact, hopefully.)

    You will probably find that your packet loss (to the ISP) goes away too, with the router out of the picture.
  16. NewG

    NewG Addicted to LI Member

    Well Toast, I'll test out DDWRT again to see if it does the same thing but I'm also going to try different patch cables and put everything to default in Tomato to see if one of the settings could be effecting performance. And if DDWRT does it... could be a bum router.

    Planiwa: By loose contact you mean cabling? I'm trying to remove that possibility. Hopefully you dont mean inside the router because that wouldn't be a "hopefully" at all since my soldering skills leave alot to be desired.
  17. az2008

    az2008 Addicted to LI Member

    That's because it only operates on outbound TCP traffic to avoid congestion of outbound traffic. It wouldn't affect inbound traffic unless you had outbound congestion. It's avoidance algorithm would then cause outbound acks to be delayed, which could (probably would) affect inbound senders to slow down.

    That's why I didn't understand TCP Vegas being raised as causing your problem (at least without some qualifications of how it could cause it).

  18. NewG

    NewG Addicted to LI Member

    Well I flashed to the newest version of DDwrt this morning and it seems as though it has the same problems.

    So I guess I have to look at my cat5 cable first and try and see if my Asus router is toast. I wonder if Asus will replace it after all this :p haha

    Well I tried out my 3rd cable... this time a cat5e that was never been used and lo and behold I am getting steady downloads. Imagine that! The second attachment shows it. I'm still on DDWRT for right now... but going to flash over to Tomato here shortly. But I'm VERY happy that its not a bum router

    Attached Files:

  19. NewG

    NewG Addicted to LI Member

    Ok so now I am back on Teddy's Tomato. Ok that sounded a bit wrong and dirty... but all the same I'm back to the TomatoND USB firmware. Well I hate to say it but I'm back to the bandwidth drop offs. I figure from here I am going to:

    • [1]unplug usb
      [2]goto factory defaults
      [3]flash over to non Teddy Tomato ND
    Isn't there some nvr that I can clear or something like that as well?
    Oh and just for uniformity I am using the same server and same file for all tests.

    So I solved one weak link... just a mater of time until the next...

    I am a one man thread I tell ya! Well here is a status update. I did [1] unplug usb and tried my download again. Looks like thats the ticket. The second attachment shows my results. I will continue testing, i.e. running another with the USB plugged in, to make sure thats whats going on. If thats the case then I'll start playing with the USB settings in the GUI and hopefully find something important to toggle. Again... that sounds a bit dirty for a Sunday :biggrin:

    Attached Files:

  20. NewG

    NewG Addicted to LI Member

    Update number 5,000,000

    I have unplugged and plugged USB in almost every conceivable manner, (router->usb hub->2 hd, router->usb hub->1hd, router->1 hd etc.) and have found that the bandwidth drops occur when hardrive #2 is hooked up via the usb hub or directly to the router. If harddrive #1 is plugged in to the hub then all is well in bandwidth land and if hard drive #1 is plugged directly into the router all is well in bandwidth land.

    Now here is the deal... which I think I'll put over to Teddy next... Drive 1 has an inode size of 128 where drive 2 is ext3 and has an inode size of 256. I'll copy the drive contents over to another hard drive and change the inode size to 128 and see if that changes things.
    On a related side note, is there any reason to format to ext3 instead of ext2 for use as an external hard drive? Is journaling important in this context?

    Oh and I'm adding a chart that shows what happens when I turn on/plug in hard drive #2. I turned it on for the first drop, turned it off and the bandwidth returned and then turned it on again for the next drop. So yeah...pretty sure thats what the problem is....

    Attached Files:

  21. Toastman

    Toastman Super Moderator Staff Member Member

    Yes, looks like that's the cure.. TeddyBear is the guy to ask re ext2..

    Gld you found it!
  22. NewG

    NewG Addicted to LI Member

    yeah.. crazy that a hard drive could do that though... tech is crazy sometimes
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice