Re: packet error rate
- From: roberson@xxxxxxxxxxxx (Walter Roberson)
- Date: Wed, 08 Feb 2006 20:07:53 GMT
In article <z-ydnaWwY9wd13fenZ2dnUVZ_tqdnZ2d@xxxxxxxxxxxx>,
Jeff B <jbeard_No-SpAm_1185@xxxxxxxxxxxx> wrote:
Ethernet is a uncontrolled, contention network -- the writing of packets
takes place without looking to see if the link is already busy.
Not so: writers look to see if they can tell if the link is already
busy, and if they can detect it then they back off.
This generates "collision" which must be retried.
When a writer cannot tell that a link is currently busy, and that
it has been long enough since the link was last busy, then the writer
will start trying to write the packet. If another writer happens to
start writing in the time before the signal from the first reaches it,
*then* you get a collision and need a packet retry.
Retries due to collisions do not require effectively flushing an
entire TCP window-full of data [in the absence of SACK].
When the link is running
at ~70% utilization, these collisions will start to occur more
frequently, and thus generate more retries. This is *not* considered an
*error* case and will not show up as PERs.
Small expansion: the average number of collisions for a packet is
proportional to 1 / (average remaining bandwidth fraction), so it
goes up rapidly as you get closer to link saturation. It -is- considered
an error case for a packet to need 16 retries, but such instances
will not show up as PERs.
.
- References:
- packet error rate
- From: fangyong.F@xxxxxxxxx
- Re: packet error rate
- From: Walter Roberson
- Re: packet error rate
- From: Jeff B
- packet error rate
- Prev by Date: Re: IP Reservation/MAC
- Next by Date: Re: Home firewall recommendations
- Previous by thread: Re: packet error rate
- Next by thread: Getting a game working...
- Index(es):
Relevant Pages
|
