Slow transmit / upload

Using a 56k dial-up modem to ISP.
Dual boot between Fedore Core 1 ( updated kernels, etc ... using up2date
) and NT4 SP6a.

From within NT, when I upload to an FTP server via ncftp in cygwin, it
shows about 3.0K/sec.

From within linux, when I upload to the same FTP server via ncftp, it
shows about ~500B/sec.

The symptoms happen only when transmitting "large" packets ... so is not
limited to FTP but also scp, etc ... and also happens when FTP'ing to
other servers.

Using ethereal, it appears that the ACKs from the FTP server for the
large transmitted packets is arriving late, with each ACK arriving what
appears like a constant of 3 seconds after the previous one.

What could be the problem ?
Note again that the problem does not happen from within NT SP6.
I could not capture packets on winnt because winpcap does not work with
PPP. Would have been great though so that I would have seen the difference.

noone <(E-Mail Removed)> wrote:

> Using a 56k dial-up modem to ISP.

What brand and name? At least some USR Sportster models need to be
initialized by AT&F1.

> Dual boot between Fedore Core 1 ( updated kernels, etc ... using up2date
> ) and NT4 SP6a.

> From within NT, when I upload to an FTP server via ncftp in cygwin, it
> shows about 3.0K/sec.

> From within linux, when I upload to the same FTP server via ncftp, it
> shows about ~500B/sec.

> The symptoms happen only when transmitting "large" packets ... so is not
> limited to FTP but also scp, etc ... and also happens when FTP'ing to
> other servers.

> Using ethereal, it appears that the ACKs from the FTP server for the
> large transmitted packets is arriving late, with each ACK arriving what
> appears like a constant of 3 seconds after the previous one.

> What could be the problem ?

A broken ISP PPP implementation or data corruption might cause
the problem. At this point my guess is that it's a broken ISP
implementation.

You might try adding the pppd option "asyncmap a0000" and, if not
already present, the option crtscts. The first can compensate for
a PPP implementation broken with respect to ACCM and the second,
in some cases, for data corruption (it is almost always required).

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Better is the enemy of good enough. */

Clifford Kite wrote:
> noone <(E-Mail Removed)> wrote:
>
>
>>Using a 56k dial-up modem to ISP.
>
>
> What brand and name? At least some USR Sportster models need to be
> initialized by AT&F1.

Netcomm RoadsterII 56KUltra ( AM 5690 ).

I also spent this afternoon doing the following:

1) From winnt, told it to record the AT commands the driver was using.
Copied those commands, so that wvdial uses the exact same AT commands.
No luck with that one.

2) Tried disabling all pppd compression ( VJ, deflate, bsdcomp ). No luck.

3) Also tried adding the pppd option "default-mru". No luck.

4) Even added the pppd option "record <filename>", and viewed the file
using ethereal ... and it really does not show ACKs from the remote site
for those large packets.


>
> A broken ISP PPP implementation or data corruption might cause
> the problem. At this point my guess is that it's a broken ISP
> implementation.

If it is a broken ISP implementation, why dont I have the same problem
on winnt ?

I'll try anyway.

>
> You might try adding the pppd option "asyncmap a0000" and, if not

The pppd process shows it is using "asyncmap 00000000". What's the
difference here with a0000 ?


> already present, the option crtscts.

The pppd process shows that crtscts is added as an option

The first can compensate for
> a PPP implementation broken with respect to ACCM and the second,
> in some cases, for data corruption (it is almost always required).
>

noone wrote:
> Clifford Kite wrote:
>>
>> You might try adding the pppd option "asyncmap a0000" and, if not
>
> The pppd process shows it is using "asyncmap 00000000". What's the
> difference here with a0000 ?
>

Just tried now .. still the same problem.

However, looking at the debug log of pppd, I am not sure if asyncmap
a0000 is actually used:

Apr 12 00:55:35 localhost wvdial[8539]: Waiting for carrier.
Apr 12 00:56:00 localhost wvdial[8539]: CARRIER 4800
Apr 12 00:56:00 localhost wvdial[8539]: PROTOCOL: LAP-M
Apr 12 00:56:00 localhost wvdial[8539]: COMPRESSION: V.42BIS
Apr 12 00:56:00 localhost wvdial[8539]: CONNECT 50000/ARQ
Apr 12 00:56:00 localhost wvdial[8539]: Carrier detected. Chatmode
finished.
Apr 12 00:56:00 localhost pppd[8524]: Serial connection established.
Apr 12 00:56:00 localhost pppd[8524]: using channel 12
Apr 12 00:56:00 localhost pppd[8524]: Using interface ppp0
Apr 12 00:56:00 localhost pppd[8524]: Connect: ppp0 <--> /dev/ttyS0
Apr 12 00:56:01 localhost pppd[8524]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0xea746386> <pcomp> <accomp>]
Apr 12 00:56:01 localhost pppd[8524]: rcvd [LCP ConfReq id=0x1 < 00 04
00 00> <mru 1524> <asyncmap 0x0> <auth pap> <pcomp> <accomp> <mrru 1524>
<endpoint [MAC:00:c0:7b:8b:60:77]>]
Apr 12 00:56:01 localhost pppd[8524]: sent [LCP ConfRej id=0x1 < 00 04
00 00> <mrru 1524>]
Apr 12 00:56:01 localhost pppd[8524]: rcvd [LCP ConfAck id=0x1 <asyncmap
0xa0000> <magic 0xea746386> <pcomp> <accomp>]
......

From here, it looks like asyncmap a0000 was accepted


Apr 12 00:56:01 localhost pppd[8524]: rcvd [LCP ConfReq id=0x2 <mru
1524> <asyncmap 0x0> <auth pap> <pcomp> <accomp> <endpoint
[MAC:00:c0:7b:8b:60:77]>]
Apr 12 00:56:01 localhost pppd[8524]: sent [LCP ConfAck id=0x2 <mru
1524> <asyncmap 0x0> <auth pap> <pcomp> <accomp> <endpoint
[MAC:00:c0:7b:8b:60:77]>]
......

But this shows another asyncmap negotiation ... back to 0x00 ???
Am I reading that right ?


Apr 12 00:56:01 localhost pppd[8524]: sent [PAP AuthReq id=0x1
user="jmsalvo" password=<hidden>]
......



John

noone <(E-Mail Removed)> wrote:
> Clifford Kite wrote:
>> noone <(E-Mail Removed)> wrote:
>>
>> A broken ISP PPP implementation or data corruption might cause
>> the problem. At this point my guess is that it's a broken ISP
>> implementation.

> If it is a broken ISP implementation, why dont I have the same problem
> on winnt ?

NT would probably use asyncmap a0000 by default. Since adding it to
pppd didn't help, the asyncmap is not the problem anyway.

> I'll try anyway.

>>
>> You might try adding the pppd option "asyncmap a0000" and, if not

> The pppd process shows it is using "asyncmap 00000000". What's the
> difference here with a0000 ?

Using asyncmap a0000 causes software flow-control start and stop
characters in the data being sent to be escaped, asyncmap 0 causes
the data to be sent with no character escaped.

>> already present, the option crtscts.

> The pppd process shows that crtscts is added as an option

> The first can compensate for
>> a PPP implementation broken with respect to ACCM and the second,
>> in some cases, for data corruption (it is almost always required).

I thought about the problem after sending my reply and decided that
it really wasn't likely that either of my guesses was correct.

Truthfully I don't know the cause, although I think I've seen the
problem in other posts before. I've half a notion that it is a
protocols configuration thing, especially since you didn't mention
that retransmission occurred often - as it would seem reasonable to do.
And I have only a superficial understanding of TCP/IP.

You might check to see if selective ack is turn on with

cat /proc/sys/net/ipv4/tcp_sack

which should be 1. And check the PPP MTU, it should be 1500 not any
smaller. These are WAGs.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */

noone <(E-Mail Removed)> wrote:
> noone wrote:
>> Clifford Kite wrote:
>>>
>>> You might try adding the pppd option "asyncmap a0000" and, if not
>>
>> The pppd process shows it is using "asyncmap 00000000". What's the
>> difference here with a0000 ?
>>

> Just tried now .. still the same problem.

> However, looking at the debug log of pppd, I am not sure if asyncmap
> a0000 is actually used:

It's used by pppd, but not by the peer. It can be, and is here, different
for each direction.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */

Finally found the solution!
After several days, the solution was a combination of the following:

1) Use the same AT commands that are issued from windows
2) Set the MTU below 1500 ( e.g.: 1476 )


Doing [1] alone by itself does not alleviate the problem.

Here are the AT commands used within winnt for Netcomm RoadsterII 56
Ultra ( AM5690 ), added in /etc/wvdial.conf:

Init1 = ATE1V1Q0
Init2 = AT&FE0&C1&D2W2S95=47-K0S0=0
Init3 = ATS7=60S30=0L1M0\N3%C3&K3B0N1X4


.... and then in
/etc/sysconfig/network-scripts/ifcfg-NetcommRoadsterII56KUltra, I have
the following:

PPPOPTIONS='mtu 1476'


Now the ACKs does not arrive 3 seconds from each other.
They now arrive 0.3 seconds from each other, like this:

(1) FTP-DATA client-> server Time N
(2) FTP-DATA client-> server Time N + 0.000100 seconds
(3) TCP ACK of (1) server-> client Time N + 0.7 seconds
(4) FTP-DATA client-> server Time N + 0.7000100 seconds
(5) FTP-DATA client-> server Time N + 0.7000200 seconds
(6) TCP ACK of (2) server-> client Time N + 1.0 seconds
....

(end-4n) Last FTP-DATA client-> server Time Y - 1.2 seconds
(end-3n) TCP ACK of (2) server-> client Time Y - 0.9 seconds
(end-2n) TCP ACK of (2) server-> client Time Y - 0.6 seconds
(end-n) TCP ACK of (2) server-> client Time Y - 0.3 seconds
....
(end) TCP ACK of (end-4n) server-> client Time Y seconds


So instead of a 3 second delay, it is now only a 0.3 second delay.
It is still a mystery though, why the ACKs still arrive late, because
what happens in the end, some of the FTP-DATA are retransmitted because
of late ACKs.


In any case, the transmit rate is now the same as in nt ( ~ 3.0 - 3.5
Kbps ).

noone wrote:
> Finally found the solution!
> After several days, the solution was a combination of the following:
>
> 1) Use the same AT commands that are issued from windows
> 2) Set the MTU below 1500 ( e.g.: 1476 )
>
>
> Doing [1] alone by itself does not alleviate the problem.
>

That should have said:
Doing [1] or [2] alone by itself does not alleviate the problem.

noone <(E-Mail Removed)> wrote:
> noone wrote:
>> Finally found the solution!
>> After several days, the solution was a combination of the following:
>>
>> 1) Use the same AT commands that are issued from windows
>> 2) Set the MTU below 1500 ( e.g.: 1476 )
>>
>>
>> Doing [1] alone by itself does not alleviate the problem.
>>

> That should have said:
> Doing [1] or [2] alone by itself does not alleviate the problem.

So their were two mutually exclusive things causing the problem.
It seems doubtful that either could have been associated with the 3
second ACK delay unless duplicate segments were being being received
and reported.

The modem initialization problem is not a surprise, although there
was one setting I couldn't identify, the -K0. Otherwise the only
unusual one was B0 which causes the modem to use CCITT V.22/.21 as the
initial negotiation protocol. CCITT is apparently used in Japan while
Bell 212A/103 seems to be the U.S. standard. Curious, the N1 setting
should allow any speed, only use CCITT, and cause Bx to be ignored.

All this according to the old Hayes standard, which isn't adhered to
by many modem manufacturers now.

I flat don't understand why lowering the MTU to 1472 was necessary.
But if there were pppd negotiation traces available they would likely
have shown that the peer requested it (and so a provide a clue that it
should be tried with pppd).

Thanks for posting the answer! Hopefully I'll remember it should
there be another post with the same problem.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */

Clifford Kite wrote:
> noone <(E-Mail Removed)> wrote:
>
>>noone wrote:
>>
>>>Finally found the solution!
>>>After several days, the solution was a combination of the following:
>>>
>>>1) Use the same AT commands that are issued from windows
>>>2) Set the MTU below 1500 ( e.g.: 1476 )
>>>
>>>
>>>Doing [1] alone by itself does not alleviate the problem.
>>>
>
>
>>That should have said:
>> Doing [1] or [2] alone by itself does not alleviate the problem.
>
>
> So their were two mutually exclusive things causing the problem.
> It seems doubtful that either could have been associated with the 3
> second ACK delay unless duplicate segments were being being received
> and reported.
>
> The modem initialization problem is not a surprise, although there
> was one setting I couldn't identify, the -K0.

I figured that -KO means "Disable V.42 to MNP10 conversion"

Otherwise the only
> unusual one was B0 which causes the modem to use CCITT V.22/.21 as the
> initial negotiation protocol. CCITT is apparently used in Japan while
> Bell 212A/103 seems to be the U.S. standard. Curious, the N1 setting
> should allow any speed, only use CCITT, and cause Bx to be ignored.
>
> All this according to the old Hayes standard, which isn't adhered to
> by many modem manufacturers now.
>
> I flat don't understand why lowering the MTU to 1472 was necessary.
> But if there were pppd negotiation traces available they would likely
> have shown that the peer requested it (and so a provide a clue that it
> should be tried with pppd).

Someone else suggested that it maybe a hardware problem ( e.g.: the
cables are not wired correctly so that the hardware flow control is not
really working ), thus causing the 3 second ACK delay because of buffer
overrun when transmitting large packets.

Here's a complete log of wvdial ( without any setting on Stupid Mode,
and so is disabled, allowing wvdial to do the authentication instead of
pppd ) and pppd. Note that my ISP actually says that the MTU is 1524.

( I xxxxx'd my username )

Apr 15 20:39:43 localhost pppd[7668]: pppd 2.4.2 started by root, uid 0
Apr 15 20:39:45 localhost wvdial[7683]: WvDial: Internet dialer version 1.53
Apr 15 20:39:45 localhost wvdial[7683]: Initializing modem.
Apr 15 20:39:45 localhost wvdial[7683]: Sending: ATE1V1Q0
Apr 15 20:39:45 localhost wvdial[7683]: OK
Apr 15 20:39:45 localhost wvdial[7683]: Sending: AT&FE0&C1&D2W2S95=47-K0S0=0
Apr 15 20:39:45 localhost wvdial[7683]: AT&FE0&C1&D2W2S95=47-K0S0=0
Apr 15 20:39:45 localhost wvdial[7683]: OK
Apr 15 20:39:45 localhost wvdial[7683]: Sending:
ATS7=60S30=0L1M0\N3%C3&K3B0N1X4
Apr 15 20:39:45 localhost wvdial[7683]: OK
Apr 15 20:39:45 localhost wvdial[7683]: Modem initialized.
Apr 15 20:39:45 localhost wvdial[7683]: Sending: ATDT82183400
Apr 15 20:39:45 localhost wvdial[7683]: Waiting for carrier.
Apr 15 20:40:12 localhost wvdial[7683]: CARRIER 50667
Apr 15 20:40:13 localhost wvdial[7683]: PROTOCOL: LAP-M
Apr 15 20:40:13 localhost wvdial[7683]: COMPRESSION: V.42BIS
Apr 15 20:40:13 localhost wvdial[7683]: CONNECT 50667/ARQ
Apr 15 20:40:13 localhost wvdial[7683]: Carrier detected. Waiting for
prompt.
Apr 15 20:40:13 localhost wvdial[7683]: apx1.syd
Apr 15 20:40:13 localhost wvdial[7683]: login:
Apr 15 20:40:13 localhost wvdial[7683]: Looks like a login prompt.
Apr 15 20:40:13 localhost wvdial[7683]: Sending: xxxxxxx
Apr 15 20:40:14 localhost wvdial[7683]: xxxxxxx
Apr 15 20:40:14 localhost wvdial[7683]: Password:
Apr 15 20:40:14 localhost wvdial[7683]: Looks like a password prompt.
Apr 15 20:40:14 localhost wvdial[7683]: Sending: (password)
Apr 15 20:40:14 localhost wvdial[7683]: Welcome to the Internet Group
Apr 15 20:40:14 localhost wvdial[7683]: Welcome to the Internet Group
Apr 15 20:40:14 localhost wvdial[7683]: Entering PPP Session.
Apr 15 20:40:14 localhost wvdial[7683]: IP address is 203.173.142.169
Apr 15 20:40:14 localhost wvdial[7683]: MTU is 1524.
Apr 15 20:40:14 localhost wvdial[7683]: Looks like a welcome message.
Apr 15 20:40:14 localhost pppd[7668]: Serial connection established.
Apr 15 20:40:14 localhost pppd[7668]: using channel 2
Apr 15 20:40:14 localhost pppd[7668]: Using interface ppp0
Apr 15 20:40:14 localhost pppd[7668]: Connect: ppp0 <--> /dev/ttyS0
Apr 15 20:40:15 localhost pppd[7668]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0xa35b4ece> <pcomp> <accomp>]
Apr 15 20:40:15 localhost pppd[7668]: rcvd [LCP ConfReq id=0x1 <mru
1524> <asyncmap 0x0> <pcomp> <accomp> <endpoint [MAC:00:d0:52:04:36:5a]>]
Apr 15 20:40:15 localhost pppd[7668]: sent [LCP ConfAck id=0x1 <mru
1524> <asyncmap 0x0> <pcomp> <accomp> <endpoint [MAC:00:d0:52:04:36:5a]>]
Apr 15 20:40:15 localhost pppd[7668]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0xa35b4ece> <pcomp> <accomp>]
Apr 15 20:40:15 localhost modprobe: modprobe: Can't locate module
ppp-compress-21
Apr 15 20:40:15 localhost modprobe: modprobe: Can't locate module
ppp-compress-21
Apr 15 20:40:15 localhost pppd[7668]: sent [CCP ConfReq id=0x1 <deflate
15> <deflate(old#) 15>]
Apr 15 20:40:15 localhost pppd[7668]: sent [IPCP ConfReq id=0x1
<compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 15 20:40:15 localhost pppd[7668]: rcvd [IPCP ConfReq id=0x1
<compress VJ 0f 01> <addr 203.56.8.90>]
Apr 15 20:40:15 localhost pppd[7668]: sent [IPCP ConfAck id=0x1
<compress VJ 0f 01> <addr 203.56.8.90>]
Apr 15 20:40:15 localhost pppd[7668]: rcvd [LCP ProtRej id=0x2 80 fd 01
01 00 0c 1a 04 78 00 18 04 78 00]
Apr 15 20:40:15 localhost pppd[7668]: rcvd [IPCP ConfRej id=0x1
<compress VJ 0f 01>]
Apr 15 20:40:15 localhost pppd[7668]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 15 20:40:15 localhost pppd[7668]: rcvd [IPCP ConfNak id=0x2 <addr
203.173.142.169> <ms-dns1 203.109.250.50> <ms-dns3 203.109.250.61>]
Apr 15 20:40:15 localhost pppd[7668]: sent [IPCP ConfReq id=0x3 <addr
203.173.142.169> <ms-dns1 203.109.250.50> <ms-dns3 203.109.250.61>]
Apr 15 20:40:16 localhost pppd[7668]: rcvd [IPCP ConfAck id=0x3 <addr
203.173.142.169> <ms-dns1 203.109.250.50> <ms-dns3 203.109.250.61>]
Apr 15 20:40:16 localhost pppd[7668]: local IP address 203.173.142.169
Apr 15 20:40:16 localhost pppd[7668]: remote IP address 203.56.8.90
Apr 15 20:40:16 localhost pppd[7668]: primary DNS address 203.109.250.50
Apr 15 20:40:16 localhost pppd[7668]: secondary DNS address 203.109.250.61
Apr 15 20:40:16 localhost pppd[7668]: Script /etc/ppp/ip-up started (pid
7704)
Apr 15 20:40:16 localhost pppd[7668]: Script /etc/ppp/ip-up finished
(pid 7704), status = 0x0


>
> Thanks for posting the answer! Hopefully I'll remember it should
> there be another post with the same problem.
>