Priscilla Oppenheimer wrote: > > 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
That should read 80,000,000 bps. Sorry! > 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 That should read 80,000,000 bps too. > 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=65393&t=65263 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
