Well here is an illustration from a users e-mail to me: "Ken, been connecting very nicely lately with that new number. I've been connecting at 38.8 and 40.0! :-) Problem is when I play Quake I get the "phone jack" quite often, much more often than when I use the other number. I can browse the net and download files much better, but it is pretty useless with Quake. What do you reckon the problem could be?" Now for some of the pertinant details: This customer has a USR 3Com modem. He used to dial into our TC gear ("other number"). He is now dialing into our Max TNT ("new number"). The best he ever got with TC was 28.8K. Infer from this what you will. I have details such as our HDM/ARC revisons as well as his FLASH/DSP dates/revisions if anyone cares. I am working with other cases (The v.90 X-files) who have similar experiences and will let you know if there's a pattern. Tedious work, no wonder no one else has done it. :-P ----- .~. Ken Kirchner /V\ L I N U X Asst SysAdmin // \ > Don't fear the penguin < ShreveNet, Inc. /( )\ ^^-^^ - 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.
Yes have seen it ourselves over and over. BTW, reason he is having the problem with Quake probably has to do with MTU settings on the Ascend... or he has incorrect error control and thus his packets are resending. (correct me someone if I am incorrect) Ed ----- Original Message ----- From: Ken Kirchner <kenk@shreve.net> To: <usr-tc@lists.xmission.com> Sent: Monday, October 18, 1999 1:34 AM Subject: (usr-tc) Ascend vs. 3Com Well here is an illustration from a users e-mail to me: "Ken, been connecting very nicely lately with that new number. I've been connecting at 38.8 and 40.0! :-) Problem is when I play Quake I get the "phone jack" quite often, much more often than when I use the other number. I can browse the net and download files much better, but it is pretty useless with Quake. What do you reckon the problem could be?" Now for some of the pertinant details: This customer has a USR 3Com modem. He used to dial into our TC gear ("other number"). He is now dialing into our Max TNT ("new number"). The best he ever got with TC was 28.8K. Infer from this what you will. I have details such as our HDM/ARC revisons as well as his FLASH/DSP dates/revisions if anyone cares. I am working with other cases (The v.90 X-files) who have similar experiences and will let you know if there's a pattern. Tedious work, no wonder no one else has done it. :-P ----- .~. Ken Kirchner /V\ L I N U X Asst SysAdmin // \ > Don't fear the penguin < ShreveNet, Inc. /( )\ ^^-^^ - 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.
On Mon, 18 Oct 1999, Ed wrote:
Yes have seen it ourselves over and over.
BTW, reason he is having the problem with Quake probably has to do with MTU settings on the Ascend... or he has incorrect error control and thus his packets are resending. (correct me someone if I am incorrect)
I would expect the default MTU on the ascend to be the same as the 3com.........I would also expect error control to be autonegotiated correctly by either NAS.
Ed
----- Original Message ----- From: Ken Kirchner <kenk@shreve.net> To: <usr-tc@lists.xmission.com> Sent: Monday, October 18, 1999 1:34 AM Subject: (usr-tc) Ascend vs. 3Com
Well here is an illustration from a users e-mail to me:
"Ken, been connecting very nicely lately with that new number. I've been connecting at 38.8 and 40.0! :-) Problem is when I play Quake I get the "phone jack" quite often, much more often than when I use the other number. I can browse the net and download files much better, but it is pretty useless with Quake. What do you reckon the problem could be?"
Now for some of the pertinant details:
This customer has a USR 3Com modem. He used to dial into our TC gear ("other number"). He is now dialing into our Max TNT ("new number"). The best he ever got with TC was 28.8K.
Infer from this what you will. I have details such as our HDM/ARC revisons as well as his FLASH/DSP dates/revisions if anyone cares. I am working with other cases (The v.90 X-files) who have similar experiences and will let you know if there's a pattern. Tedious work, no wonder no one else has done it. :-P
----- .~. Ken Kirchner /V\ L I N U X Asst SysAdmin // \ > Don't fear the penguin < ShreveNet, Inc. /( )\ ^^-^^
- 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.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - 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.
Thus spake Brian
On Mon, 18 Oct 1999, Ed wrote:
Yes have seen it ourselves over and over.
BTW, reason he is having the problem with Quake probably has to do with MTU settings on the Ascend... or he has incorrect error control and thus his packets are resending. (correct me someone if I am incorrect)
I would expect the default MTU on the ascend to be the same as the 3com.........I would also expect error control to be autonegotiated correctly by either NAS.
And the MTU shouldn't matter for Quake and the like. Quake and the like tends to use very small packets, packets where the MTU on the link isn't relevant. -- 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.
Jeff McAdams wrote: "And the MTU shouldn't matter for Quake and the like. Quake and the like tends to use very small packets, packets where the MTU on the link isn't relevant." Not necessarily... if the packets are always larger then Quake would lag and time out. Have the client manually set their MTU down to 576 and see what the result is. I may be wrong but I have seen stranger things cause problems on games such as Quake. I know when USR had an issue with Quake that was one solution... we were deeply involved in it. However until a code revision it wasn't completely resolved. Think about it though... USR even cared about Quake and made an issue of it and resolved it. 3com would laugh about an issue with gaming. That shows how even the little things were important to USR. We were PROUD to be a USR ISP! Used to rip all the other ISP's that used other access servers... now we feel like they are ripping on us ;-( Ed ----- Original Message ----- From: Jeff Mcadams <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Monday, October 18, 1999 5:15 PM Subject: Re: (usr-tc) Ascend vs. 3Com Thus spake Brian
On Mon, 18 Oct 1999, Ed wrote:
Yes have seen it ourselves over and over.
BTW, reason he is having the problem with Quake probably has to do with MTU settings on the Ascend... or he has incorrect error control and thus his packets are resending. (correct me someone if I am incorrect)
I would expect the default MTU on the ascend to be the same as the 3com.........I would also expect error control to be autonegotiated correctly by either NAS.
And the MTU shouldn't matter for Quake and the like. Quake and the like tends to use very small packets, packets where the MTU on the link isn't relevant. -- 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.
On Mon, 18 Oct 1999, Ed wrote:
Not necessarily... if the packets are always larger then Quake would lag and time out. Have the client manually set their MTU down to 576 and see what the result is. I may be wrong but I have seen stranger things cause problems on games such as Quake.
Tell the quake (I'm assuming actually quake2 here) player to type 'netgraph 1' at his console when he's on his favorite gameserver and compare it between the two chassis. Specifically, compare the sizes of the green bars (latency), and the number of red bars (dropped packets). - 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.
Thus spake Ed
Jeff McAdams wrote: "And the MTU shouldn't matter for Quake and the like. Quake and the like tends to use very small packets, packets where the MTU on the link isn't relevant."
Not necessarily... if the packets are always larger then Quake would lag and time out. Have the client manually set their MTU down to 576 and see what the result is. I may be wrong but I have seen stranger things cause problems on games such as Quake.
Well...if there's other stuff on the link (someone doing an ftp transfer) sure, cranking down the MTU will help (I suspect this falls into the too little, too late department though). But if you're only running Quake on the link, I doubt dropping the MTU to 576 is going to help any...I've never seen Quake send any packets of that size or larger, so the MTU is totally irrelevant in that situation.
I know when USR had an issue with Quake that was one solution... we were deeply involved in it.
I never saw any change in performance in Quake by changing the MTU...we tried it when people were suggesting it, but didn't do anything here. Like I said, if it was Quake traffic mixed in with other stuff, dropping the MTU helped, but the performance would generally be so sucky in that situation that nothing would make game play satisfactory...dropping the MTU only made it to be not quite so terribly painful. :)
However until a code revision it wasn't completely resolved. Think about it though... USR even cared about Quake and made an issue of it and resolved it. 3com would laugh about an issue with gaming. That shows how even the little things were important to USR.
Actually, on the NETServers, "Quake Lag" was *never* resolved fully. It got better, but it was never to the point that I would consider acceptable.
We were PROUD to be a USR ISP! Used to rip all the other ISP's that used other access servers... now we feel like they are ripping on us ;-(
Agreed there. -- 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.
During LCP, the MRRU is negotiated from both ends. Latest Code of hiper arc does have capability of negotiating the standard value of 1500. On Mon, 18 Oct 1999, Ed wrote:
Jeff McAdams wrote: "And the MTU shouldn't matter for Quake and the like. Quake and the like tends to use very small packets, packets where the MTU on the link isn't relevant."
Not necessarily... if the packets are always larger then Quake would lag and time out. Have the client manually set their MTU down to 576 and see what the result is. I may be wrong but I have seen stranger things cause problems on games such as Quake.
I know when USR had an issue with Quake that was one solution... we were deeply involved in it. However until a code revision it wasn't completely resolved. Think about it though... USR even cared about Quake and made an issue of it and resolved it. 3com would laugh about an issue with gaming. That shows how even the little things were important to USR.
We were PROUD to be a USR ISP! Used to rip all the other ISP's that used other access servers... now we feel like they are ripping on us ;-(
Ed
----- Original Message ----- From: Jeff Mcadams <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Monday, October 18, 1999 5:15 PM Subject: Re: (usr-tc) Ascend vs. 3Com
Thus spake Brian
On Mon, 18 Oct 1999, Ed wrote:
Yes have seen it ourselves over and over.
BTW, reason he is having the problem with Quake probably has to do with MTU settings on the Ascend... or he has incorrect error control and thus his packets are resending. (correct me someone if I am incorrect)
I would expect the default MTU on the ascend to be the same as the 3com.........I would also expect error control to be autonegotiated correctly by either NAS.
And the MTU shouldn't matter for Quake and the like. Quake and the like tends to use very small packets, packets where the MTU on the link isn't relevant. -- 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.
- 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.
I'm trying to get my Netserver to connect to our ISP's Portmaster without success. It seems to connect & stay connected, problem is, it does not allow me to ping the portmaster or IP addresses on Portmaster side of the connection. We're running V4.0.13 ( I know about 4.0.2, but we thought we ought to get this working first) Our connection to our ISP works fine with a Netgear RT328, but I'd like to eliminate the separate router. I execute following to configure the Netserver: add modem_group 78 INTERFACES mod:7,mod:8 add user BN password isppassword type network,dial_out enable no set system transmit_authentication_name ME set ppp receive_authentication pap set network user BN send_pass isppassword set user BN modem_group 78 phone_number 5551212 set network user BN ppp compression_algorithm ASCEND set network user BN address_selection SPECIFIED remote_ip_address 209.74.143.3 set dial_out user BN site type continuous set network user BN ip_routing none header_compression tcp/ip add framed USER BN IP_ROUTE 209.74.143.0/C GATEWAY 209.74.143.3 METRIC 5 ENABLE USER BN ADD IP default gateway 209.74.143.3 metric 1 save all Other pertainent information: USRobotics Total Control MP I-modem with ISDN/V.34 ISDN Switch Settings... Switch Protocol *W 2 US National ISDN-1 Multipoint *M 1 Multi-point Dialing Mode *O 1 Overlap Sending mode SPID *S1 31421535730101 <-SPID1 *S2 31421535740101 SPID2 Directory No. *P1 2153573 <-DN1 *P2 2153574 DN2 TEI *T1 00 Automatic TEI *T2 00 Automatic TEI Physical Interface: Inactive Data Link Layer : Inactive OK USRobotics Total Control MP I-modem with ISDN/V.34 Settings... B0 C1 E1 F1 Q0 V1 X1 BAUD=115200 PARITY=N WORDLEN=8 DIAL=TONE ON HOOK TIMER <enter> for more... Q to quit... &A1 &B0 &C1 &D2 &G0 &H0 &I0 &K1 &M4 &N0 &P0 &R1 &S0 &T5 &U0 &X0 &Y1 %N6 *V=5 #CID=0 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=018 S11=070 S12=050 S13=000 S14=001 S15=000 S16=000 S17=000 S18=000 S19=000 S20=000 S21=010 S22=017 S23=019 S24=150 S25=005 S26=001 S27=000 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=000 S40=000 S41=000 S42=126 S43=200 S44=015 S45=000 S46=255 S47=000 S48=000 S49=016 S50=100 S51=064 S52=005 S53=000 S54=064 S55=000 S56=000 S57=000 S58=000 S59=000 S60=000 S61=000 S62=000 S63=000 S64=000 S65=000 S66=000 S67=064 S68=008 S69=000 S70=012 USRobotics Total Control MP I-modem with ISDN/V.34 Configuration Profile... Product type US/Canada External Options HST,V32bis,Terbo,V.FC,V34+,x2,V.90 Fax Options Class 1/Class 2.0 Clock Freq 20.16Mhz Eprom 768k Ram 256k Supervisor date 03/02/99 DSP date 04/02/98 Supervisor rev 2.3.7 DSP rev 2.1.0 - 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.
participants (7)
-
Ahmed Saeed -
Brian -
Ed -
Jeff Mcadams -
John Schmerold -
Ken Kirchner -
Lon R. Stockton, Jr.