Eric J. Schubert ([log in to unmask]) wrote:
[snip...]
: >: (3) At what point will my LANIC saturate?
: >   - You probably don't have to worry about this too much regardless of
: >     whether you use DTS or VT.  Again, I haven't got exact figures but
: >     the lanic should handle 200..300 packets per sec and 300 users
: >     hitting 'enter' or so simultaneously is quite unlikely... I have
: >     seen systems (992-400) running with about 700 VT sessions and lanic
: >     was not a problem.
 
: OK, Eero, what if I have a lengthy DSCOPY going on between two HP machines?
or
: continuous spooling over the LANIC between HP machines? or JetDirect over
: a network or... you get the picture.  Lanic isn't just for NS/VT.
 
- Oh yes, I do recognize that.  However, the previous question was purely
  on DTC TIO vs. NS/VT performance and moreover, from the CPU usage standpoint
  rather than anything else.  Other traffic (of course) has to be taken into
  account.  However, if you run both over the same lanic, both get impacted
  in a similar fashion since the media access protocol is the same (CSMA/CD)
  and the card+cable are the same for both TIO and TCP/IP traffic.
 
  If you have dedicated lanic for termio -- it's another story.  If they both
  access the same physical cable... then again, both are going to see same
  busy rates in the cable and have transmits deferred every now and then...
  However, I'd like to point out that I (and this is just my experience)
  have rarely (if ever) heard of LANIC being the bottleneck.
 
: Now, lets say ping returns lengthy responses off our machine, is it a CPU
: problem or LANIC problem or both?
 
 - Expected ping response time from a 3000 is longer than from a unix machine
   ... and I think the reason is (apologize for little knowledge on unix
   implementation) that on a 3000 a separate process has to be dispatched to
   respond to a ping request (ICMPSERV.NET.SYS) -- on a unix machine I don't
   think that's the case.
 
 - Then again... it could be the network in between, routers etc...  in our
   building network traffic rates have increased above what ethernet can
   handle (30..40%) and until that gets fixed, we'll continue to see
   pretty bad response times... well, that's our problem, not yours...
 
: How can you determine factors that affect network response? What tools are at
: my disposal to check LANIC rates or problems?
 
 - LINKCONTROL STATUS command allows you to check data rates... LINKCONTROL
   tracing gets more detail...  You could also have a job collecting link
   statistic which then could be used to get graphical info on LAN utilization
   vs. time of the day or so... (I actually have a dumb program that does
   the data collection into a logfile and can also analyze the content..)
   also, the SNMP agent has link stats.  Link statistics can also be resetted
   thus allowing you to concentrate on a specific time you need to watch.
   Specifically the option ;status=d gives the most detail...
 
: Also, if a LANIC saturates from network services, is there an upgrade path to
: LANIC?
 
 - I would not think it does.  You have the option of adding more LANIC's,
   however, that would result into using another IP network for the second
   one...  Which is probably not anything you want...  maybe a faster
   network is required... FDDI... 100VG???
 
Best regards,
Eero - HP CSY lab.