Hi, I've got a PPP connection to my ISP through an Adak 221 ISDN
terminal adapter (has two serial ports, and acts like a normal
modem). Incoming data, ftp and http, for example, works great; I can
get about 7.5Kbytes/second. However, I only get about 5Kbytes/second
for outgoing data. I have a feeling it's not a NetBSD problem, but a
problem with my terminal adapter, but I wanted to get y'all's opinion :)

I've got some stuff captured from tcpdump that maybe someone fluent in
TCP can help me interpret... This is an excerpt of tcpdump output of a
file being ftp'd from my machine, apm2-108, to a machine at my ISP,
ghostwheel. This tcpdump was done on ghostwheel. Everything looks OK
until around the 51.571655 line. If ghostwheel received everything
from 13313 to 14849, why did it only ack up to 13825? It then sits
around waiting until my machine decides to retransmit at 53.454061.

16:57:51.223266 apm2-108.1130 > ghostwheel.ftp-data: . 11777:12289(512) ack 1 win 16384
16:57:51.291321 apm2-108.1130 > ghostwheel.ftp-data: . 12289:12801(512) ack 1 win 16384
16:57:51.292222 ghostwheel.ftp-data > apm2-108.1130: . ack 12801 win 8192 [tos 0x8]
16:57:51.359336 apm2-108.1130 > ghostwheel.ftp-data: . 12801:13313(512) ack 1 win 16384
16:57:51.371605 ghostwheel.ftp-data > apm2-108.1130: . ack 13313 win 8192 [tos 0x8]
16:57:51.427907 apm2-108.1130 > ghostwheel.ftp-data: . 13313:13825(512) ack 1 win 16384
16:57:51.495508 apm2-108.1130 > ghostwheel.ftp-data: . 13825:14337(512) ack 1 win 16384
16:57:51.564313 apm2-108.1130 > ghostwheel.ftp-data: . 14337:14849(512) ack 1 win 16384
16:57:51.571655 ghostwheel.ftp-data > apm2-108.1130: . ack 13825 win 8192 [tos 0x8]
16:57:51.632490 apm2-108.1130 > ghostwheel.ftp-data: . 14849:15361(512) ack 1 win 16384
16:57:51.700858 apm2-108.1130 > ghostwheel.ftp-data: . 15361:15873(512) ack 1 win 16384
16:57:51.769406 apm2-108.1130 > ghostwheel.ftp-data: . 15873:16385(512) ack 1 win 16384
16:57:51.837664 apm2-108.1130 > ghostwheel.ftp-data: . 16385:16897(512) ack 1 win 16384
16:57:51.903513 apm2-108.1130 > ghostwheel.ftp-data: . 16897:17409(512) ack 1 win 16384
16:57:51.969983 apm2-108.1130 > ghostwheel.ftp-data: . 17409:17921(512) ack 1 win 16384
16:57:52.037396 apm2-108.1130 > ghostwheel.ftp-data: . 17921:18433(512) ack 1 win 16384
16:57:52.104812 apm2-108.1130 > ghostwheel.ftp-data: . 18433:18945(512) ack 1 win 16384
16:57:52.171796 apm2-108.1130 > ghostwheel.ftp-data: . 18945:19457(512) ack 1 win 16384
16:57:53.454061 apm2-108.1130 > ghostwheel.ftp-data: . 13825:14337(512) ack 1 win 16384
16:57:53.571696 ghostwheel.ftp-data > apm2-108.1130: . ack 14337 win 8192 [tos 0x8]
16:57:53.749496 apm2-108.1130 > ghostwheel.ftp-data: . 14337:14849(512) ack 1 win 16384

Here's part of the same ftp session as seen from my end. Our clocks
weren't synchronized to the millisecond or anything, so trying to
compare timestamps between the two machines probably isn't going to be
very useful... interesting that my machine sent everything up to
22017, but the last thing ghostwheel got was 19457.

16:57:50.693879 apm2-108.1130 > ghostwheel.ftp-data: . 17921:18433(512) ack 1 win 16384
16:57:50.693973 apm2-108.1130 > ghostwheel.ftp-data: . 18433:18945(512) ack 1 win 16384
16:57:50.694028 apm2-108.1130 > ghostwheel.ftp-data: . 18945:19457(512) ack 1 win 16384
16:57:50.773754 ghostwheel.ftp-data > apm2-108.1130: . ack 11777 win 8192 [tos 0x8]
16:57:50.773918 apm2-108.1130 > ghostwheel.ftp-data: . 19457:19969(512) ack 1 win 16384
16:57:50.883750 ghostwheel.ftp-data > apm2-108.1130: . ack 12801 win 8192 [tos 0x8]
16:57:50.883883 apm2-108.1130 > ghostwheel.ftp-data: . 19969:20481(512) ack 1 win 16384
16:57:50.883943 apm2-108.1130 > ghostwheel.ftp-data: . 20481:20993(512) ack 1 win 16384
16:57:50.973752 ghostwheel.ftp-data > apm2-108.1130: . ack 13313 win 8192 [tos 0x8]
16:57:50.973909 apm2-108.1130 > ghostwheel.ftp-data: . 20993:21505(512) ack 1 win 16384
16:57:51.173755 ghostwheel.ftp-data > apm2-108.1130: . ack 13825 win 8192 [tos 0x8]
16:57:51.173884 apm2-108.1130 > ghostwheel.ftp-data: . 21505:22017(512) ack 1 win 16384
16:57:52.863771 apm2-108.1130 > ghostwheel.ftp-data: . 13825:14337(512) ack 1 win 16384
16:57:53.163762 ghostwheel.ftp-data > apm2-108.1130: . ack 14337 win 8192 [tos 0x8]

I guess my main question is if tcpdump shows 14849 getting to
ghostwheel, why didn't it get acked? Does tcpdump show corrupted
packets? Other question is how can I make my outgoing ftps nice and
fast? :)

Some info that might be useful: The connection between my machine and
the Adak runs at 115200 baud (async), but I only have a 64000 bps
(sync) connection to my ISP. Supposedly, the Adak takes my PPP
packets, extracts the data out of 'em, and then sticks it back into
HDLC framed packets or something to send out the ISDN line. I can send
data out to the Adak faster than it can send it out the ISDN line, but
the Adak doesn't seem to be doing any flow control. I've got one of
those RS232 line tester things with the LEDs hooked up so I can watch
CTS, and it never goes low. I do have the Adak configured to do
RTS/CTS flow control though, so either it thinks it has enough buffer
space to hold everything, or it's just plain broken. I have a feeling
that I'm having some sort of flow control problem though.

My machine's a P100, running NetBSD-current, July 12th kernel,
userland from around June 8. pppd is version 2.3.0. I have no idea
what's on the other end of the ISDN line, perhaps a Livingston
Portmaster of some sort. ghostwheel is running BSD/386 v1.1 though.

I've got the tcpdump for the whole session, as seen from both sides if
someone wants to take a look at 'em.

Um, I guess that's all that I can think of... thanks in advance :)

Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 20 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++