🚀 go-pugleaf

From: "k1io@fn42jk 19-Jun-1991 0942" <goldstein@carafe.enet.dec.com>
Date: Wed, 19 Jun 91 10:13:01 EDT
Subject: Re: V.29 vs FSK

>	IMHO, the reason 9600bps hasn't done much is that people don't
>	want to do rig surgery even if there is a well publicised mod
>	for doing it. I don't know if that's a good or bad thing but
>	that's the reason. Given that this approach has the advantage
>	of not requiring such surgery, I reckon it will at least give
>	9600 a chance *both* at the user access level and for backbones
>	where the disadvantages of a long train time aren't too apparent.

I Agree.  Rig surgery is not a winning idea.  But that doesn't lead 
necessarily to V.29 fax modems for 9600 bps use.  What other better
options may exist?  The problem I don't want to see replayed is the
standard ham mistake:  Take the first semi-working hack and declare it
standard. That got us in the 202 mess, the AX.25 mess, etc.  Maybe Japan
is using V.29 instead of 202, which is certainly better -- now they're
using 1975 technology instead of 1965 technology.  But that's not what's
going to save the bands. 

What's wrong with V.29 is training time.  What's wrong with G3RUH/K9NG
is frequency and phase response requirements, which translate to "rig
surgery" on voice radios.  Now, is it possible to have a 9600 bps modem
that doesnt take more than a few milliseconds to train and still runs in
a voice bandwidth?  I'm not certain but I suspect it is.

For that matter, one of the reasons I did some work on AMI modems
was because they can do 4800 bps without munging the radio.  The
HAPN version, alas, doesn't do it right (there's a concept of "pulse
template" which establishes the analog-domain characteristics).
Getting to 9600 is trickier (AMI won't do) but I think there are 
fast-training variants or implementations of V.29.

And I don't think we should assume that today's old voice radios will
dominate forever.  Of course, if we use protocols that require
slow turnaround, they will :-( . 

>	I suppose for good old AX25 L2 user access traffic this modem
>	isn't much use beacause of the train time. I'm thinking particularly
>	of the common situation where a user logs onto a mailbox sends
>	'LL 200' and sits back for the next 20 minutes sending ACKs 
>	(or REJs :-) to the 200 I frames sent from the BBS. That's
>	certainly wasteful on the user side. Then of course, what about
>	L2 file transfers ? Who sees those these days - not in my area
>	certainly - I'm sure these would benefit.

To be sure, today's BBS code is smarter and fills the AX.25 L2 MTU
with multiple text lines. It's really not all so inefficient if you
don't digipeat.  BTW, we TCPers shouldn't be so smug either; the
selective recovery capability of TCP is rather minimal, to be kind.
Given high loss rates, I can think of much more robust protocols.
Anybody want me to explain the COMSAT multi-selective reject?
     fred k1io


----
From: jackb@MDI.COM (Jack Brindle)
Date: Wed, 19 Jun 91 10:17:17 PDT
Subject: Re: V.29 vs FSK

> For protocols at a higher level that have the ability to pack 
> more than a line of text into a frame (like IP/TCP) things may 
> well improve because at last we can open up MTUs. Or am I being 
> too naieve ?

Yes. People tend to think of backbones as being independent of the
LANs/MANs the connect. This is true only if all traffic across the
backbone is BBS type where the BBS is located at the backbone interface
to the LAN/MAN. Unfortunately, this is almost never the case. The high
speed backbones in place today simply port data from one low-speed LAN/MAN
to another. This means that we get several logical low-speed channels
co-existing on the backbone, with the inherent tendencies of the low-speed
LANs (generally an ack responding to every packet). If you really want to
mess things up, place a news or mail source on the high-speed backbone.
The news source will start pumping out data, only to stations on the LAN,
only to be flow controlled by the LAN. Things slow down quickly on both
the LAN (which has become saturated by the news), the high-speed system
(where the gateway node fills its buffers) and the news server (which has
had its flow shut down). The flow mechanism causes small "LAN-sized" packets
to be carried across the backbone. Next thing to happen is the LAN users
start screaming that someone is hogging the channel.

The basic point, though, is that the small frame activity on the LAN is
directly brought onto the backbone. This eliminates the desired large
packets needed to get good throughput on the backbone. What is really
needed here is a better gateway scheme that will use large packets on the
backbone, buffering the data and feeding it to the LAN with the proper
characteristics. (And vice-versa the other way, waiting for a reasonable
amount of data to accumulate before transmitting. Of course I wouldn't
want this if I were logging onto a UNIX box...). This will require some
changes in timing in the TCP system, but should be doable. Gee, why haven't
we thought of this before?  This also points out (again) the fact that the
BBS software needs to be network-aware, and use real file-transfer techniques
to transfer mail.

Oh well...
73, JackB, wa4fib/7


----
From: "k1io@fn42jk 19-Jun-1991 0942" <goldstein@carafe.enet.dec.com>
Date: Wed, 19 Jun 91 10:13:01 EDT
Subject: Re: V.29 vs FSK

>	IMHO, the reason 9600bps hasn't done much is that people don't
>	want to do rig surgery even if there is a well publicised mod
>	for doing it. I don't know if that's a good or bad thing but
>	that's the reason. Given that this approach has the advantage
>	of not requiring such surgery, I reckon it will at least give
>	9600 a chance *both* at the user access level and for backbones
>	where the disadvantages of a long train time aren't too apparent.

I Agree.  Rig surgery is not a winning idea.  But that doesn't lead 
necessarily to V.29 fax modems for 9600 bps use.  What other better
options may exist?  The problem I don't want to see replayed is the
standard ham mistake:  Take the first semi-working hack and declare it
standard. That got us in the 202 mess, the AX.25 mess, etc.  Maybe Japan
is using V.29 instead of 202, which is certainly better -- now they're
using 1975 technology instead of 1965 technology.  But that's not what's
going to save the bands. 

What's wrong with V.29 is training time.  What's wrong with G3RUH/K9NG
is frequency and phase response requirements, which translate to "rig
surgery" on voice radios.  Now, is it possible to have a 9600 bps modem
that doesnt take more than a few milliseconds to train and still runs in
a voice bandwidth?  I'm not certain but I suspect it is.

For that matter, one of the reasons I did some work on AMI modems
was because they can do 4800 bps without munging the radio.  The
HAPN version, alas, doesn't do it right (there's a concept of "pulse
template" which establishes the analog-domain characteristics).
Getting to 9600 is trickier (AMI won't do) but I think there are 
fast-training variants or implementations of V.29.

And I don't think we should assume that today's old voice radios will
dominate forever.  Of course, if we use protocols that require
slow turnaround, they will :-( . 

>	I suppose for good old AX25 L2 user access traffic this modem
>	isn't much use beacause of the train time. I'm thinking particularly
>	of the common situation where a user logs onto a mailbox sends
>	'LL 200' and sits back for the next 20 minutes sending ACKs 
>	(or REJs :-) to the 200 I frames sent from the BBS. That's
>	certainly wasteful on the user side. Then of course, what about
>	L2 file transfers ? Who sees those these days - not in my area
>	certainly - I'm sure these would benefit.

To be sure, today's BBS code is smarter and fills the AX.25 L2 MTU
with multiple text lines. It's really not all so inefficient if you
don't digipeat.  BTW, we TCPers shouldn't be so smug either; the
selective recovery capability of TCP is rather minimal, to be kind.
Given high loss rates, I can think of much more robust protocols.
Anybody want me to explain the COMSAT multi-selective reject?
     fred k1io


----
From: barry@dgbt.doc.ca (Barry McLarnon)
Date: Wed, 19 Jun 91 15:06:05 EDT
Subject: Re: V.29 vs FSK

>Dunno that either is a clear winner.  If I were buying everything, and all my
>friends were buying from scratch too, I'd go FSK with real data radios like
>the Tekk or Kantronics units, but there's a *lot* of V.29 on the air in Japan
>today, and I dunno that we can say as much for FSK in the US... makes me wonder
>who's really got the better approach.

One thing that's not been mentioned yet is that V.29/AFSK, being a highly
convoluted and bizarre way of transmitting data over a radio channel,
requires considerably higher link margins than a well-implemented direct FSK.
Therefore it is not a good choice for backbone linking, even if you go to
full duplex.  This is less important for MAN use, but it is still a factor
because folks tend to try to cover wide areas with MANs instead of deploying
them in small cells, as they should be!

The more optimal FSK hardware is indeed taking a long time to take shape,
but it's worth waiting for.  It would be a a nuisance to have two
incompatible 9.6kb standards around.  Let's take the extra time and do it
right (although I have no doubt V.29 will find some niches).

Of course, what we *really* should be doing is skipping 9.6 entirely and
going directly to 56kb.  You may heard me say that before... :-)

Barry VE3JF


----
From: foxworth@bnlls1.nsls.bnl.gov (Bob Foxworth)
Date: Wed, 19 Jun 91 23:43:17 EDT
Subject: report of problems with pa0gri nos 0604

A local user is running the 0604 version of pa0gri. He reports two problems,
first with smtp mail sending multiple copies of some mail messages out
from his station, secondly sometimes ftp sessions are abruptly broken
off. I believe two users locally are running it (myself not included as
yet) with no word from the other station. Any other feedback on this?


----
From: Michael Chace <mikec@praxis.co.uk>
Date: Wed, 19 Jun 91 08:37:27 +0100
Subject: Re: V.29 vs FSK


Since I brought this one up....

>>>>> Regarding V.29 vs FSK ; Bdale Garbee <bdale@col.hp.com> and
      Fred (K1IO) have added:

> That's why direct FSK and AMI codes make more sense.

Bdale> Absolutely agreed, *if*, and only if, the implementation of FSK 9600 in
a given 
Bdale> area is done in such a way that fast tx/rx switching times are
Bdale> real or not an issue.

	That's right. I suppose it's just like running p-persistence timing
	and/or building a TAPR DCD mod kit in (to help reduce TXD) - If
	you're the only person on the channel doing it there is very little
	point. 

Bdale> The one big win of a V.29 approach (usually run at 7200 baud in Japan, by the
Bdale> way), is that you can populate any band that has voice gear available without
Bdale> needing special radios...

	My point precisely and as I mentioned in the posting that started
	this all off again. In the UK 9600bps hasn't taken off either,
	despite it being around for some 5? years now and having G3RUH as
	one of our fellow packeteers. There's lots of talk about moving
	to higher data rates but as we all know it costs money.

	IMHO, the reason 9600bps hasn't done much is that people don't
	want to do rig surgery even if there is a well publicised mod
	for doing it. I don't know if that's a good or bad thing but
	that's the reason. Given that this approach has the advantage
	of not requiring such surgery, I reckon it will at least give
	9600 a chance *both* at the user access level and for backbones
	where the disadvantages of a long train time aren't too apparent.

	I suppose for good old AX25 L2 user access traffic this modem
	isn't much use beacause of the train time. I'm thinking particularly
	of the common situation where a user logs onto a mailbox sends
	'LL 200' and sits back for the next 20 minutes sending ACKs 
	(or REJs :-) to the 200 I frames sent from the BBS. That's
	certainly wasteful on the user side. Then of course, what about
	L2 file transfers ? Who sees those these days - not in my area
	certainly - I'm sure these would benefit.
	
	BUT

	For protocols at a higher level that have the ability to pack 
	more than a line of text into a frame (like IP/TCP) things may 
	well improve because at last we can open up MTUs. Or am I being 
	too naieve ?

73. Mike



----
From: PMcAfee.El_Segundo@xerox.com
Date:  Wed, 19 Jun 1991 12:08:22 PDT
Subject: Re: A plea when sending stuff


I received my PI board without any extra fee in Los Angeles. NO customs fee.

Pete


----
From: 
Date: 
Subject: 

X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/;
               Relayed; Thu, 20 Jun 1991 08:35:00 +0000
X400-Received: by /PRMD=iris/ADMD= /C=es/; Relayed;
               Thu, 20 Jun 1991 09:37:16 +0000
Date: Thu, 20 Jun 1991 13:35:00 +0000
X400-Originator: flimon@fi.upm.es
X400-Mts-Identifier: [/PRMD=iris/ADMD= /C=es/;910620153716]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 767
Conversion: Prohibited
From: flimon@fi.upm.es
Message-Id: <"767*/S=flimon/OU=fi/O=upm/PRMD=iris/ADMD= /C=es/"@MHS>
To: garnier <garnier@sol.med.ge.com> (IPM Return Requested)
Cc: tcp-group <tcp-group@ucsd.edu> (IPM Return Requested)
Subject: Re: mfj-2400 baud modem

Dave,

Several months ago I bought a MFJ 1274 T (with 2400 bps modem).  Since the
begining I saw that at 2400 bps it had a great number of retries because of
dificulties in reception.

After reading Mike's message (KA9WSB), I tried to use the DCD that the
transceiver has... but everything kept the same way.

Finally, taking a look at the TNC's (1274) scheme, I saw that at the audio
entrance to the modem at 2400 bps, i goes trough a 10 nF (C69) condenser, which
looks OK for 1200, but not for 2400.

This TNC comes prepared to set up a condenser (C70) in parallel to the other
one mentioned before.  In the scheme it says "optional component".  
If I set up in C70 a 100 nF condenser (as it says in the scheme) ... problems
in reception are solved and the behavior is perfect.

In 1278 something similar happens, but in this case they don't say anything
about the posibility of setting up a parallel condenser.  So you have to 
change C82 or C80 (or both) by a 100 nF condenser, if you are going to use
RAD1 or RAD2, respectively, at 2400.

What I can not tell you is if this change in the 1278 affects to the behavior
in any other mode that this TNC offers, but I can assure you that with this
modification ... at last I have managed to work with TCP/IP at 2400 without
problems.

I hope that my experience helps you in some way.

Regards

			Fernando Limon (EA4/EA8SU)
			flimon@fi.upm.es


----
From: pnm%saturn.ACC.COM@salt.acc.com (Patrick N. Medved)
Date: Thu, 20 Jun 91 09:51:09 EDT
Subject: Running NET in Windows



I am trying to run net.exe from windows on a 386 clone.

Everything comes up okay, but my connections seem to hang or
stop sometimes.   I am connecting (FTP, Telnet) to other hosts
on the local Ethernet.

I turn on a trace of my Ethernet port and it seems like no data
is coming in even though Etherfind will show TCP retransmissions
from the connected host.

Everything works find when I don't run it in Windows 3.0.

In adding Windows, the following was added to my config.sys:

	device=c:\himem.sys
	device=c:\WINDOWS\smartdrv.sys 2048 512.


Also, I am using a Western Digital Ethernet Card.

The driver is loaded as follows:

	wd8003e -w 0x78 0x280 0xd000

I added the -w to the driver command line for it to work in windows.

Anything else that I should be doing?

Thanks, PAT
pnm@saturn.acc.com




----