Hi Jeff, Thanks a lot for taking the time to explain all this, It sounds like you have been using this platform for a while.... Do you think the 486 processor is the reason for the Netserver card's lack of performance ? The reason I ask is that, I think the pm3 only has a 486 processer onboard and I have not heard of any "quake lag" with the pm3. Also did you try setting "ppp in modem" to help reduce the load on the Netserver ? did it help ? About half of our modem server are tc with netserver cards, the other half are pm3's. It never fails that the tc's hunt group fills up with users while our pm3 hunt groups have avail lines..... any idea on what Hyper arc's are going for ????? see ya. Jeff Mcadams wrote:
Also sprach mark ross
Jeff Mcadams wrote:
I'll say ahead of time...the NETServer PRI is a bad idea. They have been end-of-lifed at 3Com (read: no support at all), and had quite a few rather significant bugs in their software code at the time they were discontinued.
Are you refering to the "NETServer PRI" or "NETServer's" in general ?
Uhm...I'm referring to NETServer cards in the TC chassis in general. Note that this doesn't necessarily cover the NETServer units which are not chassis based and are just generally inferior all the way around. To the best of my knowledge, the code base is the same for the NETServer card, and the NETServer PRI card that I believe you are asking about.
My understanding was that the only difference was that the "NETServer PRI" was able to do ISDN calls with less overhead, somthing about an enhanced packet bus and a munich daughter card...
I wouldn't say less overhead.
Uhm...this is gonna proly get into more than you really cared to know about TC chassis history. :)
Originally, the TC chassis was not capable of doing ISDN at all...it came out before ISDN really existed to any real degree. You had (this is neglecting the age of dual modem cards, of which I still have a few in service believe it or not!) a channelized T1 card, modem cards and the NETServer card to be the gateway. The modem cards were just that, modems only. When ISDN started to become prevelent, USR/3Com came out with the Courier I-modem high-end consumer equipment, which was a device that could do either ISDN, or modem protocols over an ISDN line. The decision was made that the TC chassis should have essentially the same capability. The modem cards were slated to be upgraded to handle ISDN, and essentially be I-modems, but in the meantime, a solution was needed to handle ISDN calls on the current modem card software base. The NETServer PRI was introduced. The enhanced packet bus is basically irrelevant in this, but the NETServer PRI card did have the Munich daughter card, which was essentially a co-processor card that handled termination and signaling for ISDN in the chassis. Essentially, the card handle some number of ISDN terminations in the place of the modems. Eventually, the modem card code was developed to handle ISDN as well as modem, and they became I-modems, and the Munich daughter card became redundant. For some time, while the modem card code was still working out some of its bugs, it was a good idea to switch back to using the Munich daughter card to troubleshoot problems. Eventually, since the development effort was being put into the modem card code, the modem cards became considerably more reliable and gave better performance than the Munich daughtercard for terminating ISDN, so pretty much everyone switched to using the quad cards for ISDN termination. With the switch to the HiPer Arc, they don't even have the Munich daughtercard, so it quads and DSPs for ISDN termination, or nothing.
Looking at the 3com software matrix I don't see different versions of software for the "PRI" vs "non PRI" netservers.
To the best of my knowledge, they use the same code base.
So a "HiPer Arc" can just be installed in place of the Netserver card ? Is the command line syntax for the HiPer Arc the same as Netserver ?
Yup, the Arc would take the place of the NETServer card (minus the Munich daughtercard of course ;). The syntax is radically different, but also rather better. The processor on the Arc is also rather more powerful (a PPC 603e I believe it is, compared to the NETServer's 486) The NETServer started running into performance issues (the dreaded so-called "Quake Lag") at around 30 ports of usage (note that this is less than the number of ports that you'll be dealing with), and running it in a double-play chassis (12 quads and 2 dsps) as was originally suggested when the dsps were first announced was virtually suicide for an ISPs with any significant number of gamers.
The NETServer code base was derived (very directly) from the Livingston ComOS code-base. USRobotics originally had licensed ComOS from Livingston to use in the NETServer, USR got bought by 3Com, and Livingston got bought by Lucent. 3Com never did develop the "Pilgrim" code base (the code base of what now runs on the HiPer Arc, and several other 3Com products) to run on the NETServer as they promised. Instead, the NETServer product was End-Of-Lifed with all of about 4 months notice to those of us using them.
If you'd like, I can probably dig up versions of code for the NETServer right up until the last day that 3Com has the legal rights to work with the code. I was working desperately with 3Com to find and squash a bug in the MPIP handling code of the NETServers...I was not successful in that quest. There are other outstanding bugs in the NETServer code, which, due to the lack of source code access at 3Com, and that the product is long-dead at 3Com, will never be fixed. Among these, the MPIP bug(s) I mentioned, the Quake Lag (which 3Com will claim was just a performance limitation inherent in the NETServer card...I think that's a load of hooey to this day), and probably others that I have (thankfully) forgotten.
Anyway...if you're still reading at this point, hopefully you've got some idea of why you *really* *really* want to stay away from the NETServer. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.