Thanks for getting back to us. This is an interesting quandary. I think it must have something to do with SAR. When you had the MTU set to 4470, the interface chopped up 4470 worth of bytes (from different packets), and whipped out the cells as fast as possible, causing you to burst beyond your allotted 10 Mbps. (I say "from different packets" because the protocols you mention don't normally send packets larger than 1500 bytes.)
When you have the MTU set to 1500, the interface chops up those bytes, sends them out, grabs some more bytes, chops those up and sends them out, etc. This takes more time causing you not to burst. Do you get charged extra for going over 10 Mbps? Also, does SMDS have something like Frame Relay where traffic in the burst range can get dropped more readily in the provider's network? (meaning it's a bit risky to burst) If you don't get charged extra and the risk of dropped cells isn't an issue, then maybe you don't want to change it. The second scenario (with the 1500-byte MTU) is less efficient and leaves bytes hanging around in queues longer than the first scenario. I hate making all these guesses, but my SMDS, AAL3, HSSI experience is pretty minimal. But the theory is sound! ;-) Priscilla At 09:08 AM 12/4/01, steve skinner wrote: >Hello, > > >sorry i`ve taken so long to reply.... > >the underlying technology is an SMDS network...we have bought a 10 meg pipe >that has the capacity to Burst upto 25meg..(think Frame..same sort of >thing).. > >so yes it is impossible to use 120% ...but i should have said 120% of what >we are allowed ...sorry...my bad > >it`s SMDS which is just basically AAL3 over a HSSI int to the provider ATM >backbone...so BT say`s > >about the SARing.....we were thinking about that but.... > >we are only using Ethernet apps...we have OSPF,Multicast SMDS,HTTP,Mail >netbeui,ipx(tunneld)...that`s all ... >non of this stuff should generate packets bigger than 1500... > >the only thing i have been able to come up with since then is.... > >it goes from >HUB....PTMultiP (10 sites) over HSSI multicast.... >To Spoke PTP multicast... >both of our ends are serail ....so prehaps it was losing something in the >sar`ing at both ends... > >i am really stumped as to how changes to the MAX MTU size would do >anything......i thought with this command all we were doing was allowing >a MAXIMUM TRANSMISSION SIZE....not changing the interface so every unit is >set to this size...that`s what foxes me...... > > >cheers anyway > >steve > >From: "Priscilla Oppenheimer" > >Reply-To: "Priscilla Oppenheimer" > >To: [EMAIL PROTECTED] > >Subject: Re: MTU size increase`s bandwidth ???? [7:27673] > >Date: Thu, 29 Nov 2001 13:31:04 -0500 > > > >Bandwidth is how much capacity a link has. It can't be increased without > >asking for more bandwidth from a provider or moving to a different > >technology. (Just a comment on the subject of your message.) > > > >The amount of bandwidth usable by applications could increase if you > >reduced the overhead. Overhead includes packet headers, packet ACKs, > >interframe gaps, etc. Increasing packet sizes can reduce the percentage of > >bandwidth used by those overhead functions, thus leaving more for > >application-layer data. > > > >You said that you are using 120% of bandwidth. That's not possible. > >Remember bandwidth just means capacity. You can't use more than is there. > >The offered load to the network could be more than the capacity. But the > >network itself can't carry more than its capacity. I'm wondering what is > >telling you that you are using 120%? > > > >Since you are paying for bandwidth, in one way or another, you want to use > >as much as possible, while leaving head room for bursty traffic. > > > >Those were just terminology things. > > > >On to your question: I could see bandwidth usage going down when you > >decrease the frame size. There's an interframe gap (silence) between every > >frame. That may explain it. > > > >Also perhaps you are benefiting from more efficient segmentation and > >reassembly. (I think you said you are using SMDS which is cell-based?) > >Perhaps it works more efficiently if you give it smaller chunks to work on. > > > >On the other hand, what are the applications? Most applications don't send > >large frames, although they could be configured to do so. But a typical > >TCP/IP application that grew up on Ethernet and Internet technologies > >wouldn't send packets bigger than 1500 bytes. And packets can't grow in > >size. I don't know of any technology that puts packets together just > >because the interface MTU is larger than received packets. So I'm wondering > >what the 4470 MTU you mentioned was really doing (as are you! ;-) > > > >Need more caffeine........ ;-) > > > >Priscilla > > > > > > > >At 09:30 AM 11/29/01, steve skinner wrote: > > >Chaps, > > > > > > > > >i came across this recently and was wondering if anyone had seen this > > >before.. > > > > > >we currently have 2 10meg smds(multicast)curcuits spanning the uk > > > > > >each curcuit is terminated at 2 different point`s (seperate HSSI router > > >int`s) in 2 seperate HO`s in the UK.... > > >the HO`s are linked by gig ether-fibre link across the UK. > > >OSPF is the only protocol bieng used (apart from some statics for Backup) > > > > > >after consulting the Cisco Documnetation about HSSI MTU over AAL3 we > >were > > >advised that an MTU of 4470-9120 compared to the standard of 1500 would > > >greatly increase the performance of our links.... > > > > > >the orignal network desinger set them to this > > > > > >over the last month or so ..these links have been running at 120%..(no > > >good)...so as an experiment the MTU were changed to 1500 for the HSSI > >int`s > > >and now since then the traffic has decreased to 80%...... > > > > > >anyone seen this before ...and why would the decrease in MTU size cuase > > >less bandwidth to be used ..!!!! > > > > > > > > >anyone > > > > > >TIA > > > > > >steve > > > > > >_________________________________________________________________ > > >Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > >________________________ > > > >Priscilla Oppenheimer > >http://www.priscilla.com >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=28138&t=27673 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
