[SunRescue] Sparc 10 cover plates

Tue Dec 21 07:28:37 CST 1999

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF4BB7.49DFA95A
Content-Type: text/plain;
	charset="iso-8859-1"

} > > No you won't. Taking TCP as an example, a data packet
} > > containing 8K of data could get ack'ed by a 20 byte
} > > packet. Looking at it this way saturation
} > > appears nearer 9Mbit/s.
} > 
} > True. If you have only two units 

*communicating*

} > on the physical network.

} > When you pass 4 to 5 Mbit/s you'll notice an
} > inrease in collisions,
} > which causes retransmissions. Guess what happens
} > then... *grin*
} 
} I don't think so...we have a small network 16 systems here on 
} Two SMC Hubs
} and we get local trafic at 8.8 - 9.1 Mbit/sec on ordenary 
} 10Mb/s network.

I added the word communicating above because that clears things up.
The key point that Paul made was "increase in collisions".  If your
office network happens to only have low background traffic on it or
short bursts of high bandwidth traffic (say people web browsing) 
then you can get the 8 -> 9 Mbit/sec data transfer when you go for 
your ftp.  That was what I was assuming.

If your office network has everyone working on NFS mounted file systems
and the like (i.e. a big computing lab) then the high background traffic 
generates a large number of collisions (hub receives packets from two hosts
at the same time) which in turn causes the hosts to have to retransmit a
larger
number of packets and hence lowers available bandwidth.

If you consider the following case

                Host1
                  |
                  |
         Host2---HUB---Host3
                  |
                  |
                Host4

If you start an ftp from host1 to host2 whilst the other two are
are doing nothing then you'll get your 8 - 9 Mbit/sec

If you simultaneously start an ftp from host1 to host2 AND an ftp
from host3 to host4 then the situation changes. Assuming the worse
case then because of collisions you'll lose half the packets you send
so have to retransmit the half you lose - but half of those might get lost
as well so you'll have to retransmit half the retransmitted packets and 
so on (if fact it's a bit worse than this but ...) and the effective
bandwidth of you're network starts falling through the floor.

Stuart

------_=_NextPart_001_01BF4BB7.49DFA95A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: [SunRescue] Sparc 10 cover plates</TITLE>
</HEAD>
<BODY>

} > > No you won't. Taking TCP as an example, a data packet
 } > > containing 8K of data could get ack'ed by a 20 byte
 } > > packet. Looking at it this way saturation
 } > > appears nearer 9Mbit/s.
 } > 
 } > True. If you have only two units

<P><FONT SIZE=2>*communicating*</FONT>
</P>

<P><FONT SIZE=2>} > on the physical network.</FONT>
</P>

} > When you pass 4 to 5 Mbit/s you'll notice an
 } > inrease in collisions,
 } > which causes retransmissions. Guess what happens
 } > then... *grin*
 } 
 } I don't think so...we have a small network 16 systems here on 
 } Two SMC Hubs
 } and we get local trafic at 8.8 - 9.1 Mbit/sec on ordenary 
 } 10Mb/s network.

<P><FONT SIZE=2>I added the word communicating above because that clears things up.</FONT>
<BR><FONT SIZE=2>The key point that Paul made was "increase in collisions".  If your</FONT>
<BR><FONT SIZE=2>office network happens to only have low background traffic on it or</FONT>
<BR><FONT SIZE=2>short bursts of high bandwidth traffic (say people web browsing) </FONT>
<BR><FONT SIZE=2>then you can get the 8 -> 9 Mbit/sec data transfer when you go for </FONT>
<BR><FONT SIZE=2>your ftp.  That was what I was assuming.</FONT>
</P>

If your office network has everyone working on NFS mounted file systems
 and the like (i.e. a big computing lab) then the high background traffic 
 generates a large number of collisions (hub receives packets from two hosts
 at the same time) which in turn causes the hosts to have to retransmit a larger
 number of packets and hence lowers available bandwidth.

<P><FONT SIZE=2>If you consider the following case</FONT>
</P>

<P><FONT SIZE=2>                Host1</FONT>
<BR><FONT SIZE=2>                  |</FONT>
<BR><FONT SIZE=2>                  |</FONT>
<BR><FONT SIZE=2>         Host2---HUB---Host3</FONT>
<BR><FONT SIZE=2>                  |</FONT>
<BR><FONT SIZE=2>                  |</FONT>
<BR><FONT SIZE=2>                Host4</FONT>
</P>

<P><FONT SIZE=2>If you start an ftp from host1 to host2 whilst the other two are</FONT>
<BR><FONT SIZE=2>are doing nothing then you'll get your 8 - 9 Mbit/sec</FONT>
</P>

If you simultaneously start an ftp from host1 to host2 AND an ftp
 from host3 to host4 then the situation changes. Assuming the worse
 case then because of collisions you'll lose half the packets you send
 so have to retransmit the half you lose - but half of those might get lost
 as well so you'll have to retransmit half the retransmitted packets and 
 so on (if fact it's a bit worse than this but ...) and the effective
 bandwidth of you're network starts falling through the floor.

<P><FONT SIZE=2>Stuart</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF4BB7.49DFA95A--