Date: Fri, 25 Feb 2000 09:53:37 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: cwasser@v-wave.com (Chris Wasser), freebsd-current@FreeBSD.ORG Subject: Re: dc0 wierdness with Compex Freedomline Message-ID: <200002251753.JAA70936@gndrsh.dnsmgr.net> In-Reply-To: <200002251625.LAA30533@khavrinen.lcs.mit.edu> from Garrett Wollman at "Feb 25, 2000 11:25:59 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Fri, 25 Feb 2000 01:13:51 -0800 (PST), "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> said: > > >> [I wrote:] > >> quite right. In a CSMA/CD medium access protocol, like that used by > >> Ethernet, the actual capacity of the link is always(*) somewhat less than > >> 100%; the exact value depends on the precise parameters of the > >> transmissions at both ends.(**) > > >> (*)In non-trivial conditions; i.e., when actual work is being done. > >> (**)I've heard numbers between 70% and 95%. > > > And the major set of parameters that effect the higher side of this > > number are MTU(Maximum Transmission Unit) and IFG (Interframe Gap) > > and the protocol overhead of what ever proto you are using. > > Nope. Those two values are defined by the protocol, and are not > parameters at all. (It's only a parameter if it could conceivably be > varied in an experiment.) Don't tell the guys at PARC, Intel, DEC or TRW these are not parameters, the MTU as defined by the ethernet specification has a minimal and maximal value. That pretty much makes it a parameter. Also the 1518 bytes is the in-spec maximal but many chips, even the old 82586, could be programmed to do 4K or larger frames. (TRW takes advantage of the 82586's ability to do 16KByte frames for pumping huge images around very effecently on ethernet. Given that I have worked on real world systems that modify the MTU to reach a desired goal I can state without a doubt that MTU is a paramter, as I have changed not just in experiments or on paper, but in the real world with 1000's of systems deployed using the tweaked value, including having to hack out the jabber circuits in hubs to deal with the frame size.) > The relevant parameters are the > transmission schedules of the end stations, which are of course > dynamic in most real-world applications, but not necessarily so. Those parameters mean nothing when caclulating the Data Link layer maximal transmission rate possible. If they use them then you are calculation something else, like the application maximal transmission rate. > These can be boiled down into a single number P(coll), which is the > probability that two stations will cause a collision by transmitting > at precisely the same time. Although this seems unlikely, certain > kinds of network protocols can unintentionally synchronize > end-stations to the extent of causing pessimal behavior. I specifically excluded P(coll) by stating point to point or effectively point to point via switching. P(coll) is 0 in this situation, again going to my note of keyword ``maximal''. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002251753.JAA70936>