Jump to content


  • Content Count

  • Joined

  • Last visited

  • Speed Test

    My Results

Everything posted by Jodokast96

  1. When you are directly connected to your modem (no router between the it and the pc), will take you right to the page. Also, there 6100 and 327 are virtually the same modem, except the 327 adds wireless and a 4 port router instead of the 6100's 1 port router.
  2. That Verizon plan is for speeds "up to 3/768". The key there being "up to". If your line cannot support 3mb speeds, they provision you at 1.5/384. The 1.5 is not an actual plan, just a different provisioning of the 3 plan. You can call and complain as much as you want, but there is little chance of getting a lower price.
  3. Before putting down support, maybe you should make sure you know what you are talking about. I'd like to ask you the same question, because only an incompetent person wouldn't ask. I've heard of "packet loss" before, but package loss? I'd look in your pants for the answer to that one.
  4. What modem you running? If it's a Westell, check the stats listed here: You are probably on interleave. If your line quality supports it, switching to fastpath will lower pings. You can find out more here: http://www.dslreports.com/forum/remark,14674058
  5. Your speeds will be overprovisioned to allow for the necessary overhead inherent with DSL. For example my modem stats read 3360/864 for the 3.0/768 plan. If they don't read over your speed plan, you've got problems somewhere. I've never used Firefox, so I'm guessing that Firetune is some sort of caching plug-in? If so, they can speed up browsing, but don't really speed up your connection. If that's how it works, that 1520 is not a true speed. As for Infospeed, I, and others, have found them to be very innacurate. I personally like the Speakeasy.net tests, but the one right here is just
  6. Make sure you reboot after loading the ccs file.
  7. You are getting 1500 on a 1500 connection and your complaining? Everybody here wishes they had your problem. BTW, the infospeed site is notoriously inaccurate.
  8. I didn't think it would work, but it was worth shot.
  9. Try opening up CableNut again, but only change the second on, DefaultSendWindow. Change it to 64240. Your down is great (don't know how you're getting it, though), but the up might be able to be improved a little more.
  10. Details will help. Check here http://www.testmy.net/forum/index.php?topic=2097.0 and give all info. No one can help you if we don't know what is wrong.
  11. I honestly don't know if they (Verizon) did anything. I've been trying to think of anything that changed, and the best that I've come up with is that I used to use Winpoet software on each pc, and pull a different ip address for each one. It wasn't so much to have different ip's for each pc, as that I liked being able to disconnect at any time. Anyway, not long before I noticed this problem, Verizon changed over so that I can't pull multiple ip's anymore. The guy at my local CO also said that they've been doing lots of equipment upgrades. That is the only thing I know of that changed. Un
  12. Hey, I do appreciate the time. Maybe VanBuren would like to vist my house and he can start a new project for atypical CableNut tweaks, lol. What do you think, up for it, VB?
  13. Only using the PPoE built into the modem. No speed software at all. CableNut did modify the registry values. I've used both that and DrTcp from DSLReports, and they all gave the same results. Understand now why I've been so nuts about this? It really doesn't any make sense, does it? And remember, this is on more than one pc and more than one OS on the same connection, and until 2 months ago, it wasn't like this. I could throw just about any VanBuren tweak in there and get good results. Some were better than others, but they didn't cripple me like they do now.
  14. Same as the last link, can ping and tracert it, but can't open it.
  15. Second file gives roughly the same results as the first one. Very minor improvements.
  16. Whoa, hold on a sec. We're crossing messages here. Everything I was just talking about was for the first file you sent. I'll try the second one now.
  17. With an RWIN of 12k, I can download at about 2800. With you setting it drops to about 1000.
  18. That was with your file. I can't get that link to open, get the "Page Cannot Be Displayed". I can ping it though, 585ms.
  19. I've done this at all times of day, with the same results. The low speeds with less latency only come with higher (over 20000 or so) TcpWindowSize or DefaultReceiveWindow values. Ideally, I would like to find a list of good, large bandwidth servers that also list where they are located. This would be a huge help in helping figure this out. With those new settings: Speakeasy NY: 768Kbps about the same for the rest of the East Coast. Lower RWIN usually about 2800kbps. Speakeasy CHI: 1600Kbps usually gets the same as the East Coast, but not this time However lower RWIN gives speed
  20. But that's just it. Dealing with latencies of less than 50ms, I'm seeing decreases in speed of as much as 75%. I can achieve that 90%. My concern is that if I can acheive it from somewhere with a higher latency, why does it cause such a drop with a lower latency? Or just to rephrase it, if I can acheive it from somewhere far away, why does that kill speeds near me? With only a difference of 50ms or so? I'll give that file a try, but I'm going to make a prediction first. I looked at the settings, and I'm guessing that Speakeasy tests in California and Seattle will be in the 2500+ ran
  21. 1426 down on a 1500 connection is good. Your up sucks, however. In CableNut, try setting the DefaultSendWindow to 64240 and see if it helps.
  22. Just ran a few quick tests. Based on these and other's, here's some quick ideas. Will use 3 values for examples. For a given TcpWindowSize, and any DefaultReceiveWindow up to and including that, the TcpWindowSize is dominant. Any DefaultReceiveWindow over the TcpWindowSize, and the DefaultReceiveWindow becomes dominant. TcpWindowSize of 13068 and ReceiveWindowSize of 8192 gives same results as: TcpWindowSize of 13068 and ReceiveWindowSize of 13068 TcpWindowSize of 8192 and ReceiveWindowSize of 13068. TcpWindowSize of 13068 and ReceiveWindowSize of 63888 gives same results
  23. The DefaultSendWindow value should not have been blank. I have found that increasing that to 63888 has helped my uploads out by about 100kbps. If it is blank, let me know, possibly I attached the wrong file. Ok, this brings me back to the very first question I asked at the very beginning of this post. The TCP/IP Analyzer reads the TcpWindowSize for it's RWIN number, not DefaultReceiveWindow. It clearly says this, and I just checked it myself. Nowhere on that page did it list the value I have entered for DefaultReceiveWindow. Now I know VanBuren already tried to answer this, but perh
  • Create New...