mryanbrown
join:2004-04-13
Glendale, AZ
| reply to Tony_Stuart
Re: [AZ] Cox Internet speeds.
Ikyuao I think it's very safe and certain to say that any TCP optimization on a client end is generally not required, ever. The amount of bandwidth dealt with doesn't require optimizations, but if you feel you need those few bytes/second on your consumer end NIC, be my guest. |
|
bentmember
join:2004-08-22
Gilbert, AZ
| reply to Tony_Stuart
Yes I have. They were checking into it and said there was an open ticket but I haven't heard anything for awhile. They said it would take time. I talked to one of my neighbors and he said he is having the same problem. I need to talk to more of them and have them all call in. |
|
Fubar
join:2001-02-20
Phoenix, AZ
| reply to bentmember
said by bentmember  :I have the same problems at night also. I doubt cox techs will come out at night which is when the problems occur. Latency and Bandwidth are absolutely horrible at night. Everything is pretty good during the day but nowhere near as good as it used to be. As I have posted before everything seemed to go to pot when On Demand was introduced to my area. I'm not sure if the bandwidth is shared but it still seems strange. I call and complain at least 5 times a week hoping it will get fixed. Based on what I have read here and elsewhere I'm pretty sure a node split is required to handle the problem. Have you been in contact with any of the techs here? |
|
bentmember
join:2004-08-22
Gilbert, AZ
| reply to Tony_Stuart
I have the same problems at night also. I doubt cox techs will come out at night which is when the problems occur. Latency and Bandwidth are absolutely horrible at night. Everything is pretty good during the day but nowhere near as good as it used to be. As I have posted before everything seemed to go to pot when On Demand was introduced to my area. I'm not sure if the bandwidth is shared but it still seems strange. I call and complain at least 5 times a week hoping it will get fixed. Based on what I have read here and elsewhere I'm pretty sure a node split is required to handle the problem. |
|
Tony_Stuart
join:2009-01-07
Phoenix, AZ
| reply to Tony_Stuart
Almost 2 months to the day, my internet has been fixed. They split the node early this morning. So far it is much much better. Will need about a week of testing to be sure. It only took calling them everyday for it to be fixed. For the first month I had technicians at my house just about every day. When that didn't work I finally got quite a few of neighbors to start calling in every day as well. That seemed to do the trick.
Thanks all for your suggestions.
Tony |
|
MaiShiranui74
join:2004-02-03 | reply to Tony_Stuart
I have the same problems as you I need to get a tech out too.
At least there is 1 more person with the same issue that I have! |
|
Tony_Stuart
join:2009-01-07
Phoenix, AZ
| reply to Tony_Stuart
Update:
Finally got a technician to come out after hours, and they recorded the extremely slow internet speeds. The technician recorded the numbers from the street, so had nothing to do with inside my house. I am currently waiting for another service call, for someone to come out and figure out where the bandwidth is going. Unfortunately they dont have a time scheduled for when that will take place.
So atm I call in everyday so that my acct continues to show there is still a problem. Atleast that way, they discount my bill. |
|
Dogfather
Premium
join:2007-12-26
Laguna Hills, CA | reply to Ikyuao
LOL. |
|
Ikyuao
Pro. debian Linux
join:2007-02-26
Wichita, KS
 ·Cox HSI
| reply to Dogfather
Nah, it isn't funny... TCP is still edge cutting with optional available so no new protocol needed for high speed WAN link with high delay over the internet.
--
Professional Linux environmental blows microsoft windows out of the water. |
|
Dogfather
Premium
join:2007-12-26
Laguna Hills, CA | reply to Ikyuao
You're too funny. |
|
Ikyuao
Pro. debian Linux
join:2007-02-26
Wichita, KS
·Cox HSI
2 edits | reply to AnonInTucson
I'm sorry, You are wrong about TCP optional options of a about flow control as like window scaling, timestamps, MSS and SACK and can be combined with congestion control perfectly. I understand deeply perfect about TCP flow control that I get great speeds, it is not flawed. And Mod, please lock this thread up before this gets winds up a out of control like crazy.
--
Professional Linux environmental blows microsoft windows out of the water. |
|
AnonInTucson
join:2008-12-18
Tucson, AZ | reply to vraeden
Unfortunately, your suggestion will most likely be lost on Ikyuao. His posts always manage to display a deeply flawed understanding of TCP flow control in completely broken english. It would be best to disregard his posts. |
|
vraeden
join:2007-06-21
Gainesville, FL
·Cox HSI
| reply to Ikyuao
said by Ikyuao :be quiet. I'm explaining to AZtech support how it works that between speeds and latency delay this the way what TCP do with high performance options works this the way. Unfortunately, your english is extremely difficult to understand. Your sentence structure is backwards and missing important transitions. Perhaps you should increase your study of english until you improve? |
|
Ikyuao
Pro. debian Linux
join:2007-02-26
Wichita, KS
·Cox HSI
| reply to tubbynet
be quiet. I'm explaining to AZtech support how it works that between speeds and latency delay this the way what TCP do with high performance options works this the way.
--
Professional Linux environmental blows microsoft windows out of the water. |
|
tubbynet
reminds me of the danse russe
Premium
join:2008-01-16
Chandler, AZ | reply to Ikyuao
said by Ikyuao :Hope that helps. nope. never does.
q. |
|
Ikyuao
Pro. debian Linux
join:2007-02-26
Wichita, KS
·Cox HSI
4 edits | reply to AZHSISUPPRT2
Yes and having larger window side buffer really can handling better in high latency environmental of WAN networks also I usually testing my speeds over some sites in 25 ms to 100 ms delay times and larger window side buffer can keep track with latency delay times at the same level what I get speed in exactly this the way. However smaller buffer like 64K buffer and at higher latency delay time levels then standard 64K buffer don't be giving you much speeds because latency delay times can reduces speeds so greatly in effect. My Linux PC ---> My cable modem that's it so I can get much faster speeds without using router hardware device since Linux includes flexible iptables and ip6tables firewall functionality. Hope that helps. P.S. if 64K congestion window fills out a buffer at one ms RTT really definitely gives you up to 500 Mbits but unforateunly 64K congestion window can't stand at 100 ms delay and degrades to 5 Mbits speeds down that is explain. Unless if you start with 64M buffer at 100 ms delay that could gives you 5 Gbits speeds that is very simple  And smaller buffer and higher latency delay times will take longer time and higher buffer and higher latency delay times will take much less time to get there. smaller buffer at higher latency delay times really definitely extrmemly inefficient for high speed broadband WAN link.
here's my test speed of bewteen my home in Wichita, KS and test speed site in Denver, CO over 400 miles of distance in about 100 ms delay with greater congestion window side buffer that gives me greater speeds that is very simple
So I can ignore packet delay as same as packet loss since larger window buffer are much sufficient enough.
Someday I will be professional IT either software programmer when I get into university school
--
Professional Linux environmental blows microsoft windows out of the water. |
|
vraeden
join:2007-06-21
Gainesville, FL
·Cox HSI
| reply to Tony_Stuart
Though I'll probably get blasted for saying it, but everytime I've seen this description on the forum, including in my own experience, it turns out to be just too many people in your neighborhood with probably a few of them doing heavy downloading. In my case, they doubled the node capacity to fix it and it really did work until just recently when they upgraded the speed again. I'm waiting a little bit before I complain again. |
|
AZHSISUPPRT2
join:2007-11-01
Phoenix, AZ
| reply to Ikyuao
I believe what Ikyuao is referring to is called "Flow Control" which takes place at the transport layer of the OSI model. I've included an article that explains it a bit more indepth and yes, this can have an affect on how fast a server and client communicate.
It took me a few tries to piece together what he was saying, but I believe this is it. Is this correct Ikyuao?
»www.tcpipguide.com/free/t_TCPWin···trol.htm
Thanks,
--
Chris@Cox Communications Arizona |
|
Ikyuao
Pro. debian Linux
join:2007-02-26
Wichita, KS | reply to lost404
You lost in what? |
|
lost404
join:2008-10-18
Tucson, AZ | reply to Tony_Stuart
I'm lost. |
|
