On Fri, 2002-10-11 at 06:27, Pierre Fortin wrote: > On 10 Oct 2002 20:29:32 -0700 Jack Coates <[EMAIL PROTECTED]> wrote: > > Jack, > > Guess I've been quiet on this list for too long and don't recognize all > the names; worse, not all new members know me... oh well... :> > > First chill out... my intent was to get the "me too'ers" to back off from > using bing cuz it's a "cool tool"... > > > On Thu, 2002-10-10 at 19:46, Pierre Fortin wrote: > > <snip> > > > <flame> > > > > > > Folks, > ^^^^^ == NOT targeted at an individual > > The MAIN issue I was addressing was that people see some "neat _tool_", > rush out and get a copy, then proceed to ADD to the problem(s) someone > else is trying to resolve -- the equivalent of Internet > "rubber-neckers"... > > > First, you assume that I don't know the current user or bandwidth load > > of the circuit, when in fact I know both and am working with my ISP to > > troubleshoot a problem. > > "working with my ISP" is NOT clear proof that either or both parties > understand the symptoms, the effects, etc... worse, _altering_ the > problem by injecting additional traffic which changes what is being > analyzed. Increasing traffic this way will only move you closer to the > "avalanche" mode quicker -- it will not help you figure out the problem > (unless you are looking for a one in which all-0s or all-1s is impacting > the link). > > > <snip> > > > "Tools" like this are unscientific and in an indirect way a DDoS > > > attack on the network. > > > > And second, you assume that bing is in the same class as rape.c. From > > the highly edifying man page: > > DESCRIPTION > > Bing determines bandwidth on a point-to-point link by > > sending ICMP ECHO_REQUEST packets and measuring their > > roundtrip times for different packet sizes on each end of > > the link. > > > > The actual packet stream used to measure bandwidth on the DS-3 was 3.6 > > kbps. > > So, can you tell me why it would even be necessary to measure this > link...? A DS-3 is (rounded) 45Mbps. If this is a *fractional* DS-3, I > could see the interest in finding the speed; but I'd simply *ask* the ISP > who **should** know how it's deployed -- especially when "working with my > ISP"
Anyone who thinks that an ISP knows what they are doing just because they are an ISP isn't up on on the ins and outs of the ball game. > > Besides, since you haven't found & fixed the problem, you can't say that > the link is not just 2kb from avalanching... > > Do you know the characteristics of all the components involved in "round > trip times"...? > Here's a *partial* list: > - available memory (sender, routers, target) > - queue sizes (tx & rx) > - buffer availability (tx & rx) > - prioritization (sender, routers, target) > - queue position ( " ) > - traffic already on wire > - bit transit time > - bit insertion (gapped clock): time on wire is longer than packet size > - packet size (changes RTT -- duh) > - packet loss > - retransmission > - "avalanching" > - accuracy of analysis "tool" > - etc.... > > Generally, over the years, I've found this type of "tool" to be more of a > hindrance in finding the root cause of problems... I can't recall the > number of times I've found the "tools" to be bogus... > > > Thanks for playing! > > When it come to problems, I don't play... usually, I end up being called > upon because there's more than one cause which the average troubleshooter > can't figure out... I don't know what's going on in your case; but I'd > bet you that bing will just delay finding the real cause(s)... > > Tell us your problem(s)** and maybe we can help... Sorry, I didn't follow > this entire thread -- IIRC, the original poster wanted to know how to > determine 10 vs 100 Mbps ethernet... Using tools like bing on a locally > attached, personal link is one thing; using it on shared 'net resources is > an abuse, IMO -- and the reason for my flame. > > ** just the facts... can't begin to tell you the number of problems where > I've had to debug the reporter's analysis/interpretation *before* I could > begin to debug the actual problem... > > Hope this makes sense... I just woke up and am still groggy... :^) > > Enjoy, > Pierre Pierre back down Please. This is a neat tool yes. It does have it's place yes. It doesn't add any more traffic than normal pings. Take a look at the tool and it's algorithms. You'll find that the numbers it produces are only accurate on a Lan but over a connection from say an office to the local Telco, level 3 etc etc. It can be very useful for providing proof that Your Unix box isn't the reason you've been experiencing a 40% drop in traffic speed over the last 3 months. (Yes Level 3 and Pac Hell have both told me that our Linux Firewalls and servers were the reason that our t-3 had intermittent speed drops of 75% or more at really unusual times.) As if running M$ crap would suddenly make a bad fiber splice good again. (Bing proved the slowdown. and an OTDR showed the location of the break.) James > > ---- > > Want to buy your Pack or Services from MandrakeSoft? > Go to http://www.mandrakestore.com
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
