reply to lovswr
Re: Good step
said by lovswr:Nit pick the nit pick I thought an OC-3 running STM-1 operated at 155 M/bs with 150 M/bs due to payload overhead? I'll have to dig out a manual for that one I guess.
Let me pick a nit. The SPE (SONET Payload envelope) in an Oc-3/STM-1 is 140M. There is 15M of overhead that the system uses for its own operation. Such things as the stuffing events, the payload pointer (which tells the system where YOUR 140M of data starts within each frame, & even a orderwire channel that is big enough for analog broadcast video.
So yes the line or wire speed is clocked at a little over one hundred & fifty million times per second, the actual throughput or amount of customer data is not quite that high.
The fiber networking protocol you refer to though is *usually* protocol neutral. It's job is just through the packets out (over-simplifying of course given routes, etc.) as fast as it can. Being that an atomic clock keeps the network in sync, it kind of sits high up on the hardware chart for me. I've never really seen one of those taken down by overload, but I know it does happen. As much as I would love to talk about overhead, payload, and pointers; that might cause a real eye-glazing effect at this news forum.
Basically, my only spill is that (and you probably know as well), that some of the problems we hear about with an ISP overload does have a solution that doesn't involve punishing one user for being a bandwidth hog or deciding that everyone should just be capped to XYZ gigabytes of bandwidth.
I know that no system is invincible to load. I could get about 30 clients doing about 30,000 connections each to max out the ISP setup due to the gateway/router devices having only a few gigs of RAM for state tables if I really wanted to push it to destruction.
Fight Insight Ready (Was NebuAD) and the like:
Click Here to pollute their data