[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: moving of dinstall run time on master.

> > If I'm not mistaken, we're not talking about 'bandwidth', we're talking
> > about 'excessive bandwidth'. The fault does not lie with the admin, it
> > lies with the developer who set this up without regard for the people
> > providing the service. 
> Hmm, no, we're not talking about bandwidth.  We are talking about
> a donor dictating certain things, tweaking users files without asking
> the project to work on it.

The problem is, in the sysadmin world, we see issues like this as
something requiring immediate attention. Bandwidth costs money. Bandwidth
costs a LOT of money, as a matter of fact.

I don't know if you're familiar with some of the more gory things such as
burstable bandwidth, but often what you have (And while this isn't the
case for Novare, it may be a case for their upstream provider) is this:

You are paying for a certain amount of bandwidth, but it's not capped;
That is, if you exceed the bandwidth you pay for, you do get the extra
bandwidth, at often prices quite higher than you'd pay for bulk bandwidth
purchase. Especially during peak hours. With some plans, even a bandwidth
spike will bump you into the next bandwidth bracket for a set amount of
time, which can get /expensive/.

Now,  Novare's upstream has an upstream provider, whether that be a
backbone provider or someone else with yet another upstream. 

Novare pays a flat rate to their upstream, possibly contractual, possibly
fluctuating. Their upstream pays by bandwidth to /their/ upstream. So
while bursting peak bandwidth isn't going to /directly/ cost Novare money,
it could cost their upstream a considerable amount,m, which could be
reflected back in the rate that Novare pays, indirectly costing them
money. It wil also likely degrade the relationship between Novare and
their upstream, which is a /bad/ thing to have happen. 

Thus dinstall, depending on the amount of traffic it generated, which
seems to have been quite substantial, could have ended up costing the
upstream hundreds of dollars. 

This situation is similar, though of course not identical, to having a
user-spawned process eating all the CPU time and RAM due to a memory leak.
On a production system, with other critical things running and being
prevented from doing production tasks, an admin would be forced to try to
kill the process gently and hope that whatever unsaved work remained would
be recoverable, instead of trying to track down the user and inform them
of the situation, and getting them to fix the problem themselves, which
could take hours and result in other programs being unable to run
scheduled jobs, even possibly causing operating system instability. 

Now... it is my understanding that Mr. Heath did not actually edit any
files, but proposed that something needed to have been done immediately.
Which, as I posed earlier, I consider overly generous. I would have
supported his decision to edit files, regardless. administering a network,
sometimes you have to step on people's toes to ensure that the entire
network is necessary to ensure availability of the entire network. 

This is not a flame or an attempt to stir anything up; It's merely the
situation from the point of view of a professional system administrator.

> Regards,
> 	Joey

In good faith, 


PS. Due to having a monitor blow up, having innumerable ppp problems
including routes dropping, and many other annoying issue, this email was
sent over two days and about 15 pine processes. :> 

-> 1988 Black Kawasaki EX500 ('Yarf!') <street>
-> FAA licensed private pilot
-> Unix system administrator, was WebTV Networks, now jobhunting!

Reply to: