Date: Sun, 24 Oct 93 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #276
To: tcp-group-digest
TCP-Group Digest Sun, 24 Oct 93 Volume 93 : Issue 276
Today's Topics:
Network Standards
slip/ppp problems in ka9q nos 930622? (2 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sat, 23 Oct 93 02:13:51 UTC
From: vk4grl@vk4grl.clayfield.ampr.org
Subject: Network Standards
To: tcp-group@UCSD.EDU
I guess the debate over connection oriented/connectionless services will
continue for some time, however the important thing to consider is the use
of appropriate protocols at each layer. Have you ever tried to use AX25
vc mode (connection oriented link layer) with NOS? Everything goes fine
until the frequency starts to get busy. Then AX25 retransmits and TCP
retransmits and the same information is sent many many times unnecessarily
It is interesting to use ISO terminology here - TCP is analogous to TP4
transport which is designed for a class C network layer (unreliable) network layer.
This is why when we add some lower layer error recovery things go haywire.
By adding vc mode we have (sort of) turned our network layer into a class B
(reliable with signalled errors) and the recovery processes used by TCP and
TP4 are inappropriate.
As an example of more appropriate use of connection oriented network service,
see ISO TP3 which was designed for a class B network layer. No transport
error recovery is necessary unless the network layer signals an error such
as a reset or disconnect.
Should we be looking at a way of using OSI protocols on radio LAN's? The
main problem would be the protocol conversion at internet gateways.
Graham
------------------------------
Date: Fri, 22 Oct 1993 17:20:58 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: slip/ppp problems in ka9q nos 930622?
To: bsa@kf8nh.wariat.org, tcp-group@UCSD.EDU
I don't know of any disk corruption resulting from QEMM in Stealth Mode P,
but that's in the nature of undocumented features. The problem with hard
drive corruption and QEMM Stealth is almost always traced back to disk
cache software which has a faulty implementation of the virtual hard drive
interface definition. This may be exaggerated in Mode P for some reason,
but I don't know. Floppy disk access speed under DESQview usually will
improve enormously under Mode P. Also remember that I was specifically
recommending use of Mode P only in connection with LOCKDMA. Anything that
happens with an undocumented feature is, by definition, risky.
As for Quarterdeck's official position on Mode P, I don't know of any
statement that they have been willing to make on it at all, other than
to say that it is undocumented and unsupported. If they went so far as
to warn of a specific problem such as disk corruption, that is very new.
-- Mike
------------------------------
Date: Fri, 22 Oct 1993 18:21:53 -0400
From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
Subject: slip/ppp problems in ka9q nos 930622?
To: tcp-group@UCSD.EDU
In your message of Fri, 22 Oct 1993 17:20:58 EDT, you write:
+---------------
| I don't know of any disk corruption resulting from QEMM in Stealth Mode P,
| but that's in the nature of undocumented features. The problem with hard
| drive corruption and QEMM Stealth is almost always traced back to disk
| cache software which has a faulty implementation of the virtual hard drive
| interface definition. This may be exaggerated in Mode P for some reason,
| but I don't know. Floppy disk access speed under DESQview usually will
+---------------
I believe the concern was that some disk controllers get confused by it and
screw up their writes badly. It may also affect the timing.
+---------------
| As for Quarterdeck's official position on Mode P, I don't know of any
| statement that they have been willing to make on it at all, other than
+---------------
About this time last year someone on the Quarterdeck BBS (I think it was
there) suggested using ST:P if ST:M and/or ST:F didn't work. Quarterdeck's
response said that yes, mode P exists, and it can work when F and M don't,
but it could also do Bad Things to the disk controller and result in a low-
level format being needed. Since I've seen other kinds of problems cause
this (had to low-level the drive on my former 8088 system once because
something dicked with the interrupts and other parameters and the MFM
controller blew up) I'm not too surprised by this. That was the only mention
of it.
...actually, I think it may have shown up later in a tech note, but it's been
almost a year since I checked because I switched to Linux :-)
++Brandon
--
Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development." ---dmeggins@aix1.uottawa.ca
------------------------------
Date: Fri, 22 Oct 93 23:12:39 +0100
From: sinanis@sungraz.cern.ch (Nick J. Sinanis)
To: tcp-group@UCSD.EDU
info
------------------------------
End of TCP-Group Digest V93 #276
******************************
******************************