Just a couple notes - I'm running a VPN on a 486/66 without an issue in terms of bandwidth performance (its only 1 tunnel, but it does 45 Kilobytes/sec without any problems - thats the max both ends of the tunnel can send at give or take a couple of kilobytes). I'm also running a few other "non default" packages (snmp, labrea, QoS) - so it's quite possible that the box being used here isn't the issue.
One decent test of bandwidth (at least internal to your ISP) is to find out if the host any downloads internally. Rogers (formerly of the @home chain of ISPs) used to (I'm not sure if they still do), but it was generally a good measure of performance internally. So find out if they host a customized version of IE or Netscape that you can download. These are usually sizable enought that you get a good indication of download speed (assuming the server isn't overloaded or throttled). HTH S >From: Ray Olszewski <[EMAIL PROTECTED]> >To: Dennis Stephens ><[EMAIL PROTECTED]>,[EMAIL PROTECTED] >Subject: Re: [leaf-user] FW Through Put >Date: Tue, 30 Apr 2002 11:39:07 -0700 > >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 _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [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
