| |
PA2AGA > TCPDIG 07.06.96 12:03l 205 Lines 7260 Bytes #-10990 (0) @ EU
BID : TCP_96_119A
Read: GUEST
Subj: TCP-Group Digest 96/119A
Path: DB0AAB<DB0KCP<DB0ZKA<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0AIS<DB0NDK<DB0ACH<
ON4RAT<DB0ACC<PI8DRS<PI8DAZ<PI8GCB<PI8MBQ<PI8VNW
Sent: 960607/0635Z @:PI8VNW.#ZH2.NLD.EU #:11767 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA10695 ; Fri, 07 Jun 96 03:32:25 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.60/7.1) with SMTP
id AA00008386 ; Thu, 06 Jun 96 23:42:17 MET
Received: from pa2aga-10 by pa2aga with SMTP
id AA00008351 ; Thu, 06 Jun 96 23:36:37 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.60/7.1) with SMTP
id AA00004912 ; Thu, 06 Jun 96 23:36:32 MET
Date: Thu, 06 Jun 96 17:36:37 MET
Message-Id: <tcp_96_119A>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/119A
X-BBS-Msg-Type: B
TCP-Group Digest Thu, 6 Jun 96 Volume 96 : Issue 119
Today's Topics:
9600 Baud Deviation (3 msgs)
nntp date/time stamp (2 msgs)
snoop module for tcp/ip
subscribe
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 ftp.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: Wed, 05 Jun 1996 07:33:48
From: fsanford@foxboro.com (Fred Sanford)
Subject: 9600 Baud Deviation
Hello,
Could someone out there please tell me what the deviation should be
for 9600 baud packet using G3RUH modems.
I some people saying 3 Khz and other saying 2 Khz and we have some radios
that we can't get 3 Khz deviation out of. Some before I build an amplifer
to go between the tnc and radio I want to make sure that I need one.
73 - Fred, ka1cqd
Nothin' left to do but :-) :-) :-)
------------------------------
Date: Wed, 5 Jun 1996 09:07:37 -0700
From: brian@nothing.UCSD.EDU (Brian Kantor)
Subject: 9600 Baud Deviation
I run my 9600 bps radios at +/- 2.5 kHz deviation so that I don't
scrape the walls of standard receiver voice IF filters. Other people
run them wider and then have to change the IF filters, which seems
silly to me.
It's a signal-to-noise ratio thing; if you're fully quieting the
receiver, it doesn't really matter. The K9NG and G3RUH and TAPR 9600
bps modems all require a pretty good S/N to work well, so you might as
well build lots of margin into your links anyway.
- Brian
------------------------------
Date: Wed, 05 Jun 96 15:23:54 est
From: walshk@nimo.com
Subject: 9600 Baud Deviation
Fred ...
The Network Time Protocol (NTP) uses a variety of files to manage
the time for the station. The authoratative site for NTP is the
University of Delaware. If you have WWW browser capability, try:
http://www.eecis.udel.edu/~ntp/
There is a faq as well as other documentation and RFC's that
describe the whole process.
Happy Hunting ...
'73 Kevin WB2JOD
______________________________ Reply Separator
_________________________________
Subject: 9600 Baud Deviation
Author: fsanford@foxboro.com (fred sanford) at INTERNET
Date: 6/5/96 3:06 PM
Hello,
Could someone out there please tell me what the deviation should be for
9600 baud packet using G3RUH modems.
I some people saying 3 Khz and other saying 2 Khz and we have some radios
that we can't get 3 Khz deviation out of. Some before I build an amplifer
to go between the tnc and radio I want to make sure that I need one.
73 - Fred, ka1cqd
Nothin' left to do but :-) :-) :-)
------------------------------
Date: Wed, 05 Jun 1996 07:44:10
From: fsanford@foxboro.com (Fred Sanford)
Subject: nntp date/time stamp
Hello,
Does anyone know how nntp time and date should work? What I see
is that a nntp client polls the server, the server sends a date and time,
but the client uses its local date and time for the nntp.dat file.
I would have figured, that he client should have used the server's
date and time for the nntp.dat file.
Yes, I'm using nos and maybe I should have posted this to the nos-bbs
group, but I want to know how it works on systems other than nos.
73 - Fred, ka1cqd
Nothin' left to do but :-) :-) :-)
------------------------------
Date: Wed, 5 Jun 1996 09:03:30 -0700
From: brian@nothing.UCSD.EDU (Brian Kantor)
Subject: nntp date/time stamp
NNTP has an extension command 'DATE' that returns the server's current
illusion as to time so that the client and server are talking the same
time zone.
This should not be used to adjust the client's clock, but rather as a
'magic cookie' timestamp. There is no guarantee that the value returned
by the date command isn't in furlongs-per-fortnight/lightyears or some
other such exciting and breathtaking set of units. It'll be consistent
with that news server, but that's all that's guaranteed.
That said, I think you'll find most implementations return a
millisecond-accurate time of day. But don't count on it.
If you want to sync clocks, use NTP.
- Brian
------------------------------
Date: Wed, 5 Jun 1996 22:07:57 +0100 (GMT+0100)
From: Julian Munoz <julian@linux.ea4abb.ampr.org>
Subject: snoop module for tcp/ip
Hello,
I think that the exponential/linear backoff algoritm used at tcp level is
done for what it is done (adapt the link to the traffic), but is not
valid for radio channels where we have high bit error rate.
The same happens in the link level of ax25 in jnos : if we want that our
system accept far users (wich we don't hear well), we have to set an
experimental limit to the round trip time (maxwait).
If we are using datagram mode, a fec approach at the link layer do that
tcp will work better because of the improvement of ber, but there will
alway be a limit where tcp links will not work as it should.
If we are using virtual circuit mode (tcp in a ax25 connected channel)
then we can use better link layer methods, combining fec and
retransmitions, adaptative links etc ... In the document they speak about
it :
" Link-level Retransmissions [PAL +95]: In this approach, the wireless
link implements a retransmission protocol coupled with forward error
correction at the data-link level. The advantage of this approach is that
it improves the reliability of communication independent of the
higher-level protocol. However, TCP implements its own end-to-end
retransmission protocol. Studies have shown that independent
retransmission protocols such has these can lead to degraded performance,
especially has error rates become significant [DCY93]* . A tight coupling
of transport- and link-level retransmission time-outs and policies is
necessary for good performance. In particular, information needs to be
passed down to the data link layer about timeout values and policies
reasonable for co-existence with higher transport layer policy.
...
[DCY93]
A-DeSimone, M.C. Chuah, and O.C. Yue.
Throughput Performance of Transport-Layer Protocols over Wireless LANS.
To be continued in digest: tcp_96_119B
Read previous mail | Read next mail
| |
