So, here was my thinking. Feel free to correct me if there are holes in my logic.
Notice I didn't ask about time, although the fact that you used time is fine and maybe got you a better answer. ;-) The question was after how many packets sent by the server will the switch start dropping packets? So, considering I said after how many, then actually the answer I get is 1111 packets. The 1112th packet is dropped. Here was my (possibly flawed) logic. The 10 Mbps side can send at 1/10th the speed of the 100 Mbps. Let's assume the first packet isn't queued at all and starts going out right away. The next 9 packets are queued. They can't be sent because the port is still sending the first packet at 10 Mbps, but they have arrived since the servers is sending at 100 Mbps, so they must be queued. (Hmm, I wonder if that should be 10 packets queued actually....) At 20 packets 2 have been sent, 18 queued. At 50 packets 5 have been sent, 45 queued. At 100 packets 10 have been sent, 90 queued. At 1000 packets (buffer size), 100 have been sent, 900 queued. We're still OK. At 1100 packets, 110 have been sent, 990 have been queued. At 1110 packets, 111 have been sent, 999 queued. We're getting close! At 1111 packets, 111.1111 have been sent, 1000 queued. The 1112th packet is dropped. Priscilla Priscilla Oppenheimer wrote: > > You win! However, I got the 1112 packet. :-) > > When you said the clientmax = 10 Mbps = 10 x 1024 Kbps = 10 x > 1024 x 1024 bps = 10,485,760 bps, you shouldn't have multiplied > by 1024. Bandwidth is just in 10s, not powers of 2s. > > Do you get 1112 if you take that into account?? > > Thanks, > > Priscilla > > Joseph Malin wrote: > > > > 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=65384&t=65263 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
