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.