home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / os2 / networki / 1284 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  1.8 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!cogsci!lopes
  2. From: lopes@cogsci.ucsd.EDU (alann lopes)
  3. Newsgroups: comp.os.os2.networking
  4. Subject: IBM's TCP/IP 1.2.1 SLIP
  5. Keywords: SLIP tcp/ip
  6. Message-ID: <1583@cogsci.ucsd.EDU>
  7. Date: 10 Sep 92 05:10:17 GMT
  8. Organization: University of California, San Diego
  9. Lines: 34
  10.  
  11.  
  12.   So has any lucky soul been able to get SLIP working.
  13.   The modem connection is made, although there is no
  14.   message confirming the connection (should there be one?),
  15.   but when I try to ftp or telnet it always times out and
  16.   when I ping no one returns it.  Not GOOD!
  17.  
  18.   Are there any magic words that will get this thing
  19.   going?
  20.  
  21.   On a different note -- a few days ago I posted a
  22.   message about the horrible performance of a remote
  23.   telnet session when the server's CPU has a high load.
  24.  
  25.   There were several subsequent posts (THANK YOU ALL!)
  26.   explaining what the problem might be.  All seem to
  27.   miss a couple of points (probably because I was not
  28.   clear in my problem description):
  29.  
  30.   1) with average CPU load the performance of the remote telnet session is fine
  31.   2) a telnet session from the loaded CPU to the outside world works fine
  32.     
  33.   The problem is when the loaded CPU is handling a remote telnet
  34.   session.  It seems that when the CPU is loaded OS2/TCP/IP (or whatever) 
  35.   does not give enough priority to the remote session resulting
  36.   in a completely unusable remote session.  Is there any way to
  37.   either give the remote session more cycles or limit the priority
  38.   of the task(s) that may be using too much CPU.  Of course, one
  39.   needs to be able to change these priorities remotely.
  40.  
  41.              Thanks all very much -- alann
  42.  
  43.    alann lopes:        alopes@ucsd.edu       -- internet
  44.    (619) 534-7417      ALOPES@UCSD           -- bitnet
  45.