#Suicide as an option <g>
3 messages in this thread
David, are you sure you were hitting 30% bandwidth on your net, and
not 30% CPU utilization? 30% bandwidth is amazing. On my net, which
has 30+ users pretty much all the time, when I've got two people
doing SQL database searches and several Macs printing 24-bit 400dpi
files, all to the tune of several thousand packet per second, my
bandwidth has *never* gone over 10%. CPU utilization does peak at
times, tho', up to 70%, even, but not for too long. If you're really
getting that much bandwidth, I'd be suspicious that something is
wrong. Your mentioning of bad network cards to John is a good one,
tho'. He might have gotten a bogus card that freaks when the load
gets beyond a certain point.
David {inquiring minds want to be annoying} Taffet
The analyzer I use reports packets per second and then converts that
into a percentage of bandwidth. Ordinarily we swing somewhere
between 5 and 10% with ordinary useage on a heavy day. I might peak
way up during some extraordinary transfers, but that is all with
"ordinary" office type users; word processing, I do review CPU
percentages too, but that has never been a factor, even when my
server was a 386.
When I added in those 3 GIS users the useage went way up. The
percentage of their time spent in moving large amounts of data was
very high. I wasn't showing any significant numbers of errors
anywhere on the system and their packets were all within normal
parameters. I was able to graph out the system useage for a 48 hour
period for the system as a whole and for each of the 3 GIS users and
they were definately producing the load…Enough so that a seperate
segment for them would be warranted.
Incidentally, we were doing this as an experiment. Most parks, even a
fairly large one, can't really afford to set up a seperate network to
support a specific function like GIS. We wanted to see what impact a
good sized GIS might have if it shared network resources with other
users. Our useage was high, but probably not more than would be
reasonable during peak fire season, or just before a resource
management plan was due. I was watching the packet and collision
rates very carefully and watching the quality of the packets. The
errors within a packet can help you determine if collisions are caused
by timing problems, driver problems, cable problems, or just simply
too much stuff happening at once!
Have a great weekend…glad this info was useful. I have gleaned so
much from you folks over the months and was delighted to help out for
a change.
I considered the card being the problem, so I switched the one in my
"server/workstation" with one of the slave's. Still get the checking
out, but I'll try a whole new card. If I remember correctly, the
slave with the server's card failed first, but then the other mahcine
failed, too, so that's probably not it.