Subject: (usr-tc) Ascend vs. 3Com

From: Ken Kirchner <[email-masked]>
Date: Mon, 18 Oct 1999 07:39:04 +0000

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 "[email-masked]"
 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.

---

From: Ed <[email-masked]>
Date: Mon, 18 Oct 1999 07:56:51 +0000

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 <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 18, 1999 1:34 AM
Subject: (usr-tc) Ascend vs. 3Com

-----
                        .~.

-

-

---

From: John Schmerold <[email-masked]>
Date: Mon, 18 Oct 1999 17:42:55 +0000

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

-

---

From: Brian <[email-masked]>
Date: Mon, 18 Oct 1999 23:12:10 +0000

> 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.

>  "help" to the same address.  Do not use quotes in your message.

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 18 Oct 1999 23:18:29 +0000

Thus spake Brian
 
>> 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)

>3com.........I would also expect error control to be autonegotiated

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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Ed <[email-masked]>
Date: Tue, 19 Oct 1999 03:35:02 +0000

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 <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 18, 1999 5:15 PM
Subject: Re: (usr-tc) Ascend vs. 3Com

Thus spake Brian

-

-

---

From: "Lon R. Stockton, Jr." <[email-masked]>
Date: Tue, 19 Oct 1999 06:21:40 +0000

> the result is. I may be wrong but I have seen stranger things cause problems

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).

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 19 Oct 1999 15:31:07 +0000

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.

-

---

From: Ahmed Saeed <[email-masked]>
Date: Mon, 25 Oct 1999 22:38:00 +0000

During LCP, the MRRU is negotiated from both ends. Latest Code of hiper 
arc does have capability of negotiating the standard value of 1500. 

-