barefoot@hobbes.ncsu.edu (Heath Roberts) (01/19/91)
In article <16080@accuvax.nwu.edu> wmartin@stl-06sima.army.mil (Will Martin) writes: >What would happen if everyone (in the US, in North America, on the >planet -- pick your favorite range) picked up the phone at the same >instant and tried to make a *local* call? (Yes, anyone who got Depends on the type of switch. Some would handle this gracefully, others can't. DMS (NT) switches limit dial tone, so the switch can complete the calls it provides dial tone for. First come, first serve kind of thing. I'm not sure what would happen if the wait stack filled up. Presumably it would issue a SWERR (software error) and the call would die. Use up a lot of printer paper.... If the switch _did_ crash, it would take about four minutes to reload its software, and things would be hunky-dory unless everyone was still waiting for dial tone. In a worst case situation, current draw might be great enough to draw down batteries, and if all those phones stayed off hook, either the line modules would shut them down (auto recover when the line goes back on hook) or telco employees might start powering down line frames. I don't think ATT switches handle bounds conditions this well. It'd probably die, and they take longer to come back up. (I haven't worked directly with them, but I understand it is on the order of half an hour.) Heath Roberts NCSU Computer and Technologies Theme Program barefoot@catt.ncsu.edu
KLUB@maristb.bitnet (Richard Budd) (01/19/91)
Will Martin writes in TELECOM Digest V11 #40: >What would happen if everyone (in the US, in North America, on the >planet -- pick your favorite range) picked up the phone at the same >instant and tried to make a *local* call? >Pick a time, say 12 noon Eastern on 30 Jan, and everyone in the US, >across all the time zones, picks up their phones at that same moment. What do you think happens every second Sunday in May?! :+} Richard Budd | E-Mail: IBMers - rcbudd@rhqvm19.ibm VM Systems Programmer | All Others - klub@maristb.bitnet IBM - Sterling Forest | Phone : (914) 578-3746 | All Disclaimers Apply P.S. to PAT: Thanks or mentioning my situation. IBMers from all over the country showed me the way to receive TELECOM Digest on the IBM system. I now receive it through IBM (as well as through Marist for postings) and once again have put my foot into it (and it certainly won't be the last time!):+} [Moderator's Note: You are quite welcome! There are numerous telecom-related newsgroups and mailing lists around the world which redistribute the Digest. IBM is just one example. PAT]
floyd@ims.alaska.edu (Floyd Davidson) (01/19/91)
In article <16164@accuvax.nwu.edu> Heath Roberts <barefoot@hobbes. ncsu.edu> writes: >In article <16080@accuvax.nwu.edu> wmartin@stl-06sima.army.mil (Will >Martin) writes: >>What would happen if everyone (in the US, in North America, on the >>planet -- pick your favorite range) picked up the phone at the same >>instant and tried to make a *local* call? (Yes, anyone who got >Depends on the type of switch. Some would handle this gracefully, >others can't. DMS (NT) switches limit dial tone, so the switch can >complete the calls it provides dial tone for. First come, first serve >kind of thing. I'm not sure what would happen if the wait stack >filled up. Presumably it would issue a SWERR (software error) and the >call would die. Use up a lot of printer paper.... Each resource needed to complete a call (dialtone, tone receivers, call data blocks, etc.) has a que. I don't remember exactly what happens on an overflow (I think it just drops the call to an intercept), but ... the que is not a first come first serve! It is a last come first serve. The theory being that the call most likely to be able to complete is the last one taken in. SWER logs are not generated by dropped calls or que overflows. Operational Measurement counts are pegged though. SWER logs are created when the software finds itself in a state where it does not know what is supposed to happen next. (If you are actually printing every SWERR generated you are wasting paper! Half the time it takes going all the way back to BNR to figure out what causes them.) The real secret with DMS log reports is knowing which ones to NOT print out. For everyone who wonders what we are talking about, the DMS switches can empty a box of paper printing logs on more things than you can imagine and do it in almost the blink of an eye. The first jokes I ever heard about digital switches all had to do with how much stock we should buy in Weyerhouser and Moore Business Supply. >If the switch _did_ crash, it would take about four minutes to reload >its software, and things would be hunky-dory unless everyone was still DMS switches have various levels of "crash": Warm, cold, or reload restarts. The only time software is actuaally reloaded is a reload restart, and that is going to take a lot longer than four minutes (at least on an NT-40 front end, I don't know about Super-Node's). Warm or cold restarts may take a very short time and may not even drop calls (but none can be set up during that time either). >waiting for dial tone. In a worst case situation, current draw might >be great enough to draw down batteries, and if all those phones stayed >off hook, either the line modules would shut them down (auto recover >when the line goes back on hook) or telco employees might start >powering down line frames. I don't work on a line switcher, but that does not sound realistic. What I have seen is about 50% of all the trunks in a toll switch go offhook all at once. Last week a company whose name I won't mention did a minor adjustment of Alascom's satellite, and shot it right out of the box for 42 minutes. I bet that cost $200 just for the paper to print the logs on. But nothing crashed. >I don't think ATT switches handle bounds conditions this well. It'd >probably die, and they take longer to come back up. (I haven't worked >directly with them, but I understand it is on the order of half an >hour.) Well, could be, I don't know. But I did hear one good story about NTI doing a major software upgrade on what was at the time one of the largest DMS switches in operation: the line was "The Peripheral Modules will take less than one hour to reload this time, because we fixed that problem." If I remember right it took better than FIVE hours. Floyd L. Davidson | floyd@ims.alaska.edu | Alascom, Inc. pays me Salcha, AK 99714 | Univ. of Alaska | but not for opinions.