larry@nstar.uucp (Larry Snyder) (10/31/90)
We have SLIP up and running here on nstar - and throughput
over Telebits is very bad - while 2400 baud appears faster -
it is as expected still quite - so I guess V.32 is the next path.
Are the new V.32 with v.42bis modems the way to go with SLIP?
Will it be possible to get throughput in the 15 kbytes range
with these new modems (in excess of the carrier rate - after all
the modem manufactures claim throughput in excess of 20,000 bps?)
--
Larry Snyder, Northern Star Communications, Notre Dame, IN USA
{larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu}
backbone usenet newsfeeds available
Public Access Unix Site (219) 289-0282 (5 high speed lines)grr@cbmvax.commodore.com (George Robbins) (11/01/90)
In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: > We have SLIP up and running here on nstar - and throughput > over Telebits is very bad - while 2400 baud appears faster - > it is as expected still quite - so I guess V.32 is the next path. > > Are the new V.32 with v.42bis modems the way to go with SLIP? > Will it be possible to get throughput in the 15 kbytes range > with these new modems (in excess of the carrier rate - after all > the modem manufactures claim throughput in excess of 20,000 bps?) There is no particular assurance that V.42 works well with slip or PPP, though they might. On the other hand, I wouldn't buy a V.32 modem that didn't include these capabilities. Now, any changes that affect basic bandwidth, i.e. V.32 bis are likely to help, but the facts aren't in yet... Previous comments on slip vs trailblazers have indicated that interative use of slip is pretty miserable, but performance for file transfers, i.e. FTP was pretty good. If you have access to T2500's, try v.32 slip and see which you like best... There are also a few poorly documented registers which affect TB packetizing behavior which you might want to play with... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
cpcahil@virtech.uucp (Conor P. Cahill) (11/01/90)
In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >Are the new V.32 with v.42bis modems the way to go with SLIP? >Will it be possible to get throughput in the 15 kbytes range >with these new modems (in excess of the carrier rate - after all >the modem manufactures claim throughput in excess of 20,000 bps?) I wouldn't count on getting > 800byte/sec throughput with slip because you won't be able to use the error correction mode (it will conflict with the acks required by slip). Besides, most modem manufacturer claims of throughput deal with throughput of clear text (which is pretty easy to compress), not a standard mix of text and data (which is what you would expect on a typical slip connection). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
palowoda@fiver (Bob Palowoda) (11/01/90)
From article <15506@cbmvax.commodore.com>, by grr@cbmvax.commodore.com (George Robbins): > In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: [some stuff deleted] > There is no particular assurance that V.42 works well with slip > or PPP, though they might. On the other hand, I wouldn't buy a ^^^^^ Is there any source code examples useing PPP on 386 versions of UNIX available? ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
larry@nstar.uucp (Larry Snyder) (11/01/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >>Are the new V.32 with v.42bis modems the way to go with SLIP? >>Will it be possible to get throughput in the 15 kbytes range >>with these new modems (in excess of the carrier rate - after all >>the modem manufactures claim throughput in excess of 20,000 bps?) >I wouldn't count on getting > 800byte/sec throughput with slip because >you won't be able to use the error correction mode (it will conflict with the >acks required by slip). >Besides, most modem manufacturer claims of throughput deal with throughput >of clear text (which is pretty easy to compress), not a standard mix of >text and data (which is what you would expect on a typical slip connection). But I thought that SLIP assumed the hardware (modem link) supplied the error correction - not TCP/IP itself - am I wrong? So for SLIP you are saying I don't want MNP enabled? How about v.42bis? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
raymond@gem.stack.urc.tue.nl (Raymond Nijssen) (11/01/90)
larry@nstar.uucp (Larry Snyder) writes: >We have SLIP up and running here on nstar - and throughput >over Telebits is very bad - while 2400 baud appears faster - >it is as expected still quite - so I guess V.32 is the next path. The Telebit Trailblazer PEP mode is in fact a half duplex mode, so it will behave like a modem in HST mode: SLIP really _needs_ real full duplex connections. The performance penalty when using half duplex lines due to enormous extra overhead (for line turnarounds, trashing/rebuild of the compression tables etc.) could be up to 500% >Are the new V.32 with v.42bis modems the way to go with SLIP? Definitely yes. These modems support full duplex transmissions with data compression. >Will it be possible to get throughput in the 15 kbytes range >with these new modems (in excess of the carrier rate - after all >the modem manufactures claim throughput in excess of 20,000 bps?) I don't know what you mean with 'carrier rate', but I guess you mean the '(raw) bits per second' rate. (which should not be confused with the 'baudrate'). Well, whenever a manufacturer claims their modems have a througput in excess of 20kbps, they only give you a guarantee that their device will never exceed this rate. In real life, the probability distribution over the transmission alphabet is such, that in spite of advanced data compression algorithms used in the modems, the throughput improvement because of data compression is av. 50%. Obviously, this figure will be much lower when files are transmitted which are already compressed. ______________________________________________________________________________ Raymond X.T. Nijssen / / Oh VMS, please forgive me all raymond@ele.tue.nl / / unfriendly things I said about you
DRJ100@psuvm.psu.edu (Daniel R. Jeuch) (11/02/90)
In article <1990Nov01.025031.12861@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: > >In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) >writes: >>Are the new V.32 with v.42bis modems the way to go with SLIP? >>Will it be possible to get throughput in the 15 kbytes range >>with these new modems (in excess of the carrier rate - after all >>the modem manufactures claim throughput in excess of 20,000 bps?) > >I wouldn't count on getting > 800byte/sec throughput with slip because >you won't be able to use the error correction mode (it will conflict with the >acks required by slip). Admittedly, Even with a V.32 MNP5 capable modem, you shouldn't use MNP5 because it tends to slow things down. But with a 9600V.32 MNP4 setting, througput for me is on average .8-.9kb/sec... Not bad. TN3270 is slow, but it it nice to be able to FTP anywhere over a phone line! :) Of course, this also depends on how your host decides to feed you with data... If you have last priority on the local net, you might not get .9kb/sec. P.S. This is average. Believe it or not, I had a transfer of 1.01 kb/sec once.... but only Once. ----- Daniel R. Jeuch Microsoft Corp. Student Rep. 10 Vario Blvd., Box 185 DRJ100@PSUVM, drj100@psuvm.psu.edu State College, PA 16803 (814) 867-4622, (800) 232-5129
cec@cup.portal.com (Cerafin E Castillo) (11/02/90)
Larry,
V.32 is definitely the way to go for TCP/SLIP
interactive sessions (telnet). TELEBIT PEP works well
with an ftp or other such bulk data transfers due to
the nature of the packetization. PEP is half duplex
(adaptive duplex) and will be 'jerky' on SLIP telnet
sessions. But, then again, when the phone line is
bad enough PEP will be the only modulation which will
keep up good throughput.
V.42 (LAP-M) will help keep line noise from killing
your connection in V.32. My experience with old SLIP is that
V.42 will not cause a problem with ACK or other such SLIP packets.
CSLIP (Van Jacobson RFC 1144) will also do pretty good with
V.32/V.42. PPP (Hobby/Perkins RFC 1134) with IP compression
(VJ 1144) also exhibits good behaviour.
My strong recommendation to you it that you use a T2500
TELEBIT modem to do both V.32 and PEP, which ever is needed on
a connection basis, to do SLIP/CSLIP/PPP. Furthermore, I recommend
that you switch over to using TCP/CSLIP or PPP with compressed IP
to yield better V.32 throughputs, as well as PEP throughput.
If your tired of hacking your kernel, try getting a TELEBIT
NetBlazer. This will make life easier for a lot of us Serial Line
Dial-up IP users. Call me if you need more info on any of this.
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \|| \\|
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
NTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================cpcahil@virtech.uucp (Conor P. Cahill) (11/02/90)
In article <1990Nov01.145738.16101@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >But I thought that SLIP assumed the hardware (modem link) supplied the >error correction - not TCP/IP itself - am I wrong? If I remember correctly, SLIP itself does not have error correction. However, the layers above it (TCP in most cases) will usually have thier own error correction. The main exception to this is the UDP protocol (which is used by NFS). Even without the error correction problem the IP datagrams still have an packet/ack protocol. >So for SLIP you are saying I don't want MNP enabled? How about v.42bis? I would think that either of the protocols (due to thier own packetization) would result in lower throughput. Wait for an implementation of PPP to get good throughput over serial lines. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
larry@nstar.uucp (Larry Snyder) (11/02/90)
DRJ100@psuvm.psu.edu (Daniel R. Jeuch) writes: >Admittedly, Even with a V.32 MNP5 capable modem, you shouldn't use MNP5 >because it tends to slow things down. But with a 9600V.32 MNP4 setting, >througput for me is on average .8-.9kb/sec... Not bad. TN3270 is slow, >but it it nice to be able to FTP anywhere over a phone line! :) >Of course, this also depends on how your host decides to feed you with >data... If you have last priority on the local net, you might not get >.9kb/sec. Well, with the T2000 - I get right round 1kb/sec and with the 2400 baud modem - I get right around 1.5 kb/sec which is "fair" I guess. I received a message that stated if our (I am running ISC 2.2) SLIP uses compressed headers we would get better throughput - also I should wave RFC1144, RFC1171 and RFC1172 at the ISC developers. Comments from ISC? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.uucp (Larry Snyder) (11/02/90)
cec@cup.portal.com (Cerafin E Castillo) writes: > V.42 (LAP-M) will help keep line noise from killing > your connection in V.32. My experience with old SLIP is that > V.42 will not cause a problem with ACK or other such SLIP packets. > CSLIP (Van Jacobson RFC 1144) will also do pretty good with > V.32/V.42. PPP (Hobby/Perkins RFC 1134) with IP compression > (VJ 1144) also exhibits good behaviour. I assume that these different versions of SLIP are complete replacements - not options or flags to turn with what I am running? > If your tired of hacking your kernel, try getting a TELEBIT > NetBlazer. This will make life easier for a lot of us Serial Line > Dial-up IP users. Call me if you need more info on any of this. My wife would have a fit - remember - this is a hobby for me (even though I like to spend money - I can't justify THAT much money).. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.uucp (Larry Snyder) (11/02/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >Wait for an implementation of PPP to get good throughput over serial >lines. When will this be released? Would anyone happen to know if release 4 supports PPP? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
dougm@ico.isc.com (Doug McCallum) (11/02/90)
In article <1990Nov02.032318.18632@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: ... >If I remember correctly, SLIP itself does not have error correction. However, >the layers above it (TCP in most cases) will usually have thier own >error correction. The main exception to this is the UDP protocol (which is >used by NFS). A bigger problem than not having error correction is that SLIP has no error "detection". The checksumming used by IP and UDP is very simple. Its a one's complement checksum that cannot detect certain classes of errors. For example, suppose one byte in the data stream has a 1 bit changed to a 0. Suppose an even number of bytes later a different byte has a 0 bit changed to a 1 in the same position as the previous error. If nothing else has changed, IP or UDP (or TCP) won't see an error and you have corrupted data. This usually doesn't hurt for a telnet or rlogin session, but it isn't particularly nice for NFS or file transfer. Undetected data corruption is not a desirable trait but it is something that occurs with SLIP. PPP has a CRC mechanism so will detect errors. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com
jdeitch@jadpc.cts.com (Jim Deitch) (11/03/90)
In article <15506@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: >In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >> We have SLIP up and running here on nstar - and throughput >> over Telebits is very bad - while 2400 baud appears faster - >> it is as expected still quite - so I guess V.32 is the next path. >> >> Are the new V.32 with v.42bis modems the way to go with SLIP? >> Will it be possible to get throughput in the 15 kbytes range >> with these new modems (in excess of the carrier rate - after all >> the modem manufactures claim throughput in excess of 20,000 bps?) > >There is no particular assurance that V.42 works well with slip >or PPP, though they might. On the other hand, I wouldn't buy a >V.32 modem that didn't include these capabilities. > >Now, any changes that affect basic bandwidth, i.e. V.32 bis are >likely to help, but the facts aren't in yet... > >Previous comments on slip vs trailblazers have indicated that >interative use of slip is pretty miserable, but performance for >file transfers, i.e. FTP was pretty good. If you have access to >T2500's, try v.32 slip and see which you like best... There are >also a few poorly documented registers which affect TB packetizing >behavior which you might want to play with... > I have a T2500 and use it under V.32 for SL/IP. In the pep mode it seems that the modem eventually gets confused and quits. I also use the MNP compression and average about 800k bytes throughput. I haven't tried it without the MNP but suspect that it helps some. The telnet sessions I have done seem to perform better under V.32 also. Can you expand on the packet registers and I can give them a try and post what I find out. For some backround: My end: 20 Mhz 386 clone with 8 meg memory. ISC 2.2 with HBTCP 1.2 T2500 and USR HST modems. Normal use of slip is through a computone Atvantage card but also use the FAS drivers on standard ports. My Host: DEC VAX 8600 running BSD 4.3 Jim -- UUCP: nosc!jadpc!jdeitch ARPA: jadpc!jdeitch@nosc.mil INET: jdeitch@jadpc.cts.com
jdeitch@jadpc.cts.com (Jim Deitch) (11/03/90)
Let me expand on my other post a bit. I don't have the machine, it is not mine. It is a clients of mine that pretty much let's me do what I want after hours and weekends in exchange for my services. Jim -- UUCP: nosc!jadpc!jdeitch ARPA: jadpc!jdeitch@nosc.mil INET: jdeitch@jadpc.cts.com
cec@cup.portal.com (Cerafin E Castillo) (11/03/90)
Larry,
I konw that ISC is doing some work with PPP for use with
WAN products like the NetBlazer. In the meantime, you might want
to fish off sources for KA9Q [NOS] (PPP.12) from UCDavis. Katie
Stevens did a nice job with this and you might be able to port
it onto your system. Good Luck!
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \|| \\|
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
NTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================jparnas@larouch.uucp (Jacob Parnas) (11/03/90)
In article <1990Oct31.115338.4582@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes: |> ... |> |> Are the new V.32 with v.42bis modems the way to go with SLIP? |> Will it be possible to get throughput in the 15 kbytes range This would be pretty impressive, around 150000 baud! I assume you mean 15000 baud. |> with these new modems (in excess of the carrier rate - after all |> the modem manufactures claim throughput in excess of 20,000 bps?) |> Here's some test results I got: All tests are between 2 IBM RT/PC's running 4.3 BSD UNIX with header compressed SLIP and using Dickens Data Systems 8 port adapters. ------------------------------------------------------------------------------- Microcom 3296hs BETA: PROM LEVEL: GOLD: 8/31/90, SERIAL BAUDRATE: 38400 PING test... ----dagorlad.watson.ibm.com PING Statistics---- 103 packets transmitted, 102 packets received, 0% packet loss round-trip (ms) min/avg/max = 342/355/382 FTP test: default tcp_recvspace * 1024 * FILE DESCRIPTION DIR SIZE THROUGHPUT ---- ----------- --- ---- ------------- one * 1024 * best case, all 1's GOLD get 133K 3.2 Kbyte/sec /etc/hosts 1024 ascii unix host table get 200K 2.8 Kbyte/sec gigiplot 1024 binary, application get 50K 2.1 Kbyte/sec vmunix 1024 binary, UNIX kernel get 1M 1.7 Kbyte/sec hosts.Z 1024 worst case, precompressed get 69K 1.1 Kbyte/sec ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
milton@en.ecn.purdue.edu (Milton D Miller) (11/04/90)
In article <35513@cup.portal.com> cec@cup.portal.com (Cerafin E Castillo) writes: > > >Larry, > I konw that ISC is doing some work with PPP for use with >WAN products like the NetBlazer. In the meantime, you might want >to fish off sources for KA9Q [NOS] (PPP.12) from UCDavis. Katie >Stevens did a nice job with this and you might be able to port >it onto your system. Good Luck! > FYI: Phil has incorporated Katie's PPP in the last release, so the port should be even easer now :-) He did mention that Katie updated her PPP stuff since he got the code to integrate, though. This is in the 10/29 version; the previous one was quite stable for beta code. milton
larry@nstar.uucp (Larry Snyder) (11/04/90)
jdeitch@jadpc.cts.com (Jim Deitch) writes: > computone Atvantage card but also use what version of computone drivers? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
kim@Software.Mitel.com (Kim Letkeman) (11/04/90)
In article <1990Nov3.055609.6391@larouch.uucp> jparnas@larouch.uucp (Jacob Parnas) writes: | In article <1990Oct31.115338.4582@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes: | |> ... | |> | |> Are the new V.32 with v.42bis modems the way to go with SLIP? | |> Will it be possible to get throughput in the 15 kbytes range | | This would be pretty impressive, around 150000 baud! I assume you | mean 15000 baud. This would be pretty impressive. I assume you mean 15000 bits per second. -- Kim Letkeman kim@software.mitel.com uunet!mitel!spock!kim
larry@nstar.uucp (Larry Snyder) (11/04/90)
jparnas@larouch.uucp (Jacob Parnas) writes: >All tests are between 2 IBM RT/PC's running 4.3 BSD UNIX with >header compressed SLIP and using Dickens Data Systems 8 port adapters. >Microcom 3296hs BETA: PROM LEVEL: GOLD: 8/31/90, SERIAL BAUDRATE: 38400 what version of SLIP - PPP? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.uucp (Larry Snyder) (11/04/90)
earlier I posted a message (article) about the computone board (and
drivers) not working with slip -
I called computone, and they didn't know what slip was - (likewise
they didn't know that sysV rel 4 was shipping since I also asked if
they had a driver for release 4) - but they did suggest that I download
the latest driver from their support BBS -
I called the bbs (which is running under unix) - and downloaded the
latest drivers for the intelliport boards (the drivers are supplied
as disk images - so one needs to download the entire 1.2 megabytes
even through only around 150K is actually the drivers and support
files and on top of that at 2400 baud).
Anyhow, the latest drivers for AT&T Unix (and 386/ix) is release
4.56 - and SLIP works just dandy on the Computone ports --
--
Larry Snyder, Northern Star Communications, Notre Dame, IN USA
{larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu}
backbone usenet newsfeeds available
Public Access Unix Site (219) 289-0282 (5 high speed lines)larry@nstar.uucp (Larry Snyder) (11/05/90)
well - like I said in a previous article SLIP works with
the 4.56 Intelliport drivers from Computone - but after
leaving the system up while I took the kids out to the
Olive Garden for lunch - I noticed that someone had been
having problems getting a connect with one of the trailblazers.
Further research and guess what? The Computone 4.56 drivers
don't work real well with bi-directional communications. I called
into the port that the caller was having problems on - and it was
dead. The computone utilities ttyoff didn't toggle DTR on the port
(like it normally does when it turns the port off). Further
research - and the port appears to not accept inbound calls after
using it to originate calls. Great - aren't we having fun.
Hmm. I installed the 4.31 drivers (which work fine - except
for SLIP).
--
Larry Snyder, Northern Star Communications, Notre Dame, IN USA
{larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu}
backbone usenet newsfeeds available
Public Access Unix Site (219) 289-0282 (5 high speed lines)crtb@helix.nih.gov (Chuck Bacon) (11/05/90)
Larry, SLIP is just IP using an async. RS-232 port. Error correction is done by TCP. This requires fast turnaround, however, and so the best bet is V.32 with *NO* packetizing, error correction or compression by the modem. A true V.32 rate of 9600 should give an effective data throughput close to 80%, or near 760 bytes per second. -- Chuck Bacon - crtb@helix.nih.gov - 301-496-4823 "People who like this kind of thing will find this the sort of thing they like." --A. Lincoln
jparnas@larouch.uucp (Jacob Parnas) (11/06/90)
In article <1990Nov04.130243.4587@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes: |> jparnas@larouch.uucp (Jacob Parnas) writes: |> ... |> >Microcom 3296hs BETA: PROM LEVEL: GOLD: 8/31/90, SERIAL BAUDRATE: 38400 |> |> what version of SLIP - PPP? |> 4.3 BSD slip with header compression (Van Jacobson -- ftp.ee.lbl.gov). ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
jdeitch@jadpc.cts.com (Jim Deitch) (11/06/90)
In article <600@nih-csl.nih.gov> crtb@helix.nih.gov (Chuck Bacon) writes: >Larry, SLIP is just IP using an async. RS-232 port. Error correction is >done by TCP. This requires fast turnaround, however, and so the best bet >is V.32 with *NO* packetizing, error correction or compression by the >modem. A true V.32 rate of 9600 should give an effective data throughput >close to 80%, or near 760 bytes per second. > >-- >Chuck Bacon - crtb@helix.nih.gov - 301-496-4823 > "People who like this kind of thing > will find this the sort of thing they like." --A. Lincoln What do you mean no compression? If you are moving text files around, ftp or telnet, then compression can increase throughput by about 10-15%. The only place the compression takes place is between your modem and the host's modem. That way the info can get into the faster transport sooner. Unless of course the host you are talking to also uses slip without compression. Jim -- UUCP: nosc!jadpc!jdeitch ARPA: jadpc!jdeitch@nosc.mil INET: jdeitch@jadpc.cts.com
richard@pegasus.com (Richard Foulk) (11/07/90)
> If your tired of hacking your kernel, try getting a TELEBIT > NetBlazer. This will make life easier for a lot of us Serial Line > Dial-up IP users. Call me if you need more info on any of this. How about a cheap pc instead of a NetBlazer? Could save you a couple $grand... -- Richard Foulk richard@pegasus.com
karl@ddsw1.MCS.COM (Karl Denninger) (11/09/90)
In article <1990Oct31.115338.4582@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >We have SLIP up and running here on nstar - and throughput >over Telebits is very bad - while 2400 baud appears faster - >it is as expected still quite - so I guess V.32 is the next path. > >Are the new V.32 with v.42bis modems the way to go with SLIP? >Will it be possible to get throughput in the 15 kbytes range >with these new modems (in excess of the carrier rate - after all >the modem manufactures claim throughput in excess of 20,000 bps?) > >-- > Larry Snyder, Northern Star Communications, Notre Dame, IN USA > {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} > backbone usenet newsfeeds available > Public Access Unix Site (219) 289-0282 (5 high speed lines) We are having a hell of a time getting this to work. Here's the deal: We have one machine which has a bunch of Telebit 2500's. We would like anyone to be able to log in under SL/IP that has the appropriate login id and password. The problem is twofold: 1) The system requires a system name when you set up SL/IP. The problem, of course, is that I don't KNOW what which system will call! ARGH! 2) It also wants a line name (ie: /dev/ttyxx). Again, what if I have a bunch of lines on a rotary?! Grrrrr... 3) When I go through the motions, it doesn't work. I don't know if this is me or something else. In any event, it looks like the data is going across the line, but I get no response back from the remote end (and yet data appears to be going both directions). I'm about at wits end. Does anyone have a solution that works? I want to use my current modem pool, and not split them off onto some PC-router solution (which would require doubling our modem investment). I also >must< be able to accept and make connections to multiple sites. We're willing to do some hacking, IF I know what to hack! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
larry@nstar.uucp (Larry Snyder) (11/09/90)
karl@ddsw1.MCS.COM (Karl Denninger) writes: > 1) The system requires a system name when you set up SL/IP. > The problem, of course, is that I don't KNOW what which > system will call! ARGH! > 2) It also wants a line name (ie: /dev/ttyxx). Again, what > if I have a bunch of lines on a rotary?! Grrrrr... > 3) When I go through the motions, it doesn't work. I don't > know if this is me or something else. In any event, it > looks like the data is going across the line, but I get > no response back from the remote end (and yet data > appears to be going both directions). Nope - not that I found out - all the SYSV 386's that I have found only allow one SLIP connection tied to a specific port - except for ESIX - which I've been told will allow you to define 2 ports for SLIP. Intel release 4 also allows only one SLIP connection at a time - My Computone driver won't allow data to come back from the modem (like you mention in #3) - upgrading to the latest driver fixed that - but broke bi-directional communications on the ports (which is needed more). > I'm about at wits end. Does anyone have a solution that works? I > want to use my current modem pool, and not split them off onto some > PC-router solution (which would require doubling our modem > investment). I also >must< be able to accept and make connections > to multiple sites. We're willing to do some hacking, IF I know what > to hack! Let me know what you find out - My 2 cents is to get another V.32 modem on a single line - and maybe somehow - modifing the scripts to add the names of the 20 or so machines you need to connect with. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, {uunet|backbone}!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)