zylandros Posted January 30, 2015 CID Share Posted January 30, 2015 So the long and short is this. I have an issue with Cox and speed. The issue is my downstream speed slows to a near crawl starting around 5:30PM local time and stays in the cellar until after midnight. I have had more technicians out to the house than I care to admit and on more occasions than not, they have tried to place the blame squarely on my side of the demarcation. That said, here are some particulars. I am a CCENT with other assorted tech certs. I understand what my responsibilities are versus the providers and I understand demarcs. I test out my entire network including swapping modems before I ever pickup the phone for the provider - I am anal like that, I like having my facts straight. The lay of land: Test box is a Windows 7 Pro with a Gigabit Ether adapter pulling connection from a TP-Link TL-R470T+ connected to a Cisco DPC 3010. The run from the demarc to the modem is a homerun of about 75 ft then another 30 odd ft to the tap. During the day and going into the overnight I can get consistently in the mid 60's to high 70's on downstream and consistently in the 10's to teens on the up side. However, in the evening that tanks to as low as 468kb/s on the down with the up remaining in the 10's to teens. We have had a P1 techs on site and tested the signal coming into the tap where they saw noise and jitter pushing in the 100ms range but somehow I still scored 3.6 on their MOS. Package loss at the tap was in the 2 - 4% range. As a result of that testing Cox states they identified an amplifier at the node which was misbehaving and corrected that. According to Cox now, they are not seeing those issues anymore. But, we are still seeing the degraded speeds during the evening. I would like to get some insight as to how I can continue to push this matter with Cox to fix their junk and get me at least consistent speeds. I am on a 100/10 plan. Please review my logs and letter sent to Cox Customer Relations and advise. Thank you. -Zylandros Cox_Testing_0126-0130(Public).pdf Link to comment Share on other sites More sharing options...
starship_troopers Posted January 30, 2015 CID Share Posted January 30, 2015 while i cant help in this situation, i will say that i am on a cox plan also. the 50/10 plan and i just tested and got 87mbps download speed, yet 90% of the time i will only get 8-25mbps download. so i ask, please keep this updated for others to follow and perhaps we can find some kind of solution. hope this gets sorted soon. Link to comment Share on other sites More sharing options...
zylandros Posted February 1, 2015 Author CID Share Posted February 1, 2015 ****Update**** Starting Friday night (01/30) Cox has agreed to allow me to test with two service connections coming into the house. Because I have a TP Link router that has the capability of bonding the two connections at the router I am now seeing tests in the teens during the time frame before while running multi-threaded tests. Something I did note is that the Linear test would not load balance the connections in my current configuration. I did have to switch to multi-thread to get the packets to spread across both WAN interfaces. In the linear tests I was hitting in the 7 - 8 range and switching over to a multi-thread test I hit in the 15 - 19 range. More as it develops.... Link to comment Share on other sites More sharing options...
CA3LE Posted February 1, 2015 CID Share Posted February 1, 2015 bonding the two connections at the router I am now seeing tests in the teens during the time frame before while running multi-threaded tests. Something I did note is that the Linear test would not load balance the connections in my current configuration. I did have to switch to multi-thread to get the packets to spread across both WAN interfaces. In the linear tests I was hitting in the 7 - 8 range and switching over to a multi-thread test I hit in the 15 - 19 range. Bonding won't increase the transfer rate of a single linear transfer. You can't split a transaction across two interfaces. You increase your bandwidth in total by bonding but it doesn't make individual transfers faster. Example: My main server in Dallas is is bonded with 4 GigE interfaces (2 public)... but you won't see over 1000 Mbps because each interface is limited to 1000 Mbps. The difference is with bonding multiple people can pull 1000 Mbps simultaneously. Why not put it on a 10G interface? Trust me, I tried. Problem is 10G interfaces available right now don't have flow control... without FC more packets are sent than actually arrive. Totally inaccurate for our testing purposes here, completely bonkers results. One day. Heads up! With multithreading I've seen results as high as 1.7 Gbps, confirmed by client-side interface readings. I'm working on a test that's theoretically limitless for connection well beyond 1000 Mbps. I see 1 Gbps being standard in many homes within 5 years... which means there will be outlying SUPER fast connections that are MUCH faster. It may take special tricks to test these connections. So it's totally normal. You'll never pull more than the speed of the fastest single connection in a single file transfer. The file will have to be split and sent in pieces... then you can take advantage of both connections. Multithread test aside, you should be able to open two browser windows on the download test and start a larger test manually (one that will give you at least 10-15 seconds) on both windows. Try to do it quickly. If your bonding is balancing the load well the tests shouldn't affect each other. And you'll get two similar results... which you can then combine to get a total aggregate speed. As long as the two tests started at nearly the same time the final combined number should be highly accurate. (though not perfect because the tests were initiated by hand, staggered start time will raise the score slightly.) --- this scenario is only two threads but the score should be close to what you get in the multithread test if things are running well. ... this is one of the reasons I say "Versatile" on the home page. If you're smart you can use this test is different ways for which it wasn't originally designed and it still works. Link to comment Share on other sites More sharing options...
zylandros Posted February 1, 2015 Author CID Share Posted February 1, 2015 Bonding won't increase the transfer rate of a single linear transfer. You can't split a transaction across two interfaces. You increase your bandwidth in total by bonding but it doesn't make individual transfers faster. Example: My main server in Dallas is is bonded with 4 GigE interfaces (2 public)... but you won't see over 1000 Mbps because each interface is limited to 1000 Mbps. The difference is with bonding multiple people can pull 1000 Mbps simultaneously. Why not put it on a 10G interface? Trust me, I tried. Problem is 10G interfaces available right now don't have flow control... without FC more packets are sent than actually arrive. Totally inaccurate for our testing purposes here, completely bonkers results. One day. Heads up! With multithreading I've seen results as high as 1.7 Gbps, confirmed by client-side interface readings. I'm working on a test that's theoretically limitless for connection well beyond 1000 Mbps. I see 1 Gbps being standard in many homes within 5 years... which means there will be outlying SUPER fast connections that are MUCH faster. It may take special tricks to test these connections. So it's totally normal. You'll never pull more than the speed of the fastest single connection in a single file transfer. The file will have to be split and sent in pieces... then you can take advantage of both connections. Multithread test aside, you should be able to open two browser windows on the download test and start a larger test manually (one that will give you at least 10-15 seconds) on both windows. Try to do it quickly. If your bonding is balancing the load well the tests shouldn't affect each other. And you'll get two similar results... which you can then combine to get a total aggregate speed. As long as the two tests started at nearly the same time the final combined number should be highly accurate. (though not perfect because the tests were initiated by hand, staggered start time will raise the score slightly.) --- this scenario is only two threads but the score should be close to what you get in the multithread test if things are running well. ... this is one of the reasons I say "Versatile" on the home page. If you're smart you can use this test is different ways for which it wasn't originally designed and it still works. Good to know - I did notice on the multi-thread that it appeared to be balancing across my WAN ports - which was a good sign for me. In all honesty, the intent of bonding the second connection was to be able to load balance the connection when it took a dive in the evening. Which seems to have worked last night when I was at work. While it was not perfect, it does appear to have at least alleviated a measure of the issue since I am splitting the data between the two connections. VoIP is is obviously not affected in this test because that traffic establishes its session then stays on that interface. BTW, this bonding was at the suggestion of the tech because he noticed the router and noted I had a DSL backup connection attached to it. I do not know how long Cox will let me have the second interface for free so, obviously getting them to resolve the single interface issue of utmost priority. Were you able to review my results Ca3le? Any thoughts? Cox denies the node is overloaded but also noted the node is only putting out 70 mbs where the other nodes nearby are putting out around 140 - 160 mbs. The also told me they know they are only getting 1.3 - 1.5 volts on the fiber signalling from the Office to our area (hope I stated that correctly) where I was advised by the Plant Tech it should be 3 volts. Evidently, Cox was aware of the shortfall and had plans for a fiber amplifier between our area and the main office but scrubbed it due to budget. All the signal levels from what I could read 'over the shoulder' at the tap were nominal Friday - which was a big change from Monday where we were seeing 2 - 4 % packet loss and 90+ ms jitter on VoIP tests and throughput tests to the tap of about 40mbs. Admittedly, I know enough about the WAN side of things to be dangerous which is the reason I am reaching to the forums for help. The speed drops may cost me my job since I telecommute if I don't get them resolved soon. Thank you for any additional insight you might be able to provide. Link to comment Share on other sites More sharing options...
Recommended Posts