Joseph Malin wrote: > > Priscilla, > > Thanks for the correction on the 1024 vs. 1000. I had > forgotten that > bandwidth uses 1000 instead of 1024. Rerunning these numbers > with 1000 > comes up with the last packet accepted is the 1142nd. (The > worksheet is > below.) > > I believe our results are not synchronizing because of > different readings of > the problem. As I read the problem, the server with the 100 > Mbps link is > not running full out:
You read the problem correctly. I made a false assumption that the server was using all of 100 Mbps for some unknown reason. :-) Of course it's only using 80,000,000 Mbs since I said 100 byte packets at 100,000 packets per second. So now both our methods work out! Whew. The 1143rd packet is dropped. Thanks for playing! You definitely win the book. :-) I'll send you a message offline to get your mailing address. And for all of you who said it wasn't real world for the server to send 80,000,000 Mbps worth of data to the client, OK, I have another question for you: When does the switch start dropping packets if the server is sending 10.1 Mbps. JUST kidding. You don't really have to figure it out. Just trying to make a point. The switch will drop packets when there's a speed mismatch (assuming an upper layer isn't flow controlling the server.) Priscilla > > Server rate = 100,000 packets per second > Each packet = 100 bytes > > Server rate = 10,000,000 bytes per second > Server rate = 10,000,000 x 8 bits per second > Server rate = 80,000,000 bps = 80 Mbps > > Using your elegant ratio method, the 10Mbps side can now > receive at 1/8th > the speed the server side is sending out. > > At 16 packets 2 have been sent, 14 queued. > At 48 packets 6 have been sent, 42 queued. > At 96 packets 12 have been sent, 84 queued. > At 960 packets 120 have been sent, 840 queued. > and finally: > At 1142 packets 142.75 have been sent and 1000 are queued > (actually 999.25, > but I am going to assume the switch does not remove the packet > from the > buffer until it has fully been sent on the wire.) > > This would say the 1143rd packet would reach a full buffer and > be dropped. > > Let me know if I made any errors... > > Thanks, > Joe > > Corrected worksheet: > 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 1000 x 1000 bps = > 10,000,000 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,000,000 bps)) x t > 800,000 b = (70,000,000 bps) x t > t = (800,000 b) / (70,000,000 bps) > > t = 0.011428571428571428571428571428571 seconds until the > buffer is > completely full. > > bitcount = (80,000,000 bps) x t = (80,000,000 bps) x > 0.011508433379980849966855711865655 s = > 914285.71428571428571428571428571 b > > packetcount = 914285.71428571428571428571428571 b / 100 B = > 914285.71428571428571428571428571 b / 800 b = > 1142.8571428571428571428571428571 > > The 1142th packet will go through and the 1143th will be the > first to be > dropped due to a buffer overflow. > > -----Original Message----- > From: Priscilla Oppenheimer > To: [EMAIL PROTECTED] > Sent: 3/13/2003 6:54 PM > Subject: RE: is 10baseT dead? [7:65263] > > 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=65392&t=65263 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
