All that said, it really helps to have someone express what service (e-mail, news, web surfing speed)is affected and how. Saying something like, "My e-mail is slow," doesn't give us a lot to work with. It would be best expressed if you said something like, "My e-mail keeps timing out," or "I can't get to my personal web space, it keeps giving me error x." That's sufficient substance to know where to start trouble shooting, and it's a universal language most tech support professionals understand.
On speed tests, that's an imperfect science as well. Since the packet(s) being measured leave the Cox network(at some point), traverse the Internet and then return, your results are likely to be scewed if you only test once. In my humblest of opinions, the best measure comes from running the test at the same site at different times over a number of days(making sure you clear your cache after each test). This establishes a trend of peaks and valleys, and can give you a better indication of your particular connection's performance. Yet, even this method has it's down side. Once you leave the Cox network you'll likely pick up those Internet dust bunnies (external latency, slow or congested servers, etc.) that can return slower speed results that what you're actually getting through the Cox network. Again, multiple tests over a period of days can minimize the impact of this.
Back to the gospel thing, there are some really good tools here at this site. On occasion, we have been able to help customers just by interpretting the results they've posted here. There are just some obvious things that jump right out. However, what we've found is that a blend of tests work best. In most cases we revert to following up on ping tests and the findings of tools here with our own internal diagnostic tools. That way, we have as much data as possible and can better determine what things to look at and solutions to try.
Next, pinging the network and trying to correlate packet loss as the cause of your specific problem falls a bit short of the mark. Latency could be a result of the ICMP packets being held while higher priority traffic gets passed. Some devices will even discard ICMPs and give a false positive reading on packet loss. Furthermore, networks are loaded with electronic devices that will experience hiccups (for lack of a better word). That you saw a ping spike or two in a twenty four hour period is probably not an indicator of a problem.
To all that, pinging to a specific interface can give you inconclusive results. You should try to ping through the interface to a known device on the other side. Also, it's not uncommon to see that a ping coming from the ingress side of an interface yields a different result than one coming from the egress side. For example, someone in Middle Georgia, pinging to an interface on the Atlanta network(pinging from egress point)might see packet loss, where someone from Phoenix pinging (ingress)that same interface would see none.
So, what do you do? Well, don't discount packet loss or latency completely. This may indeed be an indicator of a problem with a router or interface. Do post the results of trace routes and ping plots, just remember to further quantify the problem by telling a little bit about what drove you to start trace routing in the first place (i.e. - slow download speeds (under 1 MB), frequent disconnects, modem losing sync, etc.)
Secondly, check all the obvious things -- your cable connections, RWIN settings (see the Tweaks forum here), look at the modem diagnostics if you have access to it, make sure you have all the latest patches for your browser, e-mail, and news client, etc. Check »support.cox.net for details on technical problems and service configuration.
If you're an online gamer, check the gaming forum here. Lots of pros to help you ensure your game and PC configurations are correct, and that you get the most out of the experience.
Also remember that the more info you can provide about your problem in the post, the easier it will be for other participants and tech support to assist in getting your problem resolved.
Feedback received on this FAQ entry:
The first time A wants to send an IP packet to B, it initiates a conversation like this:
1) A -> FF:FF:FF:FF:FF:FF, ARP who has 10.0.0.2? This is a broadcast ethernet frame. It goes to every computer connected to the segment.
2) B -> A, ARP I have 10.0.0.2. This reply is directed specifically to A.
Now A knows that B is on the same segment as itself and the ip address 10.0.0.2 is associated with the ethernet MAC 00:00:00:00:00:02. Any traffic bound for 10.0.0.2 is then addressed to 00:00:00:00:00:02. It caches this ARP entry so it doesnt have to rebroadcast every time it sends a packet to B.
The same principle applies to a CMTS. All the computers connected to cable modems registered on the CMTS are on a virtual ethernet. When the CMTS receives an ip packet, it sends out a broadcast ARP request to every computer attached to the interface for that subnet to find out what CPE MAC is associated with the IP. Most (all?) markets are now using ip bundling, which means that subnets span multiple interfaces. Because of this, each bundled interface has more customers on it, and thus they see a good deal more ARP traffic than they did back in the @Home days.
An ethernet ARP packet is only 60 bytes long, so the extra traffic does not affect the customers service in any way.
So to sum it all up:
1) Its normal for customers to see lots of ARP requests
2) Its normal for customers to see ARP requests for ip addresses on subnets other than the one their computer is currently on
3) The ARP traffic is harmless.
(SPECIAL THANKS: To the Cox abuse department for this input)
ARP traffic is INCLUDED in your data totals for your connection usage and does count against the amount specified in the Cox usage limitation policy. It is estimated that approximately 1GB per month in traffic to your connection is ARP packets.
The various network devices between the head-end and your cable modem have backup power available to keep them running during comercial power failure. Most distribution systems are actively monitored and will continue to operate on batteries for a number of hours. In this scenario, as battery capacity starts to dwindle below a certain standard, a technician is dispatched to the power suply and a portable generator is connected -- thus, keeping the connection alive. Other systems have backup generators which can maintain operation of the system as long as there is a fuel source.
UCD's are Upstream Channel Descriptor. These messages are sent from the CMTS on the downstream path basically telling a modem what upstream frequency it needs to be on.
The next error "Received Response to Broadcast Maintenance Request,..." is known as a T4 timeout. This sort of timeout can sometimes indicate possible upstream issues such as contention (competition for bandwidth with other modems). Periodically, the CMTS will send out "keep-alive" messages to the modems during their maintenance cycles. The error indicates that it received that broadcast packet, but due to unknown reasons it was not able to transmit a response (But no Unicast opportunity received). Sometimes this can be due to the amount of traffic on the upstream channel, upstream utilization, things of that nature. There are numerous possibilities as to why the modem was not able to transmit back. Once a modem encounters 16 T4 timeouts in a row the modem will reset its connection.
The next message is a normal message regarding the Organizaional Identifier (OID).
ToD stands for Time of Day. When the modem has established communication with the CMTS it accesses a TFTP server (Trivial File Transfer Protocol server) where it will obtain an IP address from the DHCP (Dynamic Host Configuration Protocol) server and syncs its time with the CMTS, hence the Time of Day request.
The next log entry "DHCP WARNING - Non-critical field invalid response," sometimes will occur during a DHCP lease cycle. DHCP clients request an address on startup and when they are approaching the end of their address lease period. When a client does not have a current lease, it broadcasts a DHCP discover message on its local network segment. All DHCP servers on the network segment copy this message, and respond with a broadcast message announcing that they have an address available. The requesting client chooses one of these offers, usually the first one it receives, and broadcasts a DHCP request message indicating that it has selected that server's offer. While a server is awaiting the client's selection, it can (and should) reserve the offered address so that it is not offered to another client in the meantime. The DHCP server then replies to the request message with a DHCP acknowledgement message which includes the client's IP address, subnet mask, default gateway, and other configuration information.
DHCP provides option fields to allow the client to request and obtain vendor-specific configuration information from the server. This error indicates that one of those options fields were invalid.
The last log entry to address is the "SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing and FEC Synchronization Framing. The CMTS periodically broadcasts a basic set of instructions used by all modems. This instruction set must be used by the modem to enable any further communication with the CMTS. QAM (Quadrature Amplitude Modulation) is the form of digital modulation used primarily in transmitting downstream data signals. During its scan, the modem must locate and synchronize with the QAM-64 or QAM-256 carrier that contains data necessary for modem operation. This synchronization is commonly referred to as QAM lock.
FEC (Forward Error Correction) places overheard or parity bits in the data stream to help identify and correct errors that may occur when data is transmitted through the network. During the modem's initialization process it must synchronize with these FEC protocols so that the FEC system can correct errors. Cable receivers also use this method of error correction. This can also be associated with PreFEC BER (Bit Error Rate[or Ratio]) and PostFEC BER.
So to sum up many of these errors are common which you will see frequently. The main errors to watch out for in my opinion would be the T3, T4, QAM/QPSK symbol timing and FEC synchronization framing. These could potential point to some signal issues which most likely need to be addressed by a technician.
Descriptions, courtesy of AZHSISUPPRT2