|
Posted by Affan on April 7, 2007, 5:51 pm
If you were Registered and logged in, you could reply and use other advanced thread options
I was trying to understand the general behavior of LAN with MAC's that
have CD capability i.e. Ethernet.
One of the papers that I looked at "JiaWang and Srinivasan Keshav.
Efficient and accurate ethernet simulation.
In LCN '99: Proceedings of the 24th Annual IEEE Conference
on Local Computer Networks, page 182,Washington, DC, USA, 1999.IEEE
Computer Society."
mentions that even under high load the throughput doesnot decay i.e
remains stable.
Is that correct for all Ethernet? it seems counter intuitive as with
more contenders, even if nodes can detect
collision, it would still lead to a larger time time any one gets
through?
A naive simulation (matlab) showed that the response of the network
does remain stable but with a few nodes getting to hog the channel
completely i.e. packet startvation. But I am not sure if this is a
correct understanding of Ethernet's performance. Can some one please
comment?
Thanktyou.
|
 
| |
Posted by Albert Manfredi on April 9, 2007, 4:26 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>I was trying to understand the general behavior of LAN with MAC's that
> have CD capability i.e. Ethernet.
> One of the papers that I looked at "JiaWang and Srinivasan Keshav.
> Efficient and accurate ethernet simulation.
> In LCN '99: Proceedings of the 24th Annual IEEE Conference
> on Local Computer Networks, page 182,Washington, DC, USA, 1999.IEEE
> Computer Society."
>
> mentions that even under high load the throughput doesnot decay i.e
> remains stable.
> Is that correct for all Ethernet? it seems counter intuitive as with
> more contenders, even if nodes can detect
> collision, it would still lead to a larger time time any one gets
> through?
>
> A naive simulation (matlab) showed that the response of the network
> does remain stable but with a few nodes getting to hog the channel
> completely i.e. packet startvation. But I am not sure if this is a
> correct understanding of Ethernet's performance. Can some one please
> comment?
This is a shared Ethernet, where CSMA/CD is used to gain access. So I
think the Matlab simulation is good.
The short version of what happens is that in a heavily loaded shared
Ethernet, a few nodes will gain access and send frames. Other nodes will
sense a carrier or collisions, and back off and try again. If a node has
been unsuccessful at sending a frame, it backs off a little longer (on
average) for each failed attempt, until the 10th attempt, then use the
long max wait of the 10th attempt for the remaining 5 attempts. (Nodes
try up to 15 times, then give up and discard that frame, and something
at a higher OSI layer can worry about what to do next.)
But the thing is, the nodes that were successful the first time will use
short retry periods on their next attempts. They think everything is
okay. So because they retry so quickly, they will in effect get
preferential treatment comnpared to the other nodes waiting patiently
with their (on average) longer retry intervals.
So the total load on the Ethernet itself will be right up there, but
many of the hosts connected to that Ethernet will see very poor service
or even dropped frames.
Aside from the situation of some nodes having a lot of data to send,
there is also the possibility of a large number of nodes on the network,
each having some data to transmit. The effect is similar. The larger the
number of nodes, the more likely it is that two or more will make
attempts at exactly the same time, or at least will make attempts while
another node is sending a frame. Either will result in either a carrier
sense or a collision detect, and will cause a longer backoff wait (on
average). The closer you get to 1024 nodes per Ethernet, the more likely
it will be for nodes to have the same retry wait, and to experience
collisions. At 1024 nodes, you will be guaranteed that collisions will
always occur for some nodes.
Still, even in this case, there will be some nodes that get frames
through will relatively short waits, so the Ethernet itself will
experience a lot of throughput.
Clause 4.2.3 of IEEE 802.3-2005 explains the mechanism of half and full
duplex frame transmission.
Bert
|
|
Posted by glen herrmannsfeldt on April 10, 2007, 7:55 am
If you were Registered and logged in, you could reply and use other advanced thread options
Albert Manfredi wrote:
(snip)
> The short version of what happens is that in a heavily loaded shared
> Ethernet, a few nodes will gain access and send frames. Other nodes will
> sense a carrier or collisions, and back off and try again. If a node has
> been unsuccessful at sending a frame, it backs off a little longer (on
> average) for each failed attempt, until the 10th attempt, then use the
> long max wait of the 10th attempt for the remaining 5 attempts. (Nodes
> try up to 15 times, then give up and discard that frame, and something
> at a higher OSI layer can worry about what to do next.)
> But the thing is, the nodes that were successful the first time will use
> short retry periods on their next attempts. They think everything is
> okay. So because they retry so quickly, they will in effect get
> preferential treatment comnpared to the other nodes waiting patiently
> with their (on average) longer retry intervals.
The result, though, is that such nodes will get a burst of data
out, but overall, assuming all hosts have the same amount to send,
it is fair. Also, it is likely more efficient. Consider a traffic
light that let only one car from each direction each green.
(Not counting traffic meters.) It is more efficient to let a
group of cars through on each green.
> So the total load on the Ethernet itself will be right up there, but
> many of the hosts connected to that Ethernet will see very poor service
> or even dropped frames.
In the more usual case of a small number of hosts with a lot of
data to send, it works pretty well.
(snip)
> The closer you get to 1024 nodes per Ethernet, the more likely
> it will be for nodes to have the same retry wait, and to experience
> collisions. At 1024 nodes, you will be guaranteed that collisions will
> always occur for some nodes.
I have seen this before, and I don't believe it. First, even with
1024 nodes it would be unusual for all to have data to send at
the same time. Even more, though, nothing special happens at
1024 nodes.
Consider that 1024 hosts do want to send at the same time.
At maximum backoff each chooses a random number, and
has probability 1/1024 of choosing one. The probability
that none choose one is (1023/1024)**1024, about 0.367, in
which case two or more is the winner. The probability that
a given host is the only one to choose one is
(1/1024)*(1023/1024)**1023, about 0.368/1024 or 0.00036.
The probability that only one host chooses one is
(1023/1024)**1023, or about 0.3680. The probability
that none choose one, such that two or more is the winner
is, as above, 0.3677. The probability that only one
chooses two and wins is about 0.3680*0.3677 or 0.135.
The probability that none choose one or two is
(1022/1024)**1024, about 0.3677**2 or 0.135. The probability
that only one host chooses the lowest value, then, is
about (0.3680)/(1-0.3677) or 0.582. That is
(1023/1024)**1023/(1-(1023/1024)**1024) or
For 1025 hosts, then, the probability that only one host
has the winning backoff count is slightly worse,
at (1023/1024)**1024/(1-(1023/1024)**1025), about 0.581.
With each additional host it gets a little worse, but there
is no discontinuity at 1024 hosts trying to send at the
same time.
-- glen
|
|
Posted by Robert Redelmeier on April 10, 2007, 9:06 am
If you were Registered and logged in, you could reply and use other advanced thread options
> I was trying to understand the general behavior of LAN with MAC's
> that have CD capability i.e. Ethernet. One of the papers that I
> looked at "JiaWang and Srinivasan Keshav. Efficient and accurate
> ethernet simulation. In LCN '99: Proceedings of the 24th Annual IEEE
> Conference on Local Computer Networks, page 182,Washington, DC, USA,
> 1999.IEEE Computer Society."
> mentions that even under high load the throughput doesnot decay i.e
> remains stable. Is that correct for all Ethernet? it seems counter
> intuitive as with more contenders, even if nodes can detect collision,
> it would still lead to a larger time time any one gets through?
> A naive simulation (matlab) showed that the response of the network
> does remain stable but with a few nodes getting to hog the channel
> completely i.e. packet startvation. But I am not sure if this is
> a correct understanding of Ethernet's performance. Can some one
> please comment?
This is the fairly well-known "Ethernet capture effect" [qv]..
I think it's helpful to understand ethernet in a historical
context: it was developed as a simple competitor to complex,
directive networks like Token-Ring. The basic idea was to
provide _lots_ of bandwidth (more than any one station could
saturate) so channel arbitation could be simplified.
This historical model has largely been violated as CPU speed
increases have vastly outpaced network (and other periperal)
speeds. Fortunately, most ethernets have gone "switched" and
no longer experience collisions (although various analogous
unpleasant things can happen inside the switch electronics).
In particular, a fast station might have more data to send before
the waiting stations back-off timers expire. Software beating
hardware. Adjusting the ethernet parameters would have various nasty
side-effects (smaller allowable diameter), so hasn't been done.
-- Robert
|
|
Posted by DLR on April 10, 2007, 12:33 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> I think it's helpful to understand ethernet in a historical
> context: it was developed as a simple competitor to complex,
> directive networks like Token-Ring. The basic idea was to
> provide _lots_ of bandwidth (more than any one station could
> saturate) so channel arbitation could be simplified.
I'm fairly certain that TR came after Ethernet. Wikipedia seems to back
me up but I don't consider this a fully authoritative source. :)
|
| Similar Threads | Posted | | Embedded ethernet with high throughput | September 25, 2005, 10:12 pm |
| high availability and fiber channel | April 12, 2008, 9:32 am |
| Low-cost, high-quality design team | October 16, 2005, 2:05 pm |
| USB Ethernet controllers that use the ASIX AX88772 or AX88172 USB-Ethernet bridge devices | August 19, 2005, 4:04 pm |
| Difference between Ethernet 2 and 802.3 Frame per the Ethernet FAQ | July 28, 2006, 9:02 am |
| ethernet hub | April 27, 2006, 2:44 am |
| WAN Ethernet | May 2, 2006, 4:20 pm |
| Ethernet TAP | July 30, 2007, 12:28 am |
| Do I have an Ethernet card? | February 20, 2005, 10:48 am |
| Ethernet Repeaters | March 9, 2005, 8:10 am |
|
|
NewsGroups 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map