At 12:04 PM 4/30/02 -0500, Dennis Stephens wrote: >Have started this morning with a cable modem problem and worked through it >with Tech Support. Now the through put is less than half of what it should >be. How can I determine that the problem is on the provider's side of the >system and not in my firewall or home network?
For our purposes, a good starting place would be describing what you mean by "through put is less than half of what it should be". What throughput are you expecting, what are you getting, and how are you measuring it (include between where and where)? I ask because the traceroute result you report below is not really a local throughput measure, and response delays of the sort you mention there are far from surprising. I couldn't repliacte your experience this morning, but then I'm "closer" to Yahoo (only 10 steps) than you apparently are. The only thing the cable company can deliver on is *local* throughput, for the bandwidth between its head end and your cable modem. (Arguably, it can be held account for the quality of its connections to the broader Internet as well, but it can't be expected to deliver speed at, say, the Yahoo end of the connection.) traceroute (or ping) latencies *can* indicate throughput problems, but the better test for that is pinging your gateway address from the router itself; then all the connectivity between you and the ping target is the responsibility of the cable ISP. The usual source of degredation on cable connections is congestion ... a cable connection is really a big LAN, in which you and other users share bandwidth. The cable companies like to point fingers at what they call "bandwidth hogs", but the real problem is that they advertise a grade of service greater than what their actual technology can deliver (the so-called "bandwidth hogs" are just the people who try actually to use the bandwidth they've been promised). In practice, with equipment of the quality you are using, I've seen about a 10% hirt on throughput. But only at the higher levels of LAN-to-LAN routing (nominally 10 Mbps; in practice, about 5 Mbps). The usual range of offsite connections -- 384 Kbps to 1544 Kbps -- does not normally induce router-based throughput losses. >They are taking the >position (of course they would), that they can not see a reason for the >reduction. The Dachstien floppy is working fine, with only a slight hole >poked through it for my VPN connection to the corporation. A 486/66 is plenty fast for a normal NAT'ing router, but it isn't very much horsepower for running a VPN. From what you wrote, I can't tell where in the system the VPN'ing is being done. If on the router, that could be slowing things down. When you are having speed problems, what does the router's CPU utilization look like? (Can someone remind me how to check this in Dachstein? I usually use top for this, but I don't think Dachstein includes it.) >Everything is >working, the weblet, the bandwidth monitor et al. Just working >slowly. Do you really mean that a connection from the Weblet to a host on the LAN is "working slowly"? If so, this suggests a local problem, not a cable-side problem. >How do I determine where a bottleneck or degradation is >occurring? Did a traceroute from here to yahoo and had a hop that was 200+ >ms and one other of the 22 hops that was 700+.ms. Where was "here"? The router or a host on the LAN behind the router? Was the VPN involved? Depending on time of day and other details, delays of this sort can occur without the cable company (or anything else local) being at fault. >Truly appreciate any >guidance and greatly appreciate the programming and work of all that helped >with this great application. > >FW 486/66 48MB RAM > >Apr 30 09:39:02 xx kernel: NE*000 ethercard probe at 0x300: 00 40 f6 18 8d 51 >Apr 30 09:39:02 xx kernel: eth0: NE2000 found at 0x300, using IRQ 10. >Apr 30 09:39:02 xx kernel: NE*000 ethercard probe at 0x240: 00 40 f6 18 c5 1d >Apr 30 09:39:02 xx kernel: eth1: NE2000 found at 0x240, using IRQ 12 -- ------------------------------------"Never tell me the odds!"--- Ray Olszewski -- Han Solo Palo Alto, CA [EMAIL PROTECTED] ---------------------------------------------------------------- ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
