response 1 of 37:

Dec 30 21:24 UTC 2003

Some responses from the previous item, on the current subject:

---------------------------------------------
Item #62: Disk Quotas on the New Grex Machine
Response 4 (24) Mary Remmers (mary) Tue, Dec 30, 2003 (07:20) 2 lines:

 By increasing disk space over what's allowed now, will we be
 encouraging storage of graphic files?

---------------------------------------------
Item #62: Disk Quotas on the New Grex Machine
Response 19 (24) Jim Daloonik (naftee) Tue, Dec 30, 2003 (13:54) 3 lines:

 What, exactly, is wrong with the storage of graphics?  Certainly it can't be
bandwidth, because with the faster NextGreX machine, it should take that in
 stride, no?

---------------------------------------------
Item #62: Disk Quotas on the New Grex Machine
Response 21 (24) Mary Remmers (mary) Tue, Dec 30, 2003 (14:45) 9 lines:

 If we increased the quotas enough to allow folks to put
 web-accessible pictures on Grex, would that traffic 
 noticeably slow most user's sessions?
 
 I'm *really* hoping that Grex can be significantly faster
 on the new machine.  Unless Grex is faster I expect fewer
 and fewer users will stick around long enough to get hooked.
 
 Don't know if that helps but it is where my concerns rest.

---------------------------------------------
Item #62: Disk Quotas on the New Grex Machine
Response 22 (24) Dan Cross (cross) Tue, Dec 30, 2003 (15:07) 1 lines:

 Regarding #20; That's never been measured, and is only a conjecture.

---------------------------------------------
Item #62: Disk Quotas on the New Grex Machine
Response 24 (24) David Brodbeck (gull) Tue, Dec 30, 2003 (16:05) 2 lines:

 I think the ban on graphics was also intended to keep people from
 putting up porno sites.  The target audience for ASCII porn is pretty small.

---------------------------------------------

response 3 of 37:

Dec 30 22:12 UTC 2003

In response to #20 in item 62:

Of course a faster CPU doesn't increase network bandwidth.  However, a faster
CPU would mean less time for the host to spend accessing the file, which in
turn leads to a faster access of the image.
Besides, on average, the transfer of mail to and from the system would eat
more bandwidth than the transfer of images, guaranteed.
Besides, no one ever payed any attention to the "no image" rule.

response 5 of 37:

Dec 30 23:15 UTC 2003

Grex's ban on graphics was because of disk space considerations as 
well as network bandwidth.  Back in the early days, there wasn't much 
disk space around here.

There has been discussion of porn from time to time over the years.  
Anyone could host a porn site from Grex anyway, by posting their 
graphics elsewhere and linking to them from here.

Anyone can have any sort of graphics available on their Grex home page 
if they can link pictures from another site on the Internet.  They 
just can't use up a lot of Grex's very limited bandwidth with graphics.

I like the ban on graphics (and other multimedia).  Grex is already 
the slowest Internet site I regularly use.  I don't see there being 
any likelihood of gaining for Grex users, overall, by allowing user 
graphics to be loaded here.  There are *so* many other options in the 
world these days.  

response 7 of 37:

Dec 30 23:29 UTC 2003

Yes, I'd say it is.  Isn't the limit 100K as of now?  A reasonable 
viewable picture is about 60K.  What else are you going to use 2 MB of 
space for?

response 9 of 37:

Dec 30 23:42 UTC 2003

re 3:
        The limiting factor in accessing images on Grex isn't the time it takes
Grex's computer to access the file, but rather the amount of data that can
pass over Grex's network connection, the link between the router on Grex's
ethernet and Grex's ISP.  Time taken for the data to go over the network is
what causes accessing stuff on Grex to be slow for the end users.

Grex's DSL connection is really slow by modern standards, although it seemed
like a nice improvement when it was installed three or four years ago.  The
economical way to multiply that speed by about 300 or so would be to stick
Grex in a colocation facility, but the ban on graphics probably shohuldn't
be lifted before that happens.

response 11 of 37:

Dec 31 01:02 UTC 2003

Regarding #9; That's the conjecture I was referring to that's never
really been tested.

response 13 of 37:

Dec 31 01:20 UTC 2003

Some recent information:

Program started at Sun-28-Dec-2003 00:57 local time. 
Analysed requests from Sun-21-Dec-2003 01:03 to Sun-28-Dec-2003 00:56   (7.0
days).  

Total completed requests: 44 274 
Total failed requests: 22 249 
Total redirected requests: 1 751 
Average requests per day: 9 759 
Number of distinct files requested: 2 792 
Number of distinct hosts served: 7 441 
Corrupt logfile entries: 41 
Total bytes transferred: 312 148 721 
Average bytes transferred per day: 44 619 233  

response 15 of 37:

Dec 31 02:18 UTC 2003

Load average isn't often a problem.

http://www-personal.umich.edu/~gelinas/stuff/House/102Burton-FrontView.jpg
is 454799 bytes, almost a half-meg, all by itself.

response 19 of 37:

Dec 31 15:39 UTC 2003

Here's a concrete proposal:

*IF* we want to experiment with image files, we should set up a 
separate partition in which each user is automatically given a 
directory linked to their home directory.  That partition should 
have firm quotas, and be made web-accessible or not at the system 
level, though users could retain privacy by making their image 
directories or files non-world-readable.  Images would be allowed, 
up to the individual limits enforced by the quota on the image 
partition (presumably something less than the home directory quota), 
and images would be allowed ONLY in the image directory.

If we set it up this way, we'd continue to enforce image file rules 
in home directories the way we have, except we'd simply move them to 
the user's image directory rather than deleting, up to the limit.  
We'd also have the option of turning on and off web-accessibility of 
image directories all at once, so we'd have a means to both measure 
and control bandwidth usage for images.

It would be some work up front to set this up, but the directory and 
links could be generated by newuser, information about the system 
and its probationary status could be provided easily, and (IIRC) 
partition level-quotas are available so that would be simple to 
implement, and allowing/disallowing webserver access to the 
partition would also be straightforward to implement.

Am I missing anything?

response 21 of 37:

Dec 31 17:53 UTC 2003

re 17 I mentioned above that hardly anyone follows the "no images" rule.  I
didn't know about it until a couple months ago.  Despite all this, there is
still no evidence to show GreX has become another "tripod" or free web hosting
site.  GreX is slow because of the consistently high load averages, NOT the
bandwidth.

response 23 of 37:

Jan 3 01:11 UTC 2004

I like the idea of continuing the no-images rule on Grex.  Many of us know
about the rule, and most of us follow it.  

I'm mostly concerned with the speed-of-use issues, so the file limit would
seem most important in uploading and downloading, and not in static storage
that was only accessed in small sized chunks.