Priscilla, Never one to turn down a math problem, and my apologies if someone has already sent this in (and to any statisticians for my lack of handling of significant digits), but in answer to the question you posed earlier:
t = 0.011508433379980849966855711865655 seconds until the buffer is completely full. After the 1150th packet the buffer will be full. The 1151st packet will be the first to be dropped. ----------------------------------------------------- The work: serverpacketsize = 100 bytes serverrate = 100,000 pps serverrate = 100 bytes x 100,000 pps = 10,000,000 Bps = 10,000,000 x 8 bps = 80,000,000 bps clientmax = 10 Mbps = 10 x 1024 Kbps = 10 x 1024 x 1024 bps = 10,485,760 bps bufferpacketsize = 100 bytes buffer = 1000 packets = 1000 x 100 B = 1000 x 100 x 8 b = 800,000 b buffer = (severrate - clientrate) x time 800,000 b = ((80,000,000 bps) - (10,485,760 bps)) x t 800,000 b = (69,514,240 bps) x t t = (800,000 b) / (69,514,240 bps) t = 0.011508433379980849966855711865655 seconds until the buffer is completely full. bitcount = (80,000,000 bps) x t = (80,000,000 bps) x 0.011508433379980849966855711865655 s = 920674.6703984679973484569492 b packetcount = 920674.6703984679973484569492 b / 100 B = 920674.6703984679973484569492 b / 800 b = 1150.8433379980849966855711865 The 1150th packet will go through and the 1151th will be the first to be dropped due to a buffer overflow. ------------------------------------------------------------------ ***Please note: this all assumes a connectionless protocol. TCP will not overload the switch as the server will wait for the ack's before sending more packets. I believe many UDP based applications also implement some sort of acknowledgment at a higher (then transport) OSI level**** -Joe The Question: > Here's a hypothetical scenario: > > The server has a 100-Mbps NIC. It is connected to the switch. > The client has a 10-Mbps NIC. It is also connected to the > switch. > > The switch has 1000 buffers. Each buffer holds a 100-byte > packet. > > The server is sending 100,000 packets per second as fast as it > can (i.e. with no significant gap between the packets). Each > packet is 100 bytes. > > The switch is sending the packets out the 10-Mbps port as fast > as it can. > > After how many packets sent by the server will the switch start > dropping packets? > > A free book to anyone who gets the right answer! You must show > your work. :-) ------------------------------------------------------------------- -----Original Message----- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 12:56 AM To: [EMAIL PROTECTED] Subject: RE: is 10baseT dead? [7:65263] It's been a long day. Priscilla Priscilla Oppenheimer wrote: > > > DeVoe, Charles (PKI) wrote: > > > > > > What about htis. > > > The server tries to dump data to the client > > > over the 10M > > > pipe. The client cannot accept it as fast as the server can > > > put out. > > > Having a slower line to the client in effect will cause > > > degradation at the > > > server. > > I have a better answer and question than my previous wisecrack. > :-) I also bumped the conversation to the top of the Web site. > > Answer: The problem won't be the client not keeping up. The > problem will occur at a store-and-forward switch between the > server and client. (To connect 100-Mbps to 10-Mbps requires a > store-and-forward device. Let's say it's a switch.) > > So, the engineering question becomes, at what point will this > mythical store-and-forward switch start dropping packets? > > Here's a hypothetical scenario: > > The server has a 100-Mbps NIC. It is connected to the switch. > The client has a 10-Mbps NIC. It is also connected to the > switch. > > The switch has 1000 buffers. Each buffer holds a 100-byte > packet. > > The server is sending 100,000 packets per second as fast as it > can (i.e. with no significant gap between the packets). Each > packet is 100 bytes. > > The switch is sending the packets out the 10-Mbps port as fast > as it can. > > After how many packets sent by the server will the switch start > dropping packets? > > A free book to anyone who gets the right answer! You must show > your work. :-) > > Priscilla > > > > > > > > > -----Original Message----- > > > From: Steven Aiello [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 12, 2003 11:02 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: is 10baseT dead? [7:65077] > > > > > > > > > Scott, > > > > > > I think you have a great point, it seems that most of the > > > computer > > > technologies we have today are not taken full advantage of. > > > However > > > instead of taking the air out the sale's staff sales as it > > were > > > ( no pun > > > intended ). Why not suggest upgrade from the Idf's to the > > > server farm. > > > You could suggest Ether Channel to combine some of the > runs > > > you have > > > put in ( I'm sure ) when you are upgrading your networks. > > This > > > way you > > > have more bandwidth to the server farm and fault tolerance. > > WOW > > > now > > > that's a selling point. Also it can be done with out > raising > > > up the > > > costs on hardware to much. You can get duel interface NIC's > > > for your > > > servers that are fairly reasonable now. I am amazed at the > > > push for > > > processor speed now, I can think if very few people that > NEED > > > 3Ghz with > > > 2Gb of RAM. However no one NEEDS a Jaguar eigther, some > > people > > > just > > > want it and if they can afford it so be it. Look at the > > > situation this > > > way at least if your going for over kill the network will > > > perform well, > > > that is better than underselling and then having your > clients > > > be upset > > > because they are limited in the future. > > > > > > But hay that's just my 2 cents. Take it with a grain of > salt. > > > > > > = ) > > > > > > Steven Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65381&t=65263 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
