Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!ucsd!sdcsvax!ucsdhub!jack!nusdhub!rwhite From: rwhite@nusdhub.UUCP (Robert C. White Jr.) Newsgroups: comp.dcom.lans Subject: Re: ether errors -- vaxen&4.3&suns&sequent&etc Message-ID: <917@nusdhub.UUCP> Date: 18 Feb 88 03:21:23 GMT References: <8277@e.ms.uky.edu> <8345@e.ms.uky.edu> Organization: National University, San Diego Lines: 72 Summary: lot's of "errors" on "some machines" Hi all, In response to te query about some machines having very high numbers in their error loggs, I have this 802.3 anticdote. This behavior was noticed on a test instalation of the Starlan (r) product, but I would bet cash money that it is a protocol oddity in 802.3. Simply put, The observed product [which runs at 1mbs instead of 10mbs] would post errors to the status log of a machine attempting to assert a packet on a lan segment whenever an other machine would attempt to claim a new address. The interaction goes something like this: 1) before a name can be claimed, the system desireing to implement the name must be shure the name is unique. 2) to assure itself that the name is unique the requesting machine sends a short data packet with a _very_ high priority. 3) the network access unit formats this packet as a datagram addressed to the, hopefully mythical, name. 4) the adapter, sensing a priority requirement [and to give the user a fair chance on a busy net] listens for a time slot on the common carrier. If this time slot is not available in _very_ short order, the adapter will usurp bandwidth by asserting carrier on the line anyway. When the other machines sense carrier they signal a collision and back-off to re-time and contend. 5) When the receive lines go quiet, with a wait time aproaching 0, the E_DATA packet is sent and must propigate through the network. 6) steps 4 through 5 are retried cyclicly for itterations X at a delay of Y, where X is about 6 attempts and Y is about 5 seconds [your milage may vary ;-)] 7) Steps 2 through 6 are repeated for each name requested. This is an observed phenominia based on an educated guess, but it produces the symptoms you described. When ever a machine adds a name to the network for any reason, this rudeness is observed. It will his servers the hardest, as they are most likely to be sending a packet at any given instant. Bridge hardware will propigate the generated messages, but in a polite fassion, and so effectivly insulate against the problem. Also, as servers have a longer [on avrage] time between resets [or stat clearing's anyway] their numbers tend to be artifically high. This behavior seems to be within the accepted standard however, so cest' la gaere. When high envelope events [like 20 students starting their net sessions at the same time] occur, preformance can get choppy. This may not be as common, or even true at all, on the ether-net systems because of the generally faster environment. a good experimental check is to isolate a net section and start a stat loop. [a stats b stats c .....] Then ask for a few names from a machine outside the loop [but on the same segment]. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< << All the STREAM is but a page,<<|>> Robert C. White Jr. << << and we are merely layers, <<|>> nusdhub!rwhite nusdhub!usenet << << port owners and port payers, <<|>>>>>>>>"The Avitar of Chaos"<<<<<<<<<<<< << each an others audit fence, <<|>> Network tech, Gamer, Anti-christ, << << approaching the sum reel. <<|>> Voter, and General bad influence. << <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ## Disclaimer: You thought I was serious???...... Really???? ## ## Interogative: So... what _is_ your point? ;-) ## ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^